Until a few days ago the recently discovered flaw in modern memory chips was just a worrying curiosity - changing some bits at one location in a particular way could result in another distinct bit flipping its state. Now Google researchers have shown that it is possible to use this to gain kernel privileges.

Memory chips have been packing more and more bits into the same space for a while and we tend to think that when we store a bit pattern it stays stored. If you know a little about hardware then you may be aware that it is possible for bits to randomly flip from one state to another. The usual cause is a cosmic ray that passes through the chip. Enterprise class systems often use Error Correcting Code ECC memory, which can typically correct single-bit errors and detect two-bit errors. However, many machines don't have error detection (parity) let alone error correction. 

The latest high density memories however are susceptible to patterns of access that can cause an unrelated bit to flip - no cosmic ray needed. The reason is that DRAM is organized in rows of memory cells and these have been getting closer together. A bit is stored as a small charge which leaks away over time. This is the reason that DRAM has to be refreshed, i.e. you read the bit before it has decayed completely and write it back afresh. 

What was discovered is that it is possible that reading from two locations repeatedly can cause bit flips in a third simply because there is charge leakage between the rows. 

So what you do is:

code1a:
  mov (X), %eax  // Read from address X
  mov (Y), %ebx  // Read from address Y
  clflush (X)  // Flush cache for address X
  clflush (Y)  // Flush cache for address Y
  jmp code1a

This reads data from two locations X and Y millions of times and if the addresses are chosen correctly this causes a bit in another row to flip. The two addresses have to be in different rows and each read causes the entire row to be read out and discharged before being refreshed to its original state. 

The two addresses have to be in different rows because if they were in the same row the second and subsequent accesses would simply read the row buffer without refreshing. With the addresses in different rows multiple readouts and refreshes have to be implemented. This electrical disturbance can cause bit flips in adjacent rows.

Susceptibility to rowhammer of three manufacturer's (A,B and C) DD3 DRAM

This is essentially the mechanism that was discovered late last year by a team of researchers from Carnegie Mellon University and Intel Labs

It's an interesting and worrying discovery but the idea that it could be put to malicious use seems far fetched. At worst, a program might introduce "random" bit errors into a machine's memory that were not detected or corrected by hardware.

How can flipping a single bit be used for a practical attack when controlling which bit is flipped is so difficult?

Hence the surprising announcement from Mark Seaborn and Thomas Dullien of Google's Project Zero team that, not only is it practical, they have demonstrated the exploit. The key problems that they solve is how to pick the physical address.

Addresses that you use in a program are mapped by the memory mapping hardware to real physical addresses. If you want to target physical addresses in different rows in the DRAM you need to know the mapping. The Project Zero team suggest various approaches starting from trying random addresses, timing memory accesses to determine if they are in the same or different rows and so on. Eventually they settled on guessing the memory layout and used a scheme called "double hammering":

to attack address x hammer address x+256k and x-256k

To try to make use of this the team wrote a native process and an NaCl program running in Chrome's sandbox. 

The NaCL exploit is particularly worth understanding. The program dynamically installs 250MB of indirect jump sequences which are all to safe addresses inside the sandbox and hence allowed. It then hammers the dynamic code area and looks for bit flips that modify the indirect jumps so that they can be used to call shell code hidden in the NaCl validated code. 

The good news is that this exploit has already been mitigated by disallowing the Clfush command in NaCl code, but there may be other ways to implement a rowhammer.

The second attack works by row hammering the page table entry to cause  it to point to a physical page containing a page table of the attacking process. This is a more generalizable attack because it uses the fact that once you have found a bit you can flip then it is repeatable and this means you can work out which bit flips are useful and use just these.

The idea is to fill the memory with page tables and then hammer the memory. You then check to see if any of the page tables in memory have been adopted by the system as valid page tables - by checking to see if they point to something new. If one is found then the process has access to a page table and hence can access any memory location. 

The actual details are, as you might expect, a bit more complicated and there is the question of what the best thing to do with a page table that you own - but essentially you have the machine at your mercy. 

The Project Zero team tested 29 laptops of different ages with different DRAM, all DDR3, and discovered that they could get a rowhammer bit flip on about half of them. There is a rowhammer-test tool that you can use to test your own machines if you are worried or just curious. The blog post presents some ways of avoiding a rowhammer attack, but mostly it involves changing hardware.  

Comments

Make a Comment or View Existing Comments Using Disqus

or email your comment to: comments@i-programmer.info