Tests with LiME on CentOS. First, KeePassX was set to generate simple searchable passwords, regenerated each time because searches place passwords in memory.
All these were safe (no reveal, and unless indicated I performed the step before starting a LiME dump):
- Generate password within KeePassX, don't finish saving.
- Regenerate password, save password and leave main window open.
- Start memory capture, regenerate password, capture finishes before password timeout expires (subject to timing, but unlikely).
- Regen password, copy to clipboard with KeePassX's copy function, password timeout doesn't expire.
- Regen password, copy to clipboard with KeePassX's copy, start dump; password expires in 10 seconds (dump ends at 30 seconds)
- Regen password, copy to clipboard by hand with Ctrl-C, start dump after timeout expires.
- Regen password, copy to clipboard by hand (Ctrl-C), timeout not expired.
- Regen password, save, then leave [Show Password] active during dump.
- Regen, copy and paste from KeePassX to GNote.
- Regen, copy and paste from KeePassX to Firefox + Gmail password entry field.
- Regen, show password, type manually into Firefox + Gmail password entry field.
I had one fluke detection, probably an error. A real detection was a manual attempt to queue a search command while waiting for the dump to finish: This injected the password into memory.
To your questions:
There's ample time to use Volatility with copied memory + encryption keys but physical access is often harder. Most people (in my opinion) need not worry about their hardware too much. Yes, there's low-level I/O, BIOS upgrades, BadUSB, Thunderstrike, ultrasonic communication, even modifications to hard drive firmware; all making the news but most often of narrow scope.
Clipboard managers or lower-security programs than KeePassX are more of a concern and shell interaction actually looks like the smoking gun (especially with tab completion, searches and command queueing).
My cleartext sudo password persists in memory if I elevate, but I do it a lot. To emulate low use, here's a test from a new account, starting from root (fewer opportunities for sudo). I did not search between memory dumps, trusting KeePassX to protect the passwords as above:
# adduser keepasstest
# su keepasstest ' user is working
# passwd keepasstest
Changing password for user keepasstest.
New password: ' paste from KeePassX
Retype new password: ' paste from KeePassX
passwd: all authentication tokens updated successfully.
# exit ' dump memory #1
$ sudo -s ' my account
# su keepasstest ' substitute user
$ sudo -s ' elevate
[sudo] password for keepasstest: ' Paste from KeePassX
# ' dump memory #2
$ sudo grep Ifnavcogi... lime*.txt
lime1.txt:Ifnavcogi... ' 3 entries after passwd
lime2.txt:Ifnavcogi... ' 5 entries after sudo
15 minutes later at least one password is still present in dumps, even after sudo's cached timeout expired; the rest come from my browser's memory.
Another concern, though KeePassX does lock pages to keep them from swapping to disk (ps -axu will show "L" in its flags) that no longer matters if you hibernate the system and don't use good full disk encryption.
It appears the password is in several places outside of KeePassX when I use sudo (regardless of how I get there). But live memory dumping needs elevated permissions...like the level required to place malware on your system, or to replace your hardware, or to gain the physical access necessary to copy your memory. I don't like the cleartext passwords, but the risk still seems average.