RowHammer is a category of security vulnerabilities that work by exploiting DRAM that suffers from bit-flips when accessed in particular patterns. It can be used for local privilege escalation; for example a cell-phone app without permissions could use it to take full control of the phone, a server on a shared cloud host could attack other sites on the same host, or in the worst case, a browser Javascript program could break out of the browser (not done in this paper, but done as a proof-of-concept with caveats in one of the papers it cites). The main finding of this paper is that none of the existing mitigations is fully adequate, not even ECC.<p>On the plus side, using RowHammers to make a fully working exploits is much harder than most other types of exploits, and the exploits people have managed to make so far have all involved major caveats (like requiring hundreds of hours of full CPU usage to work, or providing memory layout information that would be difficult for attackers to obtain). Still, the fact that this class of exploit has proven so difficult to fully fix is worrying.<p>There's a section of proposed mitigations at the end, one of which sounds particularly promising, though:<p>> "Kim et al. [38] and Kim et al. [37] proposed to eliminate bit flips in hardware by probabilistically opening adjacent or non-adjacent rows, whenever a row is opened or closed. As an ongoing Rowhammer attack would open and close a certain row repeatedly, the vulnerable adjacent rows would be refreshed before bit flips occur. We consider their approaches as a possible solutions to mitigate Rowhammer attacks in the future."
Software mitigation is not the right way to deal with RAM that can be fooled into flipping bits. All DRAM with this vulnerability should be recalled as defective. We'd certainly demand that Intel fix a vulnerability that let you flip register bits in other processes by doing something you can do from Javascript.<p>There are reasonable defenses possible inside the DRAM. They currently depend on the fact that repeated reads of the same data are rare, because of caches. DRAM should insert a delay after hitting the same row N times between refreshes, depending on its analog parameters. It won't affect performance in any normal application.
<i>Finally, we abuse Intel SGX to hide the attack entirely from the user and the operating system, making any inspection or detection of the attack infeasible</i><p>It's unfortunate that academics feel OK about making misleading statements in this space. SGX enclaves must be signed by Intel to work, so I doubt very much that they abused SGX in this way. What they mean is that they <i>could</i> have done, <i>if</i> they had got Intel to approve their attack, which is a pretty freaking huge caveat.