Attacker could change security settings even on locked database

[ThomasSteinbach]

Expected Behavior

The security settings should just be available when an unlocked database is opened.

Current Behavior

If an attacker has access to a computer with keepassxc on it, he could simply open keepasssc, open the [settings -> security] menu and disable timeouts or other security relevant options. Next time the keepassxc user is opening a database and leaving its computer by habit with the confidence of his keepassxc security settings in mind, the attacker may then have access to the still opened database.

Possible Solution

• Make security settings just available when at least one database is opened.
• Protect the security settings within the keepassxc settings file
• It would be even better, if the security settings are linked to the database and are valid per database.

Steps to Reproduce

1. access keepassxc
2. from the menue open "settings" -> "security"
3. disable/enlarge all timeouts; disable database locking options
4. close the menu and leave keepassxc in the state you accessed it before
5. wait until the victim has unlocked the database and left its computer without locking the database by habit

[phoerious]

If someone has access to your computer that someone can do things a lot worse than changing your settings.

[droidmonkey]

This is covered by another issue report requesting enterprise control of settings

[droidmonkey]

See #2189

[ThomasSteinbach]

@phoerious This issue is focused on KeePassXC. It is not about what someone can potentially do on an unlocked OS, it is rather about an attack vector to steal credentials out of KeePassXC. And it is more than just changing settings, because changing the mentioned settings is the entrypoint into a security breach.

I think for a security relevant software like KeePassXC it is important to think out of the box. Not just the integral security is important but also to help the user to keep its secrets safe in a general way.

[ThomasSteinbach]

@droidmonkey Perhaps, but this issue is more OS specific and not easy to configure for a single user.

[phoerious]

You can install a trivial Keylogger (easiest on Linux with the broken X11 input stack) and get the full master password.

[droidmonkey]

The problem with your attack scenario is that it still requires the attacker to have continued access to the machine in order to get to the database that no longer locks on time. In which case they might as well have installed a virus or some other malware

[RenatoLopes771]

Giving the nature of this, shouldn't it be a private issue? Security flaws shouldn't be shared to the public.

[droidmonkey]

This isn't a security flaw.

[J3m5]

It would still prevent coworkers who have access to the machine and are not hackers from having access to the database when the database has not been closed.

[droidmonkey]

Once you've given up physical access to a machine, and especially if you are sharing accounts (???), there is very little you can do to protect yourself from a malicious actor.

[ThomasSteinbach]

@droidmonkey So what is locking/closing a keepassxc database then good for?

[droidmonkey]

As of 2.4.3, locking a database ensures your RAM is clear of all sensitive information from the database. This is done by overwriting all data storage associated with the database with zeros.

However, this does not preclude someone with physical access to your machine from doing anything (including installing user mode malware) that can compromise your database while it is unlocked.

[J3m5]

Once you've given up physical access to a machine, and especially if you are sharing accounts (???), there is very little you can do to protect yourself from a malicious actor.

No need to share accounts, just forget to close your session or have a need to leave your workstation in a hurry....

This would suffice to remove some (minor) risk factors and prevent concerns
from being raised on this point.

[ThomasSteinbach]

@droidmonkey ok, your explanation sounds for me like it is a good choice to usually lock the database early or when not in use in order to prevent access from others to the data stored in the keepass database. Isn't it? E.g. when leaving the computer in a hurry and forgetting to lock the OS itself, like @J3m5 described a comment before.

[intika]

If a security issue have any argument in its favor it should be fixed...
This would imply encrypting the keepassxc.ini which is not an easy task without modifying the core functioning, on the other hand migrating the security section of the settings to the used data base make sens and should not require a huge patch...

[phoerious]

Encrypting keepassxc.ini does nothing. You'd need to prove it's authenticity somehow. Also if you don't want to store the key somewhere unsafe, you'd have to store it inside the KDBX, which effectively binds it to a single database.

[ThomasSteinbach]

That sounds clever, as (security relvant) settings could be bound to the kdbx.

Wouldn't that be a point worth to be placed on the roadmap?

[droidmonkey]

It's already there... #2224 and #891

[ThomasSteinbach]

Nice - this matches my third point of possible solutions in my descriptions.

As integrating settings into the kdbx itself would protect the (auto lock) settings when the kdbx is locked itself, this issue would be solved.

I think I gained awareness over this attack vector and a possible solution is on the roadmap with #2646 #2224 and #891. Thus I am closing this (more specific) issue.

Thanks for the discussion.

[droidmonkey]

Agreed, good talk!