I want to believe reading memory from another process is more difficult in modern operating systems than reading a configuration file in a user's home directory. That said, I'm a layperson so I don't actually know what protections are in place for either memory or filesystem access.

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*

Another example of if you already have user-level access:

Attach a debugger to the browser, intercept password field input events.

Or KeePass doesn't have browser integration by default so just listen to clipboard events at an OS level.

KP2 can interleave among clipboard and keyboard when it is auto-typing. The feature is meant to mitigate either attack when used alone.

Attaching a debugger to a process on my OS requires me to enter my system password.

Listening to global clipboard events at the OS level is a permission I have to explicitly grant.

Which OS is this?

The first rules out Linux (unless this is a SELinux thing?).

The second rules out Windows/Mac OS/Linux with X11.

The upstream KeePass application does not support mobile operating systems. It barely supports non-Windows, which is why when most people say they use KeePass they mean KeePassXC

In Linux you can't attach to arbitrary processes depending on configuration. You can start a program with gdb, but not attach to a running one by default. It was a security upgrade a few years ago https://www.kernel.org/doc/Documentation/security/Yama.txt

Maybe NixOS? I've barely played with it, but this seems like the level of isolation/paranoia that NixOS seems to offer (as far as a layman like myself understands - could be completely wrong on all counts, as usual).

I think you might be misunderstanding nixos, the tree separation will not improve security for this kind of scenario, the only guarantee that nixos offer is that the package is exactly as it’s described on nixpkgs if the store is untainted.

Wouldn't be shocked at all, I mostly think of it as "Linux but with a bunch of inherent security separations introduced", which is why I thought it might be what the...grandparent at this point? is using.

gotta love how every discussion pertaining to program isolation in the last 20 years is just "well all these years i thought this thing isolates processes like it ought to do", followed by a quick, "nope, it actually doesn't". i blame UN*X

Eh, it's a field/domain I am definitely ignorant of - at least I'm not out there confident in my wrong beliefs X)

Right but on windows editing a config file is substantially easier than installing a keylogger or messing with the signed executable