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
C-C-C-C-Combo breaker
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)."
Enjoy your triple Troll moderations, asshole. This is Hardware. If this were a vulnerability introduced in the Linux Kernel, then you'd have a fucking point. This is Hardware. If you're a damn software genius and build a custom OS that locks everything down to bare metal and you'll still have this bug. This is Hardware. All operating systems running on this hardware will have the exact same attack vector, and thus the playing field is just as level now as it was before the bug was discovered. This is Hardware. Even given this hardware bug, Linux security is still leagues better than the Windows Equivalent. OS X Would still be vulnerable to this bug and it's only slightly more secure than Linux given the fact that it's such a damn walled garden. This is Hardware. Do you get the recurring theme, asshole?
I suspect that ECC (Error Correction Code) RAM will avoid this. I will not purchase a machine without it. It also protects from failing memory. All modern systems should implement this. Yes, it is more expensive than simple parity checking RAM, or just simple RAM, but it will detect and protect you from such attacks.
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.
Row hammering corruption occurs when refreshes are set to far apart (posted refreshes). Consecutive reads between refreshes drain the charge in such an extent that corruption occurs. Setting up the refresh rate until all possibilities of row hammering corruption becomes nil, effectively cures this issue.
It will come at the expense of slight, hardly measurable DRAM speed losses and a slight power consumption increase.
Normal code will never hit this issue because normal reads result in cached data. Even for code severely hammering some address will result in cache usage, not memory reads. This type of hammering is possible if you can bypass cache hierarchy or evict/invalidate data stored between reads.
Years ago, I was doing my undergrad project writing a kernel in 68K assembler (years ago, remember). I was at the point where my kernel tick driver was working but I didn't have any process support yet. I was getting strange reboots after an exact amount of time (2min or so); 100% reproducible on my machine. I eventually discovered the issue went away if the tick handler just did some do-nothing XOR ops to some memory locations before returning. I knew it had to be something to do with the kernel running such a small amount of code in such a highly-recurring fashion -- perhaps this was what was going on. I didn't have a scope handy or anything to determine if it was some sort of bus glitch but I always suspected...
Once I had processes actually running in the kernel, I was able to remove those XOR ops.
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.