Keepassxc: Improve and secure attachment handling

Created on 19 Oct 2018 · 9Comments · Source: keepassxreboot/keepassxc

Expected Behavior

When an opened attachment changes in its temporary location, KeePassXC should ask if the user wants to update the KDBX and not silently ignore any changes.
When the application associated with an opened attachment is closed, the temp file should probably be be deleted and when KeePassXC is closed / locked, it should definitely be deleted.
Opened attachments should be stored in a writable AND secure location, not in /tmp. Just setting the mode to 0600 is not very secure since it leaks the filename and the application it's opened in can easily change permissions inadvertently [loosely related to #2283].
There should be an option to save attachments from the details panel [related to #2039].
Attachment files need to be watched by KeePassXC and all read/write locks removed. Currently locks are in place for the duration of KeePassXC running. [related to #5745]

Current Behavior

None of the above.

Debug Info

KeePassXC - Version 2.3.4
Revision: 6fe821c

Libraries:

Qt 5.9.5
libgcrypt 1.8.1

Operating system: Ubuntu 18.04.1 LTS
CPU architecture: x86_64
Kernel: linux 4.15.0-34-generic

Enabled extensions:

Auto-Type
Browser Integration
Legacy Browser Integration (KeePassHTTP)
SSH Agent
YubiKey

high priority security ux

Source

phoerious

👍22

Most helpful comment

A simple solution might be to remove the "open in place" feature altogether. If the user wants to see the file, he can extract the file where and how he wants using the save button, and open it itself under his full control. The usability of this is not much less than auto-extracting it to /tmp.

The primary purpose of keepassxc is to keep information secure. It's not intuitive that "opening" a file extracts it to /tmp at all in the first place, and furthermore, leaves it there. This allows access to the file for anyone with unprivileged access on the user's file-system level.

The user should see and control what's happening with his file if it leaves the encrypted scope, and the cost of usability is negligible compared to the security that it offers.

otto-dev on 31 Oct 2019

👍3

All 9 comments

When the application associated with an opened attachment is closed, the temp file should probably be be deleted and when KeePassXC is closed / locked, it should definitely be deleted.

Above all things this should be prioritized. I think the temp file should be deleted in _all_ instances, including after the opened attachment has been closed.

rpgdev on 25 Nov 2018

👍2

The Open button uses whatever application is associated with the attachment's extension. Are you assuming that all applications will write a single temporary file to a standard location? That all applications will manage memory securely? KeepassXC has an option to clear the clipboard after a certain number of seconds, yet at the same time, you're allowing the user to open a file that they've intentionally safeguarded with, say, an application like Microsoft Word (.rtf) or LibreOffice (.csv)?

socketbox on 6 May 2019

This issue is connected with feature request #3383 .

matjon on 30 Jul 2019

The user should see and control what's happening with his file if it leaves the encrypted scope, and the cost of usability is negligible compared to the security that it offers.

otto-dev on 31 Oct 2019

👍3

I can't believe this is open for more than 1 year. I have 2D PIN Codes for the banks stored as jpg in the keepass file. Original KeePass opens them with an inbuilt viewer, so there is no security loophole as KeePassXC has with copying it to a temp folder.

esackbauer on 13 Dec 2019

This is a rather big problem to address, we had many other initiatives to work through first, including code refactors, to better support a fix for this. This will be addressed in 2.6.0.