What are the security implications of "Row Hammer" attack?

Question

I just found out about the Row Hammer attack. Based on the description, this sounds extremely dangerous, but I wonder what percentage of devices are actually affected by these. Are there any ways to protect oneself other than replacing RAM with one that supports ECC?

Answer 1

The basic security implication is that an unprivileged user can elevate their access to root/kernel level.

Google's Project Zero tested 29 different laptops manufactured between 2010-2014 inclusive, and found that 15 were vulnerable and 14 were not. They do warn that this sample size is not enough to be considered representative, but it is still suggestive that this is unlikely to be an isolated problem.

The original Flipping Bits in Memory Without Accessing Them paper suggests that the problem is much wider:

Among 129 DRAM modules we analyzed (comprising 972 DRAM chips), we discovered disturbance errors in 110 modules (836 chips). In particular, all modules manufactured in the past two years (2012 and 2013) were vulnerable

The only real way to mitigate the attack is to not run arbitrary binaries on your system, and to not allow anyone else to access your system if they might have hostile intentions. This is obviously a problem for shared computing resources e.g. universities, hosting facilities etc. Cloud providers could potentially be vulnerable (successful memory corruption from inside VMs has been reported, but it remains to be seen how exploitable this is).

Using ECC, whilst not a guarantee of security, might lower the probability of successful exploitation. The full mitigation is to update to a system that employs some defence - either a memory controller or DRAM that actively detects and avoids the exploit. Availability of such controllers or DRAM right now is unknown, but they are known to exist. Memory manufacturers have been aware of this problem for a while, and the specification for LPDDR4 includes mitigations, so future laptops will be protected.

Answer 2

ECC RAM is not necessarily immune; ECC memory reliably fix one-bit flips and detect most two-bit flips, which makes the attack harder, but not conceptually infeasible.

Non-ECC RAM is not necessarily weak; in fact, as per the definition of how RAM should behave, no single bit flip should ever happen. What we are talking here is RAM with a defect: the RAM does not work like it should. The depressing fact is that such defects are a lot more common than usually assumed, since, under normal conditions, such defects are not triggered often (or at all).

Solution is to get non-defective RAM. The underlying issue then becomes: how will we detect that RAM is defective ? The well-known MemTest86 tool includes a "row hammer" test (since at least v6, available in the free version).

---

For a software-only solution, one could imagine a "manual refresh" done by the kernel. Some kernel thread would regularly do the following, for all pages in physical RAM:

• Lock the page (i.e. mark it non-accessible for userland code).
• Flip all the bits in the page, ensuring a cache flush with the relevant opcodes.
• Flip all the bits again, again with a cache flush. This restores the original data in the page.
• Unlock the page.

If userland accesses the page while it is being refreshed, the trap handler simply waits for the refresh to complete, then jumps back to the process so that it may try again.

The double-flip is meant to ensure that even smart hardware that tries to follow actual modifications will flush the data and thus rewrite the page (which will refill the potential wells in the DRAM chips).

To a large extent, this process would mimic what hardware already does for memory refresh. Then it would be a matter of deciding how often this should be done; refreshing more often means more CPU / RAM bandwidth spent on the refresh, so there is a trade-off. Whether an acceptable trade-off can be achieved depends on how much RAM there is, how fast the RAM is, and how defective the RAM is.

Implementation in any given operating system is left as an exercise to the reader. I presume this may have non-trivial impact on the paging/swap heuristics (when paging or swapping, the kernel tries to evict pages that have not been accessed recently, and this accounting is done by the MMU itself; the "refresh thread" will play havoc with this information gathering).

Answer 3

I had been working on DRAM for many years, here is some of my points. As I know, there are a lot of researches trying to solve this problem and some of them claim have solution. But as what I see, most of them do not have a full protection. So, it might be a big bomb in the computer world if some hacker able to make successfully to trigger this bomb. It is not only DDR-3 and manufactured between year 2012-2013 are vulnerable. Actually it can be happen on all DDR-3 and even DDR-4. The problem is caused by higher density of today’s DRAM chips. The data stored in each cell cause the nearby cells to change its contain when doing a lot read on the same cell. To increase the Refresh is not going to solve the problem, it just reduce the chance of being hit. But it also increase the system heat and slow down the process power. In fact, when this happen, it becomes more vulnerable to Row Hammer hit. So, increase Refresh Rate is not a good solution. ECC is not going to solve the problem, it just make it more difficult to make it happen, because ECC only can correct 1 or 2 bits error. Sorry, I haven’t see any good solution yet, but I will post here if I know it.