4 ms·

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

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.

Cthulhu_ 4y ago
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.
- moritonal 4y ago
  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."
- wheybags 4y ago
  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/memoryapi/nf-memoryapi-readprocessmemory https://learn.microsoft.com/en-us/windows/win32/api/memoryap...
- vgalin 4y ago
  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 https://keepass.info/help/base/security.html#secmemprot
- tialaramex 4y ago
  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.
  - sporksmith 4y ago
    > 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.html https://www.kernel.org/doc/html/latest/admin-guide/LSM/Yama....
  - papruapap 4y ago
    I just feel that eventually Linux will have to move to the sandboxed model for apps like Android and, recently, Windows.
- DethNinja 4y ago
  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.
  - bollos 4y ago
    I’m all for more funding for OpenBSD. I doubt we would be able to really tackle the usability hindrance of security first though.
    - somat 4y ago
      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.
- arp242 4y ago
  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. 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.
- Macha 4y ago
  Writing*
- deleted 4y ago
  [deleted]
Macha 4y ago
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.
- Ensorceled 4y ago
  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.
  - Macha 4y ago
    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
    - maicro 4y ago
      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).
      - licebmi__at__ 4y ago
        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.
        maicro 4y ago
        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.
didntreadarticl 4y ago
Right but on windows editing a config file is substantially easier than installing a keylogger or messing with the signed executable

Cthulhu_ 4y ago

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.

moritonal 4y ago
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."
wheybags 4y ago
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/memoryapi/nf-memoryapi-readprocessmemory https://learn.microsoft.com/en-us/windows/win32/api/memoryap...
vgalin 4y ago
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 https://keepass.info/help/base/security.html#secmemprot
tialaramex 4y ago
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.
- sporksmith 4y ago
  > 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.html https://www.kernel.org/doc/html/latest/admin-guide/LSM/Yama....
- papruapap 4y ago
  I just feel that eventually Linux will have to move to the sandboxed model for apps like Android and, recently, Windows.
DethNinja 4y ago
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.
- bollos 4y ago
  I’m all for more funding for OpenBSD. I doubt we would be able to really tackle the usability hindrance of security first though.
  - somat 4y ago
    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.
arp242 4y ago
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. 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.
Macha 4y ago
Writing*
deleted 4y ago
[deleted]

Macha 4y ago

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.

Ensorceled 4y ago
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.
- Macha 4y ago
  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
  - maicro 4y ago
    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).
    - licebmi__at__ 4y ago
      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.
      - maicro 4y ago
        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.

didntreadarticl 4y ago

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