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.

    • @Hirom@beehaw.org
      link
      fedilink
      1110 months ago

      The information appearing in memory isn’t a serious issue, your computer would need to be compromised while you’re using it. In which case all bets are off.

      What’s concerning is the data potentially appearing in hibernation/swap files, and persisting on disk after shutdown. This would be rather serious, as someone stealing the computer could potentially recover the key.

      Using full disk encryption would hopefully mitigate this.

      “If your computer is already infected by malware that’s running in the background with the privileges of your user, this finding doesn’t make your situation much worse,” says the researcher, who goes by the handle “vdohney”.

      “If you have a reasonable suspicion that someone could obtain access to your computer and conduct forensic analysis, this could be bad. Worst case scenario is that the master password will be recovered, despite KeePass being locked or not running at all.”

      • @Hirom@beehaw.org
        link
        fedilink
        6
        edit-2
        10 months ago

        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?

          • @Hirom@beehaw.org
            link
            fedilink
            510 months ago

            There are multiple local attacker / evil maid scenarios, each require different counter-measures:

            • Attacker with access to the system memory while the DB is unlocked, ie prior undetected compromise.
            • Attacker with access to the system memory after the DB is locked, ie stealing a powered-on machine with a locked manager.
            • Attacker with access to the system hibernation/swap file, ie stealing a power-down machine.

            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!

        • 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.

      • Chris Remington
        link
        fedilink
        410 months ago

        KeePassXC could be another viable choice. Bitwarden has been free of any incidents for the eight years that I’ve been using it.

        • @rysiek
          link
          1010 months ago

          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.

          • viq
            link
            fedilink
            410 months ago

            @sxan @admin 1password is interesting since they have taken steps to make sure even full access to their servers does not mean access to contents of your vaults, since vaults are client side encrypted, not only with key derived from password, but also by another key you need to transfer between your devices for another device to be able to access the stuff.

            • 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.

    • @jherazob@beehaw.org
      link
      fedilink
      1110 months ago

      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.

    • Vega
      link
      fedilink
      1110 months ago

      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

    • petrescatraian
      link
      fedilink
      510 months ago

      @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).