Scary exercise

26.12.2010 21:19

Try this on a computer you use often:

# export HISTFILE=/dev/null
# grep secret /dev/sda /dev/sdb
Binary file /dev/sda matches
Binary file /dev/sdb matches

Substitute secret for a secret password that should never be stored in clear text in any persistent storage. For instance your system account password, disk encryption key, GPG private key passphrase, etc. Note that entering your secrets on the command line like that has dangers beyond Bash history logging, so it's only safe to do this experiment with a password that you just changed.

If grep returns no hits, great. Your secret is safe from this particular attack. In my case however the fun part was in finding out why exactly the password that supposedly never leaves volatile RAM appeared in clear on all of the computer's hard drives (and the machine in question doesn't even have swap enabled).

Posted by Tomaž | Categories: Code

Comments

Hi there,

Nice blog.

http://zanetworking.wordpress.com/2008/08/01/is-your-ram-chained-to-your-servers/ may be of interest to you I made mention of some cold boot attacks as well.

Posted by zanetworking

Thanks for the link. Yes, cold boot attacks are pretty real, but it's not something you can easily fix. At the moment at least I think they are not something worth worrying about. It's not like there are people walking around with liquid nitrogen waiting to freeze my laptop.

Posted by Tomaž

Hello,

Thanks for this post (and blog!).
My PC has the same problem: my google password is in fact in the disk, but I could not figure out why - no files match it.
Any hints?

Posted by Antoine

Antoine, that means the password was once written to a file that was later deleted or modified. Data from a file usually persists on the drive until the OS decides to reuse the blocks that were once allocated for it.

Posted by Tomaž

Is there a way to visit all 'unused' blocks and write a shred like sequence on it?
I also have a binary password match, i would like to remove this match without having to shred the whole disk after moving all data, and after the shred moving it back again.

Posted by klaas

You just need to fill the filesystem to capacity with garbage. Do something like "dd if=/dev/urandom of=garbage", wait until it runs out of free space then delete the "garbage" file.

Posted by Tomaž

Add a new comment


(No HTML tags allowed. Separate paragraphs with a blank line.)