12

How can I ensure that the whole RAM was zeroed-out? Does a reboot (Power On Self Test) clear whole memory before system is booted? Or does a Linux kernel zero memory before proceeding?

I am familiar with cold boot attack and TRESOR countermeasure. I am merely interested in other, less elaborate ways of clearing memory.

Anders
  • 65,052
  • 24
  • 180
  • 218
ArekBulski
  • 332
  • 1
  • 2
  • 11
  • 1
    Related question: http://security.stackexchange.com/questions/10643/recover-the-prior-contents-of-ram-from-a-turned-off-pc?rq=1 – Mike Ounsworth Apr 22 '15 at 23:56
  • Great question. I wonder if any motherboard vendors include a memory wipe in their POST. Even if they do, it doesn't protect against me yanking out your power cable, ripping out your RAM sticks and quickly putting them into my machine. – Mike Ounsworth Apr 23 '15 at 00:03
  • Putting a physical lock on your case, and a password on BIOS (if supported) seem like they would stop most attack vectors for a Cold Boot Attack. – Mike Ounsworth Apr 23 '15 at 00:07
  • @MikeOunsworth No, [FireWire/DMA attack](http://www.hermann-uwe.de/blog/physical-memory-attacks-via-firewire-dma-part-1-overview-and-mitigation) would defeat that and probably even TRESOR. – ArekBulski Apr 23 '15 at 05:30
  • Fair point about FireWire/DMA attacks. Another reason not to buy a machine with firewire ports :S – Mike Ounsworth Apr 23 '15 at 12:08
  • Firewire can have its DMA capabilities disabled. I believe the Linux Firewire driver does this by default (requiring you load the module with a specific parameter to re-enable it). Windows disables DMA over Firewire whenever the screen is locked. – forest Mar 01 '18 at 06:01

5 Answers5

16

During the POST, the BIOS traditionally performs a "memory test" which entails writing to and rereading the whole of the physical RAM. However, this process can take a non-negligible amount of time, and is rather bad at detecting bad memory (it reliably detects only very bad memory) so it is disabled in many cases (by the computer vendor, or the user). Thus, one must assume that scraps of the RAM contents prior to the last boot may still linger; how much data thus remains depends on the RAM technology, the power down time before the new boot, and the temperature.

The Linux kernel, like most other modern operating systems (including Windows, excluding the Windows from the "95" line), zeroes out the RAM pages before handing them to applications. Thus, while physical RAM contents might contain interesting remnants of past data, this is accessible only to kernel code; userland only sees zeros.

Thomas Pornin
  • 322,884
  • 58
  • 787
  • 955
2

On Tails it does!

Other than that I am not aware of any other popular operating system that does this by default, so if someone inserted your RAM sticks into some kind of OS written for the purpose of snooping your data (it would likely have to be an essentially bespoke kernel to avoid any RAM write operations) they would be able to get all that sweet, juicy memory.

Thanks to Thomas Pornin for the tip that user-mode applications cannot access raw RAM.

ArekBulski
  • 332
  • 1
  • 2
  • 11
user1535427
  • 56
  • 1
1

Reboot no, not anymore.

Today systems are designed to be able to sustain the RAM content very well for stand-by/sleep/hibernate or any type of suspended states and for other purposes like persistent RAM disks. Unless the software does special things to clear RAM content (like TrueCrypt does if you run truecrypt /wipecache), the data will still be there until overwritten.

As for a disconnect-from-power procedure, then yes, the RAM content does clear, quite fast for DDR3 and above, so it practically becomes blank unless the system is designed with some sort of integrated backup battery (like for some storage systems or servers).

Now if you intentionally want to wipe RAM without resulting to barbaric means like unplugging, you could boot up a memtest and it will clean it very nice for you.

I also used on early operating systems a different way for testing purposes: I have a test-file (with random data or just one character repeating), as large as the RAM of the system. I open it for editing with an editor that loads the whole file into RAM. At a point, there will be out-of-RAM error. I close the editor and continue my work.

Overmind
  • 8,829
  • 3
  • 19
  • 28
  • Memtest is actually not a very good solution here. It tends to wipe memory much more slowly than it would otherwise, as it writes (and reads) individual address ranges multiple times in a row. This is much slower than simply overwriting memory (i.e. it can take _minutes_ or more to finally get to the last address). A real solution would be to boot into an initramfs which fills free space with `smem`. This is similar to the technique used by Tails. Kexec can boot an alternate initramfs in an instant without actually needing to reboot. – forest Mar 01 '18 at 12:21
  • Yes, but it's a thing easy to get. My solution, as I said, was as simple as booting an MS-DOS and editing a large file. It does work significantly faster than memtest. – Overmind Mar 03 '18 at 08:36
  • Wouldn't it be faster to just shut down? Memtest takes several minutes to hours to get all the addresses, whereas shutdown takes a second to several seconds. – forest Mar 04 '18 at 02:51
1

On virtual machines it seems memory isn't cleared. In IncludeOS (includeos.org) we use this to store crash data in memory (as the IP stack and IO system might not be functional) and pick up the crash report after rebooting the system.

We've tested this on qemu/kvm and Vmware ESXi. We have not tested on bare metal.

perbu
  • 111
  • 2
  • Could you elaborate on what includeos.org does an why it is important in this context? Also: are you affiliated in any way with includeos.org? – Tom K. Mar 09 '18 at 10:10
  • IncludeOS is an OSS library OS. Yes. I am affiliated (which is why I say "we"). The question is compounded and my answer is towards "Does a reboot ..." and the answer seems to be no. The rest is to substantiate why I believe it isn't so and how we actually use this behavior. Feel free to delete the answer if you feel it ads no value. I find that this behavior is very weakly documented. This is one of very few pages discussing this. – perbu Mar 10 '18 at 14:38
  • I appreciate this answer -- IncludeOS is a very interesting project and this is a very interesting edge-case behavior. – Reid Rankin Jun 06 '20 at 01:16
0

Memory is not cleared on reboot (tested on Macbook). You can check this trivially under Linux by running a program, rebooting so that the program is no longer running, and then grep in /dev/mem for the hash of strings contained in the program memory. For example:

  • Run XFCE and thunar file manager
  • Reboot in to single user mode (no GUI, no desktop)

  • Login as root then

    # sums=$(strings /dev/mem | while read s; do echo $s | sha256sum; done)
# echo "${sums}" | grep 79b4f11b6ccf3a7c397fbfd032672c65d825bdb38eae1aa445183b0b3934be6b

This calculates the sha256 checksum of all the strings in memory. The checksums are then grepped for the sha256 checksum produced by echo THUNAR_ZOOM_LEVEL | sha256sum. THUNAR_ZOOM_LEVEL is a configuration string from /usr/bin/thunar (thunar is a file manager for the XFCE desktop). Since this Linux boot was in single user mode, Xorg will not be running, and no X apps will have been started, so this string does not come from the current boot. The Xorg application strings in memory were retained from the previous boot.

If you dump /dev/mem with dd or run strings on it you will see the memory from all the graphical programs that were running in the GUI - programs which were running before the reboot but aren't running in single user mode.

bain
  • 231
  • 1
  • 5
  • Your `grep` example, at best, proves absolutely nothing. If `THUNAR_ZOOM_LEVEL` wasn't in memory by the time `grep` is running, then how would `grep` be able to search for it? Where would the shell keep the command line history? I'd expect any string passed as a command-line argument to a process to occur at least at a few places in memory by the time that process is running. – user Mar 01 '18 at 15:47
  • @MichaelKjörling _"If THUNAR_ZOOM_LEVEL wasn't in memory by the time grep is running, then how would grep be able to search for it"_ - because thunar is not run in this boot, but the memory is not cleared on reboot, so strings from the previous boot are still in memory. That was the point of the example - rebooting in to single user mode ensures that thunar will never have been run on this boot (in single user mode there is no GUI, Xorg isn't even started, X apps aren't started). And yet, grep showed that there was a string from /usr/bin/thunar retained in memory from the prior boot. – bain Mar 02 '18 at 10:10
  • 2
    *"strings from the previous boot are still in memory"* So are the command line parameters you're passing to `grep`. – user Mar 02 '18 at 10:15
  • @MichaelKjörling I've updated the example to address your concerns. – bain Mar 02 '18 at 10:44