CVE-2023-32784: KeePass / Discussion / Open Discussion: Security

• Summary
• Files
• Reviews
• Support
• News
• Discussion
• Wiki
• Tickets ▾
  • Bugs
  • Feature Requests
  • Support Requests (Archive)
  • Patches
• Code
• Donate

Menu ▾ ▴

Security - Dumping Master Password from Memory, Even When Locked

Created: 2023-05-01

Updated: 5 days ago

• Hello,

  First I’d like to thank Dominik and others for the great work they are doing on KeePass!

  I found a potential issue in the latest KeePass 2.X (default settings). Given a process memory dump, I am able to reconstruct the master password. It doesn’t matter whether the workspace is locked or not, it works regardless. The memory source also isn’t important - for example, it can be a pagefile (swap) or the hibernation file. No code execution is needed, just the memory alone.

  I haven’t found a contact for responsible disclosure, so I am posting it here. Please let me know if I can post details here or send it somewhere else instead.

  Based on what I read on the website and this forum, it might not be considered a problem at all. However, this statement from the website would then be incorrect:

  "When locking the workspace, KeePass closes the database file and only remembers its path and certain view parameters.

  This provides maximum security: unlocking the workspace is as hard as opening the database file the normal way."

Last edit: Viktor 2023-05-01

• Thanks for your quick response! No, that is not what I did. The password stays allways hidden.
  I take it that I can post here then.

  The problem is with SecureTextBoxEx. Because of the way it processes input, when the user types the password, there will be leftover strings. For example, when “Password” is typed, it will result in these leftover strings: •a, ••s, •••s, ••••w, •••••o, ••••••r, •••••••d

  It is surprisingly reliable, try it! POC here: https://github.com/vdohney/keepass-password-dumper

  I understand that this is likely time-consuming to fix, as it would probably require writing your own textbox instead of inheriting from Windows.Forms.TextBox.

Last edit: Viktor 2023-05-02

• Interesting, many thanks for reporting this issue!

  I have a few improvement ideas for it and will implement and experiment with them now. Details soon.

  Best regards,
  Dominik

• I’ve now implemented two enhancements:

  1. When running on Windows, KeePass now calls Windows API functions for getting/setting the text of the text box directly, in order to avoid the creation of managed strings. For most lengths, no “●…●?” fragments occur in the process memory anymore, but for a few lengths, there still is one (maybe Windows is occasionally allocating a new buffer for the text box content?).
  2. KeePass now creates some dummy fragments in the process memory (random number of fragments that contain a random character and have approximately the length of the current password). With this, it should be more difficult to determine the correct fragments.

  On Windows, both enhancements are used. With Mono on Linux/MacOS/etc., only the second enhancement is used.

  Here’s the latest development snapshot for testing:
  https://keepass.info/filepool/KeePass_230507.zip

  Thanks and best regards,
  Dominik

• Nice, that’s a pretty creative fix! I’ve tested it and it seems to be doing the job, even the order in which the strings appear is useless now (the dummy strings can come both before and after the real character). I can no longer reproduce the attack.

  Thanks for fixing this, Dominik! Any estimate on when this is released?

• Great, thanks for testing it!

  The enhancements will be included in the next KeePass release (2.54). Currently, I’m still working on a few other features (also related to security) and as soon as these are finished, I’m going to release it. There is no fixed date, but I’m confident that it’ll be within the next two months.

  Thanks again and best regards,
  Dominik

Log in to post a comment.