Understanding Rowhammer

As I learned in my early days in electronics, every wire is an antenna. This means that a signal in any wire, given enough power, can be transmitted, and that same signal, in an adjacent wire, can be received (and potentially decoded) through electromagnetic induction (Rule 3 may apply). This is a major problem in the carrying of signals through a wire, a phenomenon known as cross talk. How do communications engineers overcome this? By observing that a signal carried along parallel wires at opposite polarities will cancel each other out electromagnetically. The figure below might help out, if you’re not familiar with this.


This canceling effect of two waveforms traveling a pair of wires 180deg out of phase is why the twisted is in twisted pair, and why it’s so crucial not to unbundle too much wire when punching down a jack or connector. The more untwisted the wire there is, the less effective the canceling effect is around the punch down, and the more likely you are to have near end or far end crosstalk.

If you consider one row of memory in a chip one wire, and a second, adjacent row of memory in the same chip another wire, you can see how rowhammer works. Chip makers have reduced the size of their dies by learning how to compensate for the induction between lines of components; some of the compensation must, for practical reasons, come from assuming (at least) moderately random reads and writes. What happens in rowhammer is the writes are not random — they are intentionally fixed, causing a constant “build” in the electromagnetic inductance between rows of memory. If the row adjacent to the hammered row happens to contain some critical data structure, then, over a few rounds of “pumping power into the transmit circuit,” you can have an effect on the receiver, thus making it possible to flip a bit.

In reality, this bit of information isn’t all that interesting. Anyone with a moderate background in electronics could work this out. What’s interesting is using internal structures to discover what specific bits of memory are crucial to the security of the system under attack, and figuring out how to place your malloc() in a position so it specifically resides within the inductive radius of the targeted memory row. This, in short, is a masterpiece of combining the electronics, the discovery of sysinternals, and the coding skills required to put the right information in the right place at the right time.

The most frightening thing about this attack is it can be done to just about any system, from routers to cell phones. With enough information about the way the system is structured, combined with enough information about the physical memory itself, anyone can flip the right bits in any system’s memory to compromise it. By extension, this same sort of attack can be performed from outside a computer, using directed signals of various types. Just like computer memory can be read through a power line or remote reading of the information on a CRT, computer memory can be modified from outside, as well. In fact, it already has been done.

If you want more information on the rowhammer attack from an academic perspective, read this paper — it’s well executed and readable.

As an interesting aside — I had a chat with an uncle who delves deep into tapeouts and chip design, and he pointed out that all memory chips have some number of bad rows that are blocked during packaging. In fact, it’s part of the six sigma process to drive the die size down until you reach some percentage of failed rows on a DRAM chip, which has been overbuilt from the beginning for a particular failure rate. The point he made was that the attack may well not work on every DRAM chip because the row the attack is “hammering” may not be close enough to the row being used as a “hammer” to succeed in every case.

Given, this attack, though, what do we do about it?

Finding an answer isn’t quite so simple as formulating the question. A number of answers present themselves. Foremost, perhaps, is learning to store information crucial to the security of a system in some sort of memory that doesn’t interact with any user accessible memory in any way. Or perhaps storing such things in a more “hardware/hardwired” way. Or to simply slow down, and figure out how to expand the die sizes so we don’t store so much stuff in such a fragile environment. From a personal perspective, we need to learn to store information more off line, and less on line. To rely on portable gadgets to get us by less, rather than more.

My guess is, though, that we will do next to nothing about it for a long time to come. We’ve come to the point, culturally, where we seemingly willingly give up control over our lives for that last little bit of convenience. Rowhammer shows us that every system is potentially insecure. The reaction to that revelation must be cultural as well as technical — but are we serious enough about security to truly address this type of issue?