Cold boot attacks, used to extract sensitive data such as encryption keys and passwords from system memory, have been given new blood by researchers from F-Secure. First documented in 2008, cold boot attacks depend on the ability of RAM to remember values even across system reboots. In response, systems were modified to wipe their memory early during the boot process—but F-Secure found that, in many PCs, tampering with the firmware settings can force the memory wipe to be skipped, once again making the cold boot attacks possible.
The RAM in any commodity PC is more specifically called Dynamic RAM (DRAM). The "dynamic" here is in contrast to the other kind of RAM (used for caches in the processor), static RAM (SRAM). SRAM retains its stored values for as long as the chip is powered on; once the value is stored, it remains that way until a new value is stored or power is removed. It doesn't change, hence "static." Each bit of SRAM typically needs six or eight transistors; it's very fast, but the high transistor count makes it bulky, which is why it's only used for small caches.
DRAM, on the other hand, has a much smaller size per bit, using only a single transistor paired with a capacitor. These capacitors lose their stored charge over time; when they're depleted, the DRAM no longer retains the value it was supposed to remember. To handle this, the DRAM is refreshed multiple times per second to top up the capacitors and rewrite the values being stored. This rewriting is what makes DRAM "dynamic." It's not just the power that needs to be maintained for DRAM; the refreshes also need to occur.
But that refreshing is double-edged. Memory is typically refreshed every 64 milliseconds, with the individual DRAM cells engineered to retain their value for at least that long under normal operating conditions. But outside normal operating conditions, the situation changes. At high temperatures, the memory needs to be refreshed more often. Cool the DRAM down and it needs to be refreshed less often. Cool it enough and it can go tens of seconds between refreshes.
This discovery formed the basis of the 2008 research and discovery of the cold boot attack: memory from a victim system is cooled to -50°C, and then the machine is abruptly powered off without shutting down the operating system. This frozen memory can be put into a different machine equipped with software to read the memory, or the machine can be rebooted into a different operating system that similarly reads the frozen memory and saves it to disk.
Industry response
The industry response to this attack was to make the system wipe memory early on in the boot process. This doesn't help if someone wants to move the chips to a different machine, but in systems with soldered-down memory it should protect against rebooting into a different operating system and dumping memory that way: by the time the different operating system is loaded, the memory has already been wiped, leaving nothing to dump.
But alas, nothing in the PC world is simple. Naively, one might think that this could be achieved by simply having the machine's firmware or processor automatically wipe the memory every single time the system is initialized. For no particularly obvious reason, that's not the solution that the PC industry chose.
Instead, the solution is something more complex: the operating system would set a special value (the "memory overwrite request," MOR) in the firmware's non-volatile storage that would specify if the memory wipe should occur or not. On booting, the firmware sets the value to indicate that a wipe should occur next boot. The operating system can, however, clear the value to suppress the wipe if it has guaranteed that it has already overwritten sensitive values in RAM. This skips the wipe next boot; the firmware then sets the value again, and the process is continued.
In this way, if the operating system is terminated without performing a clean shutdown (as is done in a cold boot attack), the MOR will still indicate that a wipe is necessary. So booting into the alternative operating system will always force memory to be overwritten first.
Cold boot, rebooted
The new attack takes advantage of this design in a way that seems rather obvious: overwrite the MOR to suppress the memory wipe, then perform a cold boot attack as normal. The system boots up, sees that it shouldn't wipe memory, then loads the attacker's operating system and allows memory to be dumped, including all the encryption keys and other secrets contained within.
The F-Secure researchers say that the attack is effective against typical corporate laptops. In response, Microsoft has updated its BitLocker configuration recommendations to require a BitLocker PIN to start and to disable system suspending (allowing only hibernation, which wipes encryption keys from memory anyway). Apple says that its systems equipped with its T2 security chip are unaffected, because they don't store secrets in main memory at all. Beyond that, however, the researchers say that there's no obvious fix to the problem.
The original specification doesn't seem blind to this problem, either. It says that the value used to determine whether a memory wipe should occur should have its integrity protected to prevent attackers from being able to tamper with it and suppress the overwrite. The success of the attacks suggests that this integrity protection either isn't happening or isn't sufficient to actually protect against attackers anyway.
Why the memory wiping is designed this way is not immediately clear, and the specification doesn't provide much elucidation. The whole memory-wiping process is only meant to be activated when powering on a machine from the S4 or S5 power states (S4 is "soft off," in which everything is powered down except for the front panel power button; S5 is "hard off" with not even the front-panel power button operational). It seems straightforward then to always perform the memory wipe; there should be no harm in doing so.
The only time you don't want a memory wipe is when restoring from the S3 suspend state. In S3 suspend, DRAM contents are refreshed, but the CPU and most other system components are powered down; this provides the combination of quick booting with low power consumption. However, the specification says that the firmware shouldn't ever perform memory wipes when leaving the S3 suspend state, so in this scenario it shouldn't matter what the MOR value is.
Update: So consensus is that the entire MOR system is there as a performance optimization. Zeroing out a few GB of system memory would add a little time to the boot process—a Skylake processor, for example, can only zero out about 20-30GB per second, depending on exact memory speed, so in typical configurations this could add a quarter, perhaps even as much as a half a second to the system's boot time—so MOR was added so that the delay could be avoided. The security problem is just a bonus.
reader comments
66