Closed vit9696 closed 11 months ago
Screenshot for reference:
This seems to be that the description and response in https://github.com/keepassium/KeePassium/issues/280 are incorrect, and the application needs further auditing in part of what database lock really is.
The issue is also mentioned in https://github.com/keepassium/KeePassium/issues/231#issuecomment-1751789060 (3).
This issue seems to be a security issue to me, perhaps there should be a way to report such issues separately and provide embargo policies. GitHub has something in https://github.com/keepassium/KeePassium/security, but it looks not enabled.
Thank you, @vit9696. I can reproduce the issue.
The reason is that DB locking (and clearing the keys) is driven by the UI. Closing the group list (left pane) should normally replace the right pane with DB unlocker, thus deallocating the DB Viewer and hence the DB. Here this does not happen and the DB remains open.
I will look into this.
Regarding the reporting channel, most security issues so far have been successfully reported via email. This is intuitive enough, I don't really see the need to document this formally.
@keepassium, the issue seems to be only partially fixed. I can still reproduce the locking issue when I have timeout enabled and it expires.
@vit9696 , thanks for the timeout hint. I was struggling to reproduce it, but finally got to the bottom of the problem and fixed the root cause. Hopefully it was indeed the root cause🤞 :)
Description Master key is not removed from memory after the database is locked at least in certain scenarios, and data protection is in fact not working. It is possible to edit and leak passwords after locking database.
How to reproduce Steps to reproduce the behavior:
Expected behavior
Screenshots If applicable, add screenshots to help explain your problem.
Environment: