Cold Boot Attack Tools for Linux

If you have used a computer for any reasonable length of time, you've learned about the difference between RAM storage and hard drive storage. Besides the fact that RAM is faster than hard drive storage, we also typically think that anything stored in RAM lasts only until the computer loses power, while data stored on a hard drive persists even when the computer is unplugged. Anyone who has lost power while working on a school assignment can attest to the temporary nature of RAM storage.

It turns out that what we have learned about RAM isn't entirely true. On February 21, 2008, a paper titled “Lest We Remember: Cold Boot Attacks on Encryption Keys” was released. In this paper, the researchers describe their discoveries about RAM persistence and how they can be exploited. The researchers found that RAM isn't automatically erased when it no longer has power. Instead, RAM degrades over time, and even after a few seconds without power, you still can recover a significant amount of data. They also found that if you chill the RAM first, using liquid nitrogen or even a can of compressed air turned upside down, you can preserve the RAM state for more than 30 seconds up to minutes at a time—more than enough time to remove the RAM physically from a machine and place it in another computer.

By itself, although this discovery is surprising, what's most interesting are some of the implications if RAM contents can survive a reboot. It turns out that a number of common disk encryption tools for Windows, Mac and even Linux all store encryption keys in RAM. With this cold boot attack, if people lock their screens or even suspend their laptops, you could pull the power, grab the RAM contents and scrub it for any encryption keys. Essentially, you could compromise all of the common disk encryption techniques if you had a few minutes alone with a computer.

When I heard of this discovery, the first thing that came to my mind wasn't encryption, but forensics. I've written previously about forensics in Linux Journal [see “Introduction to Forensics” in the January 2008 issue], and in that article, I discuss the debate over how to respond initially when your server has been hacked. One school of thought favors instantly pulling the power on a compromised server. The idea is that you want to freeze the filesystem in place and don't want to risk that the attacker, or even the investigators for that matter, will destroy evidence. The other school of thought believes that pulling the power would destroy a lot of valuable data that exists only in RAM, so one should gather data from RAM first and then pull the power. With this cold boot attack, now you don't have to make that choice. If a server has been compromised, you can pull power first, and then reboot and grab the contents of RAM.

In the paper, the researchers not only outlined the cold boot attack, they also described tools they had created to take advantage of this flaw. On July 16, 2008, the complete source code for these tools was released to the public at citp.princeton.edu/memory/code. In true UNIX style, each of the tools are small and single-purpose:

Since the source for all of these tools was released, you can download and use them yourself without too much setup. First, go to citp.princeton.edu/memory/code, and download the latest version of the bios_memimage tarball, or the efi_netboot tarball if you want to image a machine that boots with EFI. Then, unpack the tarball. For my examples in this article, I use the bios_memimage package.

The bios_memimage package contains a doc directory with good documentation on the project and how to build and use the source. The tools support both 32- and 64-bit environments. Although the 32-bit version technically will work on a 64-bit system, it can't address all the 64-bit environment's memory space, so you might not get a complete image. To build for a 32-bit environment, enter the bios_memimage directory and type make. To build for a 64-bit environment, enter the bios_memimage directory and type make -f Makefile.64.

Note: I noticed when I compiled the code on my environment, the build errored out with an undefined reference to __stack_chk_fail. This is due to GCC's new stack protection. As a workaround, edit the pxe/Makefile file and change the line that reads:

CFLAGS= -ffreestanding -Os -Wall -I../include -march=i386