by J. Edward Durrett
dd if=/dev/sda2 of=/home/jed/swap.img
Just using cat on the image produces a bunch of junk, so running strings on the image and outputting the results
to a file makes it easier to read:
strings swap.img > swap.img.strings cat swap.img.strings|more
To let the computer do the work, refine what is displayed:
cat swap.img.strings|grep -A 50 "BEGIN RSA PRIVATE"|more -----BEGIN RSA PRIVATE KEY----- JN ... CONTENT REDACTED ... 4= -----END RSA PRIVATE KEY-----
Oh, no, what is a private key doing in swap? Any system user with access to /dev/sda has access to this private
key if they look. In this case, we should just assume the key has been compromised, revoke it and issue another.
Why, though, would a private key end up being swapped out?
Generally, programs that handle keys like ssh-agent or gpg-agent use mlock() to prevent pages with sensitive data
being written to disk. In this case, the key was being copied and pasted. When the system needed more RAM, the
private key was written to disk as the page was swapped out. This can be replicated by opening a notepad / leafpad
document, and typing some data. Then, open an image processor such as GIMP and create a document larger than the
available RAM. The contents of notepad / leafpad will then be written to the swap space.
An encrypted swap partition does not solve the problem. While the file system is up, the unencrypted contents of
swap are visible. Of course, on a dead system using a random one time key to encrypt the swap partition, the data
would be very difficult to recover. Also, encrypting swap with random one time keys does provide some protection
as old swap data isn’t unencrypted after a reboot. For a production server that hardly ever reboots, this
small crumb of protection is null.
Copyright (c) 2019, Jason Edward Durrett - All content on this site, unless otherwise noted, is subject to this license.
Please contact me if any errors, such as erroneous / misleading content or missing / incomplete attribution, are found.