Problem description:

The row-hammer attack is a method, where the physical properties of the DRAM chip are exploited: Flushing one row frequently may trigger bit flips in adjecent rows (see here). One Problem is, that each row contains many pages belonging to various processes or the operating system. Hammering might cause also bit flips in any of those, thus causing system instability.

The following article demonstrates an approach to nail down a memory page from a SUID-binary or ld-linux itself to a suitable physical memory location and then hammer it without any risks.


The main idea behind the tool is to use two features of Linux to get zero-risk row-hammer exploitation:

So the main feature of the POC is to

The POC currently does not support too many command line arguments or automatic adaption to the target machine. Hence the parameters have to be changed in code. As I do not have any row-hammer affected test equipment, the tool will currently only print out the message Put your rowhammer code here when mapping was set up correctly. Functionality for that might be included in later releases.


Source code controls:


To start, the POC should be configured to consume nearly all available memory on the machine (see hogDataSize). To perform IO activity, create file some-file so that hogDataSize and the file consume 2-20% more RAM than available in the machine.

After invocation the tool fills up memory and performs disk IO to cause page cache pertubations.

$ ./D-RamPage --DiskInputFile DiskInput --HogDataSize 1073741824 --TargetFile /usr/bin/chfn --TargetFilePage 3 Longest span is 0x686c at 0x2ff94 Using page range 0x27f80-0x37f80 at 0x600000602000-0x600010602000 Got 0xebd1 pages of 0x10000 in range, will be used in 255 cycles Searched pages, got 128 spans Mapped one in-range page in run 186 Target page map successful at 0x29b00+0x0 (rowLength 0x40)! Got target address 0x600002182000 Ready for hammering: pagemap is: 0x6000c0000000: page 0xa600000000029b00 ... ... 0x6000c00bf000: page 0x8600000000029bbf Put your rowhammer code here!

The tool can also be used to evict pages from ld-linux from page cache. This worked on a 2-core machine with desktop and virtual machine running but might fail on really busy server systems.

Interesting bit-flip targets for escalation:

As the flipping of bits does not give root privileges per se, one of the modified files has to be used for escalation.

For evaluation of good bit-flip target pages, the tool BitFlipEmulate.c can be used to create modified variants for system files. Then one can attempt to exploit a number of such files to get a feeling for the success rate.


Future improvements:

Currently the POC does not include the row-hammer attack code itself as it is highly likely to be dysfunctional without testing (at the moment I have no test machine). When available, implementation of 3 functions might be useful:

Privilege escalation within virtual machine:

To avoid crashing of the guest or host, /proc/[self]/pagemap cannot be used as it does not yield the real physical page addresses. An alternative crash risk mitigation procedure could be to allocate as many pages as possible. Afterwards start row-hammering a random page and try to infer the adjecent pages from monitoring the remaining allocated pages. As soon as linked pages are known, try to fix interesting target content to the vulnerable pages.

Privilege escalation from virtual machine to host:

There may be hypervisor calls, where guest pages are passed on to host directly and vice versa. Interference with such a page might allow targeted host influence from within guest.


Material, References

Last modified 20150403
Contact e-mail: me (%)