The dev does quite a lot actually to protect the program, including using things such as SecureString. However, even Microsoft have a comment against this saying:

"When porting code to .NET Core, consider that the contents of the array are not encrypted in memory. The general approach of dealing with credentials is to avoid them and instead rely on other means to authenticate, such as certificates or Windows authentication."

Which I read as: "If writing a program in C#, assume the memory can be read by apps on the same device."

On a Linux system, for example, if you're allowed to look inside the process, which would be for similar reasons to why you're allowed to look inside a configuration file belonging to the user, then it's pretty much just as easy.

Suppose we want to look inside process #1234, we just open the file /proc/1234/mem and suppose we know we want the value at address #003e0f20 we just seek to that address and read however much we want.

Unlike a typical data file the memory map has holes in it, so we do need to know where we're going, but that's OK the Linux kernel also provides information about what is in there and where it is, so e.g. we can root around specifically in the program's heap.

> if you're allowed to look inside the process, which would be for similar reasons to why you're allowed to look inside a configuration file belonging to the user

On recent Linux distros, by default you can't ptrace (or read memory via /proc/x/mem etc) of non-child processes https://www.kernel.org/doc/html/latest/admin-guide/LSM/Yama....

I just feel that eventually Linux will have to move to the sandboxed model for apps like Android and, recently, Windows.

About data stored in-memory, see KeePass.info > Security > Process Memory Protection [0]

> While KeePass is running, sensitive data is stored encryptedly in the process memory. This means that even if you would dump the KeePass process memory to disk, you could not find any sensitive data. For performance reasons, the process memory protection only applies to sensitive data; sensitive data here includes for instance the master key and entry passwords, but not user names, notes and file attachments. Note that this has nothing to do with the encryption of database files; in database files, all data (including user names, etc.) is encrypted. [...]

[0] https://keepass.info/help/base/security.html#secmemprot

Replacing the keepass binary is probably easier than reading the memory. Even if you don't have access to write to /usr/bin/keepass or C:/Program Files/..., you can probably still replace the desktop icon, start menu shortcut, etc. to point to a different binary, or frob with the user's shell config to put ~/.bin in the PATH and/or set up an alias.

Unfortunately if you can read a configuration file in a user's home directory, you can also get local admin rights very easily via various simple exploits.

This is why RCE type exploits are super dangerous.

There probably won't ever be a solution for this unless we get a completely rewritten Windows / Linux with pure security in mind.

I wonder if any VC would invest in a startup to build a secure OS.

I’m all for more funding for OpenBSD. I doubt we would be able to really tackle the usability hindrance of security first though.

As a huge openbsd aficionado I don't think openbsd is more secure than any other operating system, or more correctly speaking, I think openbsd definition of security is different than most peoples definition of security. If anything, by most peoples definition of security openbsd may be less secure.

Most peoples definition of security is to have improved access control such that unauthorized access cannot happen. The openbsd definition of security is closer to "build it correctly so that it operates correctly". openbsd access control is actually fairly limited and rudimentary.

It's pretty easy[1] if you're running as the same user, or higher privilege

1: https://learn.microsoft.com/en-us/windows/win32/api/memoryap...

Writing*