The vulnerability affects the KeePass 2.X branch for Windows, and possibly for Linux and macOS. It has been fixed in the test versions of KeePass v2.54 – the official release is expected by July 2023. It’s unfortunate that the PoC tool is already publicly available and the release of the new version so far off, but the risk of CVE-2023-32784 being abused in the wild is likely to be pretty low, according to the researcher.
Even KeepassXC, which used Qt instead of .NET, aknowledge they can’t garantee that things put the UI, such as the passphrase, won’t appear in memory dump, even though they attempt to clear memory.
Any password manager with a UI is at risk, but KeePass should definitely do a better job at mitigating this risk.
I don’t know which software, that can ever handle passwords, is immune to a hostile user capable of doing memory dumps on the target’s memory space. Are you aware of one?
This threat model would require inter-process memory security at the OS level; you’d need to be running BSD, or some microkernel. You’re not getting those protections on mainstream OSes, even with SE Linux, and every application that ever handles credentials in plain is at risk.
The point about Qt (and, TBH, probably about .Net) is how long the password remains in memory, and ao how big the attack vector window is, not whether or not it’s completely immune to memory dump-level threats. 'Cause Windows and Linux are both susceptable to that.
Right?
There are multiple local attacker / evil maid scenarios, each require different counter-measures:
You’re focusing on the scenario #1, but the blog post allege KeePass is be vulnerable to all 3 attack scenarios. No password manager is resistant to #1 to my knowledge.
KeePassXC is at least partially resistant to #2 on a best-effort basis. Where possible, they use a custom allocator that zeros memory. The recent audit claim no username/password/passphrase was found in the memory dump after locking, but some metadata/notes were found. I think pass is resistant to #2 because it’s a short-live process that unlocks & obtain-the-pass & exit immediately.
IMHO #1 is a non-issue, #2 is a low-severity issue, and #3 is a medium-to-high-severity issue. Operating Systems have API programs can use to declare allocated memory as being non-swappable, which password managers should be leveraging to protect against #3. So being vulnerable to #3 is bad.
True, all true. The KeePassXC auditor was able to get metadata and notes (which dismayed them, as there was no indication that notes were not encrypted) from a dump after DB lock.
Good points!