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
      arrow-up
      11
      ·
      1 year 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
        arrow-up
        6
        ·
        edit-2
        1 year 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
            arrow-up
            5
            ·
            1 year 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.

        • 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@beehaw.org
        link
        fedilink
        arrow-up
        4
        ·
        1 year 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@szmer.info
          link
          fedilink
          arrow-up
          9
          ·
          1 year 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.

            • 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
      arrow-up
      11
      ·
      1 year 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@feddit.it
      link
      fedilink
      arrow-up
      11
      ·
      1 year 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

    • Cătă@libranet.de
      link
      fedilink
      arrow-up
      5
      ·
      1 year 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).