5

I use to copy and paste my sudo password from a KeePass file so I guess the plain text user password will be saved in RAM at some point when I use it, for example, to accept an update. Is that right?

Would it be theoretically possible for an attacker to extract this password string or a part of it by connecting the RAM to another machine (for example Cold Boot Attack)? Could the attacker then reconnect the RAM to the first still running machine and enter the user password to unlock the screen for example?

Would it make a difference if I typed in the sudo password with my keyboard every time I need it? I think simple keystrokes are not being saved in RAM, right?

Another option to prevent this would be a custom screenlocker password, I guess.

Junior J. Garland
  • 677
  • 5
  • 15
  • 2
    You can test this yourself with the LiME kernel module. I have it installed and indeed see my own passwords in memory, long after I use them. Your specific question (for which I have a similar setup) I haven't had a chance to check; if I find it I'll come back with an answer over a comment. – ǝɲǝɲbρɯͽ Apr 28 '15 at 23:09
  • Each character you type is stored in RAM at least temporarily. Additionally the sudo command will store the entire password in RAM until you press enter. After you have pressed enter, any RAM that has been used for the password should be immediately available for reuse. I know of no guarantees about how quickly that RAM will be reused (and overwritten), but it is likely that at least part of it will only be overwritten by typing more characters. – kasperd Apr 28 '15 at 23:32
  • @kasperd Anybody know if `sudo` zeros out the `char*` that stored the password before it's `free()`'d? – Mike Ounsworth Apr 28 '15 at 23:34
  • 1
    @MikeOunsworth It might. I don't know if that's the case. Other layers of code are involved as well, and not all of those layers even know that what is being typed is a password. Based on that I would find it unlikely that every layer in the stack would wipe the password soon. – kasperd Apr 28 '15 at 23:41
  • 1
    @MikeOunsworth From what I've been able to determine, the sudo password is one of the most persistent. I noticed this earlier but have actually been running LiME sudo. I'm running a few other tests, since this came up. – ǝɲǝɲbρɯͽ Apr 29 '15 at 00:10
  • @ǝɲǝɲbρɯͽ Can you expand on `LiME sudo`? Is LiME a memory analysis tool? I'm having troubles finding info on it. Thanks. – Mike Ounsworth Apr 29 '15 at 23:08
  • @MikeOunsworth I mean: "as" sudo, likely seeding my own passwords as part of starting The Linux Memory Extractor (https://github.com/504ensicslabs/lime). It's a pre-analysis forensics tool for point-in-time raw memory snapshots, not live analysis (another use case). A LKM you build and insmod, it's unrestricted by userland, works on distros that phase out vulnerable special memory devices, and won't overwrite memory pages (other tools can, defeating this use case). Analysis for captures is available via other free tools: Volatility, Mandiant RedLine?, etc. Google: "Lime forensics" – ǝɲǝɲbρɯͽ Apr 30 '15 at 14:50
  • Would lime show if the system encryption key is still in RAM? – Junior J. Garland May 06 '15 at 12:05

2 Answers2

6

Yes. In fact this is a common feature of keyloggers. They will often take screen captures every X seconds, monitor the clipboard, and log key strokes. These features pretty much defeat your strategy of typing rather than copy/paste.

However you mention you're using keepass. So you may be protected. Take a look at this information from their FAQ

Because we are heavily using the clipboard, it is useful to block all current clipboard monitors. This means that no other applications will get notified when KeePass changes the clipboard.

For this, an invisible window is created and added to the top of the clipboard event handler chain. This window simply throws away all clipboard change messages it receives, practically blocking all other applications from receiving any events.

It also details another feature to defeat keyloggers:

The Auto-Type feature of KeePass is very powerful: it sends simulated keypresses to other applications. This works with all Windows applications and for the target applications it's not possible to distinguish between real keypresses and the ones simulated by Auto-Type. This at the same time is the main disadvantage of Auto-Type, because keyloggers can eavesdrop the simulated keys. That's where Two-Channel Auto-Type Obfuscation (TCATO) comes into play.

TCATO makes standard keyloggers useless. It uses the Windows clipboard to transfer parts of the auto-typed text into the target application. Keyloggers can see the Ctrl-V presses, but do not log the actual contents pasted from the clipboard.

The bottom line, as you may gather, is that as new attacks arise so do new defenses (and vice versa).

KDEx
  • 4,981
  • 2
  • 20
  • 34
  • 1
    I would just want to add a warning against clipboard manager software which are installed by default on some PC (including well known Linux distributions) and are logging in background the clipboard content (for instance the 20 latest values). They are discrete, enabled by default, and will just own a listing of all the most used KeePass passwords, annihilating Keepass efforts to securly erase clipboard content... – WhiteWinterWolf Apr 29 '15 at 10:35
2

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:

Terminal 1:
========================
# adduser keepasstest
# su keepasstest            ' user is working
$ exit
# 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

Terminal 2:
=====================
$ sudo -s                        ' my account
# su keepasstest                  ' substitute user
$ sudo -s                        ' elevate
[sudo] password for keepasstest:  ' Paste from KeePassX
#                                ' dump memory #2

Results:

$ sudo grep Ifnavcogi... lime*.txt

lime1.txt:Ifnavcogi...
lime1.txt:Ifnavcogi...     ' 3 entries after passwd
lime1.txt:Ifnavcogi...

lime2.txt:Ifnavcogi...
lime2.txt:Ifnavcogi...
lime2.txt:Ifnavcogi...     ' 5 entries after sudo
lime2.txt:Ifnavcogi...
lime2.txt:Ifnavcogi...

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.

ǝɲǝɲbρɯͽ
  • 429
  • 2
  • 8