To quote Raymond Chen: this exploit "rather involved being on the other side of this airtight hatchway"
If they didn't modify the config, they could presumably use one of a plethora of tactics to extract data directly from keepass.exe's memory.
If they didn't modify the config, they could presumably use one of a plethora of tactics to extract data directly from keepass.exe's memory.
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.
Listening to global clipboard events at the OS level is a permission I have to explicitly grant.
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
"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."
1: https://learn.microsoft.com/en-us/windows/win32/api/memoryap...
> 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. [...]
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.
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....
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.
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.
Basically, as soon as local access has been gained by an attacker you can not longer trust anything unless you have unusual protections such as locking down the shell/desktop configuration, or disallowing running binaries from ~, which isn't the case for most systems, and even those protections are tricky to be 100% foolproof. That you can't change the system itself is irrelevant if you can trick the user in to running something outside of the usual system, which is usually quite easy.