Row Hammering: Security Risks and Prevention Methods

This morning Google Project Zero – the same team that discovered the Heartbleed bug – published this blog entry, “Exploiting the DRAM rowhammer bug to gain kernel privileges.” 

The blog entry is very detailed so here’s a short summary:

• Some DDR devices have a property called “row hammer” that can cause some bits in DRAM to flip under certain conditions.
• The conditions that cause row hammering are so rare in normal operation that nobody even knew it could happen until relatively recently.
• Some researchers discovered ways of making row hammering bit flips happen more often.
• Google Project Zero reported that user code that has access to unprotected regions of the operating system that link to protected regions of memory may be row hammered to get unprotected access to the whole memory.
• Once a hacker has unprotected access to the whole memory, they can do pretty much anything they want with your system.

Google has tried their technique on 29 machines and found that they could initiate bit flips on 15 of them with some software utilities they wrote to exploit row hammering.

Google may have already patched the Chrome browser to help prevent this issue

What happens next? Well, at a minimum, we’ll probably all need browser and operating system patches to prevent row hammering exploits. It may be possible to program the BIOS in your system to refresh the DRAM more often which could help to reduce the probability that row hammering would work on your system (at the cost of more power usage and lower performance though).

Looking forward to DDR4, Row Hammering may be a thing of the past. Samsung announced in May 2014 that their DDR4 memory would not be susceptible to Row Hammering because they implement Targeted Row Refresh (TRR) – the cure to Row Hammering – inside of their devices: and Micron’s datasheets say, “Micron’s DDR4 devices automatically perform TRR mode in the background.” There’s some evidence that next-generation CPUs will either not be capable of issuing row hammering data patterns, or may mitigate them with TRR, or both.

As always, browse safely and keep your software up to date!

• Some updates since I wrote this post:
  It appears that this may affect primarily consumer machines – those without ECC DRAM. It would be much harder to make this exploit workable with ECC DRAM used in servers and enterprise-class machines. It would be harder still to induce the error in machines supporting ECC patrol scrub. (Note: Synopsys’s uMCTL2 memory controller supports both ECC and ECC patrol scrub)
• Cisco published some useful information on how to mitigate the Row Hammer issue. In that blog entry, Cisco reports that Intel’s Ivy Bridge, Haswell, and Broadwell server chipsets support Target Row Refresh capability.
• IBM has published a list of their machines that are not affected by the issue.
• TechTarget quoted my blog in their report on the issue – an excellent article by Michael Heller.