Discussion on CVE-2023–35866

On June 19, 2023 an alleged KeePassXC vulnerability with the identifier CVE-2023–35866 was posted against KeePassXC versions up to 2.7.5. As the developers of KeePassXC, we do not consider the issue a vulnerability and have filed a request for the CVE to be rejected. Additional information can be found in the discussion on GitHub.

The root of the argument submitted by the CVE author is that an attacker with unfettered access to an already unlocked database could export or change the password without requiring the original credentials. Where this is true, there are numerous barriers to actually executing this attack sequence. In addition, having lost control of your computer in this manner would mean the attacker could execute any number of security compromises against your KeePassXC database, regardless of requiring credentials prior to export or credential change.

At this time, we are not planning any drastic changes to the program to address this submission. We are also monitoring the request to reject/dispute this CVE on the grounds it is not actually a vulnerability in our software. Information on mitigation and other factors is included after the break.

The reasoning for the rejection of this CVE is as follows:

This issue is not a vulnerability. KeePassXC is an offline password manager and hence BY DESIGN, there is no such thing as an “authenticated user”. Asking the user for their password prior to making any changes to the database settings adds no additional protection against a local attacker. An attacker can ALWAYS make changes to the database or copy its contents if they get access to it in its unlocked form. A password prompt will not change that. There is also no (and cannot be any) “second factor” for “authentication.” Again, this is by design of an offline password manager and not a security problem. This is different from online web services.

A password prompt does not even prevent an attacker from locking a user out of their database. If that were the attacker’s goal, they would not need access to the unlocked database. Corrupting the locked KDBX file is enough to achieve this goal. The correct strategy to protect against this is keeping backups of the database. A password prompt will not help.

Adding an additional credential validation to perform specific actions on an unlocked database is akin to security theatre. There are numerous ways for an attacker with unfettered access to your unlocked database to compromise credentials without having to export it. These are all part of the normal and expected operation of an unlocked database within KeePassXC. To add an additional credential barrier to each of them would absolutely represent an undue burden to every user.

The simplest mitigation to this threat vector is to lock your database prior to leaving your workstation. By default this is done when the screen is turned off or screensaver is activated. Users can also configure a timeout based lock and/or lock when minimized to further restrict access. We recommend these features be enabled on shared work stations or other places where physical access to your machine can be attained. Due to our screen capture protection on Windows and MacOS, it is not possible for a remote attacker to conduct an export or access your credentials from the GUI interface.

Feedback

Please report any bugs you encounter at our GitHub issue tracker. We are also available on Matrix for real-time feedback and discussions. See our contact page for further options.