Slashdot Mirror
Exploiting the DRAM Rowhammer Bug To Gain Kernel Privileges
New submitter netelder sends this excerpt from the Project Zero blog:
'Rowhammer' is a problem with some recent DRAM devices in which repeatedly accessing a row of memory can cause bit flips in adjacent rows. We tested a selection of laptops and found that a subset of them exhibited the problem. We built two working privilege escalation exploits that use this effect. One exploit uses rowhammer-induced bit flips to gain kernel privileges on x86-64 Linux when run as an unprivileged userland process. When run on a machine vulnerable to the rowhammer problem, the process was able to induce bit flips in page table entries (PTEs). It was able to use this to gain write access to its own page table, and hence gain read-write access (PDF) to all of physical memory.
Don't have much more to say than that's an impressive exploit.
is this possible to exploit on an iPhone?
It's not a typo if you understood the meaning!
Geez, who knew that writing 'NSA' to 0xdeadbeef over and over would give you kernel access? Those NSA guys really broke into everything.
Yet another reason to push shared providers for ECC memory. The error correcting memory is so far not vulnerable to this attack, all the researchers that have tried it report that ECC memory identifies and corrects the corruptions. Of course some attackers may have found a way, but ECC minimizes the risk
Amazon says it uses ECC in their AWS machines, but other big hosts like Equinix say that ECC memory is "available". Be careful about your hosting, folks.
//TODO: Think of witty sig statement
sopuM sn I ssupoo u
It is worth noting that the row hammer issue isn't new. It as been known about for some time. Including this old Slashdot post
http://hardware.slashdot.org/s...
There has been an implementation of row hammer testing in MemTest86 V6.0 for over 6 months now as well. MemTest86 implements just the single sided hammer, whereas Google used a double sided hammer.
http://www.memtest86.com/
While the double hammer might produce more RAM errors, this pattern of memory accesses isn't very likely to occur in real life software. So is of limited use as a RAM reliability test.
What is new in this report is the fact that they manipulated the RAM bit flips to turn them into an exploit. Something that was previously speculated on but considered too hard to implement.
What they didn't show however is any results from desktop machines. All their testing was on laptops. In fact they state, "We also tested some desktop machines, but did not see any bit flips on those". So the problem isn't as grave as it might at first appear. They speculate that ECC RAM blocks the bit flips and this has also been the experience with MemTest86, most (but not all) of the flips are single bit flips, which ECC would correct.
Disclaimer: I'm one of the MemTest86 developers.
This problem is remarkably similar to a problem I encountered in the memory of a 7094 (old
IBM computer) which had a core memory which stored 36-bit words. The memory was supposed
to work by operating on 6 bits at a time at 200 nanosecond intervals. The reason for this was to avoid
creating a magnetic field that was too strong. The problem occurred when the timing was off due
to failure of a component and two of the intervals overlapped. This meant that when one attempted
to store a word with 35 1s, the field created was strong enough to store 36 1s. We wrote a
diagnostic to demo the problem, and with that the engineers were able to isolate and fix the problem
in short order.
I got First Post!!!!!!! Yippppppeeeeeeee!!!!!!!!
And I don't even know what a DRAM rowhammer is!!!!!!!!!!
Dude, guess what? We row-hammered you into second place. Now excuse me while I flip you the bit. :-)
Crumb's Corollary: Never bring a knife to a bun fight.
Multi-threaded programs really do need those cache flushes to implement their interprocessor communications, don't they? It seems to me that they would be the ones most likely to hit this problem.
Bruce Perens.
Here is the link to the earlier slashdot discussion on this prevalent hardware bug. The original paper suggested the possibility of exploit.
As if there aren't enough things to take into consideration regarding security and exploits. Now we have to worry about faulty hardware design as well. Yikes!
In reality this would be difficult to exploit on a server since servers typically use ECC memory. ECC memory can typically detect two bits and correct one bit error and will likely catch this unless you can flip enough bits correctly so that the ECC remains correct. Doing this means that you would need to know the contents of those memory locations prior to flipping the bits.
I don't know about X86, but on the CPUs my company makes we support hardware address randomization, so that the address lines going out to memory are randomized such that finding adjacent rows or columns can be very difficult to figure out.
It's a shame that Intel only supports ECC memory with their XEON processors rather than all of their processors. ECC does not add much in terms of cost, only 12.5% more DRAM chips and a few more traces and a few other miscellaneous parts (resistors, capacitors). Even the lowest end processors my company makes (for things like small routers, wireless access points, etc) supports ECC and address line randomization.
This post is encrypted twice with ROT-13. Documenting or attempting to crack this encryption is illegal.
...is no physical memory, at all. The processor is simply as wide as necessary, so if your program and data is 100 megabytes large, then you need a 800 megabit processor, or a processor with 100 megabytes of register. Yes, thank you.
So I'm not (quite) a paranoid nutcase for running server-class hardware, including always using ECC DIMMS. Current desktops are older Dell T3500s, with nearly top bin Xeons, upgraded supplies and graphics, plus, of course, 24GBytes of ECC RAM.
First big splurge on a desktop had a Tyan mainboard with the ServerWorks chipset (since Intel's were pathetic, at the time), dual P-IIIs, PCI-X, PLUS an AGP slot. Awesome, for its time.
http://www.tyan.com/archive/l_chinese/html/pr01_s2567.html
All RAM on PCs used to be parity RAM until Wang started suing RAM manufacturers in the 90s over its patents on parity SIMMs.
Weird how most bug exploits result in pretty much every OS reacting with: "I don't know what you want, so here's the keys to the kingdom! (escalation)" instead of: "I don't know what you want, so I'm jumping out of the window and taking you with me! (system crash)."
I've followed the PC market since the 1970s. I was paying a good bit of attention to memory cost. As far as I could tell, people noticed that parity RAM hardly ever caught errors, and that non-parity RAM was cheaper than parity RAM. Parity became optional, then eventually went away entirely, simple because it was marginally more expensive.
Patent issues came and went, but I don't think they were a major driver away from parity.
I just tried this on my older AMD Phenom(tm) II X4 965 server with 32GB non-ECC DDR3-1333 (I think) Kingston memory. Unfortunately, the datasheed does not list refresh cycle length. No results in 200 test-cycles. I did not see any description on how long the test was run in for the table in the referenced article, but 200 cycles are about 15 minutes on my machine.
This has me wonder whether this may be a problem more common in laptops, where refresh-cycles may be set to longer intervals to save power. Refresh is a significant power-consumption source for DRAM and it stays at full power even when the CPU sleeps (otherwise the memory loses its contents). At the same time, the longer the refresh cycles, the weaker the bits in the cells get before refresh and hence the larger the risk of rowhammer to succeed. Maybe some laptop or memory module manufacturers have gone into unsafe territory here? On a desktop system, refreshing faster does not matter, the power consumed is small and the loss in performance minuscule. Hence more aggressive refresh actually increases system stability. But on a laptop things are different, and even saving 1W on refresh can make quite a difference.
Does anybody know of a tool to manually change DRAM refresh-intervals on Linux/x86? The only thing I know off would be manipulating the SPD EEPROMs or going into the BIOS and changing them there if the BIOS setup supports it.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
I agree on the settings. This may be why laptops could be a primary target: Refresh consumes the same power even when the CPU is idle or asleep, hence there is incentives to space it as wide as possible. On desktop and server systems it hardly matters if the RAM consumes 1W more or so, but it does matter for laptops, especially when going into hibernation. At the same time, refreshing slower under hibernation does not make sense, (well, unless you know about rowhammer) and hence laptops may often be more susceptible to this problem.
As to bypassing caches, that is not a problem if you have a large enough memory area to play with. You do not even need root permissions for that.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Unfortunately, it will not. It just makes the attack take longer, as you have to introduce 3 bit flips instead of one. (Memory ECC is 1 bit correcting, 2 bit detecting error correction.) Even fast memory scrubbing is not a sure way to prevent this attack. The only way I see is to refresh fast enough that no bit flips happen or they are so exceptionally unlikely to make the attack infeasible. There is a real possibility that most non-laptop systems already do that and that this problem is the result of misguided attempts to safe power on laptops.
That is not to say ECC is worthless. It has other benefits. But for this attack it is not the right fix.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.