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.
Please, switch to Bitwarden.
No.
Tge real answer is not to give control of your passwords to a third party; it’s to not use crappy .Net programs.
KeePassXC is not affected.
@sxan @admin There’s now an audit of KeePassXC. Worth reading. It’s sound.
https://keepassxc.org/blog/2023-04-15-audit-report/
I read that! Props on the auditor for doing it gratis; it’s rare to see people pay back the benefit they get from OSS.
@sxan @admin @rysiek You can also self-host Vaultwarden. Nice and easy to do via Elast.io: https://elest.io/open-source/vaultwarden
@charlesroper @sxan @admin @rysiek What’s the difference between vaultwarden and bitwarden?
See: https://github.com/dani-garcia/vaultwarden
@admin FAntastic, thanks. I’m self-hosting Bitwarden now, but I’m always interested in streamlining things.
@WillowMist @charlesroper @sxan @admin @rysiek from their github page: https://github.com/dani-garcia/vaultwarden
Alternative implementation of the Bitwarden server API written in Rust and compatible with upstream Bitwarden clients*, perfect for self-hosted deployment where running the official resource-heavy service might not be ideal.
@smorks @WillowMist @sxan @admin @rysiek Right. It’s an alternative to the official Bitwarden open source server (https://github.com/bitwarden/server), which is all .net and sql server and is quite heavy host yourself (apparently). That means most people end up using Bitwarden’s own official hosted service. Vaultwarden is a popular and active alternative to Bitwarden Server. It is written in Rust so is a lot lighter on resource requirements. You can easily spin up an instance on Elestio or Cloudron.
@smorks @WillowMist @sxan @admin @rysiek Once you have your own Vaultwarden running, you can use any of the many Bitwarden clients with it:
https://bitwarden.com/download/
@smorks @WillowMist @sxan @admin @rysiek Just seen @cloudron are here on the fedi - they also offer a really easy way to host Vaultwarden for yourself, along with loads of other good quality open source products. Worth a look.
That looks like a very good option.
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!
Yes, I was hoping that KeePassXC is not affected, thanks for confirming!!
The audit is an interesting read. The author comes off a little fan-boyish, but has good credentials and his points are well reasoned.
I’m not a security specialist, but I thought the report understandable, approachable, and brief - in short, quite readable, and informative.
KeePassXC could be another viable choice. Bitwarden has been free of any incidents for the eight years that I’ve been using it.
Bitwarden is also FLOSS and self-hostable. As much as I love KeePassXC, using it for team passwords is a pain. Having a self-hosted Bitwarden thingy would be way better.
I just don’t like having to depend on a third party, or like the idea that they have access to my keys - even encrypted. It’s too many eggs in one basket, for my taste.
But lots of people like it, and I’ve never heard of any criticisms of it from the security community, so it’s probably an acceptable choice.
Would self-hosting (as @charlesroper@indieweb.social explained here) be a more comfortable option for you?
Yes.
However, I’m perfectly happy with KeePassXC. It’s audited, secure, has a great UI, and if you want to accept less security can serve as a secret-service and ssh-agent replacement. There are a bunch of OSS tools and clients that support the kbx.v4 file format, and if you want to audit the code of the tools, they’re in almost every language. There are some really nice (pretty, user friendly) native mobile apps.
There’s risk in grabbing any old client, of course, but having such a diverse ecosystem is nice, especially if you don’t mind reading some code.
As a Bitwarden user of many years, fully and enthusiastically DISAGREE. This is a security issue on a local-only software that requires a full compromise of the computer it’s running on, it operates ON A FREAKING MEMORY DUMP, by that time you have bigger problems. There will be more such issues, including on Bitwarden, and they’ll get fixed. These kinds of bugs are a piss-poor reason to switch software, and much less to start trusting a third party when you didn’t before, doubly so when other variants of this same software don’t have these issues. Yeah, Bitwarden is great and i’ll continue recommending it, but doing so after this kind of security issues is terrible advice.
No? Bug happens and I want my password to stay offline. Bitwarden isn’t easy to selfhost and only with vaultwarden fork it become viable for users with SBC. Keepass, keepassxc and the like are still one of the best choice to store your password. If you like bitwarden stay with it, but this CVE isn’t a reason to invalidate keepass
@admin @Troy there are no third party clients for Bitwarden though afaik, at least on Android. And if they are, I’m pretty sure they are just forks of the main app. I mostly use/used third party clients when low on space (nowadays I have a whopping 128GB of storage but when I had just 16, whatever was above 50MB was just too much for me if it wasn’t justified - i.e. if there was something lighter doing whatever I needed).