Rowhammer
-
"Researchers at Google’s Project Zero have demonstrated that a recently documented bug in some dynamic random-access memory (DRAM) chips can be exploited to gain kernel privileges on Linux systems."
http://googleprojectzero.blogspot.ro/2015/03/exploiting-dram-rowhammer-bug-to-gain.html
http://blog.erratasec.com/2015/03/some-notes-on-dram-rowhammer.html#.VP974r5Olxt
-
So this is really an underlying hardware bug, it is possible to change the value in some DRAM memory locations by repeatedly writing to nearby locations within the DRAM internal refresh cycle time. It is just dumb physics that has beaten the manufacture of smaller/cheaper capacitor-based memory like DRAM.
The exploits for this relying on being able to bypass the various on-board memory caches that typically are locally handling repeated write to a memory location (like when a program is screaming around a loop modifying a few variables that do not fit in the registers). Apart from using the actual cache flush instruction, it could be achieved by simply writing fast enough to a lot of memory locations, forcing the memory caches to fill and be written back to DRAM…
It seems to me that this is mostly a denial of service (DOS) problem - the most likely thing to happen as a result of the "random" memory bit-flips is:
- The virtual address space of the hackers process itself gets modified unexpectedly and the hackers program goes wrong/crashes.
- Some currently free physical memory gets flipped - no effect
- The virtual address space of some other user process gets modified unexpectedly and so some other program crashes with some wacky traceback - DOS to that other user
- Some physical memory used by the kernel or an important system process gets flipped - the OS most likely bugchecks - DOS to everybody using the system.
Sometimes the flip might be to a page table entry or other kernel data structure in a way that gives the hackers program privileged access to kernel pages... But it seems to me that the hacker is more likely to crash the OS 100 times before getting a pattern that leaves the system running but in a state where they gain usable escalated privilege.
Anyway, what an annoying hardware "feature" that will be difficult for software to completely close off.
-
Yeah - Randomly flipping bits and hoping to end up in control of a target system seems about as likely as randomly pulling items out of a cabinet with your eyes clothes, throwing them into an oven and ending up with a cake…
-
From the first link:
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 to all of physical memory.
So it isn't a random flip and hope issue but something that can be targeted at a specific machine.
-
Neat stuff. Academically it is interesting, but realistically it only reinforces the fact that nobody is secure
from a motivated enemy.Some teenage, NSA intern probably exploited this over a decade ago, lol.
-
This has been known by hardware manufacturers since 2012. Some have already provided Bios updates to help mitigate this issue (maybe from a reliability stand point).
But it's only since June 2014 when Intel and Carnegie Mellon U. did some further research that this issue is getting more attention.
But they are saying that it can exploit privileges. Guess time will tell where hackers (or Big Bro) will take this potential.
Vendors always seem to sweep these under the carpet until they can come up with solutions.
-
From the first link:
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 to all of physical memory.
So it isn't a random flip and hope issue but something that can be targeted at a specific machine.
Yeh, that's why I put "random" in quotes. It takes some number of (re)writes to for the bit flips to happen, and it depends on analog charge leakage properties of the memory storage locations. That will vary from location to location, chip to chip, brand to brand… So any attack can be statistically targeted in a way that does make it "possible" to achieve bit flips in something like the bit pattern the attacker is aiming for.
The articles I have seen do not give any idea about how well targeted the bit flipping can be in real life - i.e. on a typical real-world system with other user processes doing real stuff, how many times does the attacking code bugcheck the system, compared to achieving exploitable privilege escalation without bugchecking the system.