Drammer: Flip Feng Shui Goes Mobile - vusec

Rowhammer

is a hardware bug that allows attackers to manipulate data in memory without accessing it. More specifically, by reading many times from a specific memory location, somewhere else in memory a bit may flip (a one becomes a zero, or a zero becomes a one). Our work is the first to show that Rowhammer is possible on mobile, ARM-based hardware.

Flip Feng Shui

or FFS is a technique that allows for reliable exploitation of a hardware vulnerability (e.g., Rowhammer) by combining it with a memory massaging primitive (to land sensitive data on a vulnerable location). Drammer is the first to show that such deterministic Rowhammer exploitation is possible without relying on fancy memory management features. Although we focus mainly on mobile devices, this makes that Drammer comes with a wider impact; allowing FFS attacks without memory deduplication, for example.

1. Mobile Rowhammer

Although functioning fairly well on x86, researchers have speculated that Rowhammer on ARM could be impossible. One of the main reasons being that the ARM memory controller might be too slow to induce bit flips. Not surprisingly, before Drammer, no existing work from academia or industry documents any success in reproducing the Rowhammer bug on mobile devices.

The obvious first goal of our study was to find bit flips on a mobile phone. Since Rowhammer manifests itself in DRAM, existing hammer code usually consists of a small loop that 1) reads a value from memory, and 2) flushes this value from the CPU cache. Without cache flushing, the vulnerable DRAM chip would only be accessed once during the first iteration. Every subsequent access would be served from the cache.

Working with an ARMv7-A CPU (the core of our poor LG Nexus 5 test phone), cache flush instructions are unavailable from user space (unlike Intel’s clflush instruction). We thus implemented a hammer function as Loadable Kernel Module. This allowed us to use the DCCIMVAC instruction (Data Cache Clean and Invalidate by MVA to PoC: mcr p15, 0, <reg>, c7, c14, 1). After some frustrating trial and error – do we not see any flips because of a bug in our code, is the controller really too slow, or is this DRAM chip simply not vulnerable? – we found a first flip. Later, once we established that the ‘row size’ of the Nexus 5 is 64 KB instead of 256 KB, this one flip became many…

1b. Direct Memory Access

Although good for feasibility analysis, flipping bits with kernel code that requires root access is not practical for writing a root exploit. Our next goal was thus to induce bit flips from user space. After establishing that existing methods for flushing or bypassing the CPU cache do not work on ARM, we tried a new approach: using direct memory access (DMA). By design, DMA memory pages have two important properties: 1) they are marked as uncached; and 2) they are physically contiguous. The former means that any read operation from DMA memory (or any write operation to it) bypasses the CPU cache and propagates to the DRAM chip directly. The latter means that pages obtained by allocations up to a certain size (4 MB on recent Linux kernels) are guaranteed to be adjacent to each other in physical memory.

DMA memory thus solves our problem of not being able to flush the CPU cache. The fact that allocated pages are physically contiguous happens to also solves another important issue. Recent kernels disabled access to /proc/self/pagemap – a special file containing the mapping of virtual to physical addresses. Without such mapping, it is hard to figure out from which ‘aggressor’ address x we should read to hammer ‘victim’ address y (x should be exactly one row above or below y to get the best chance of flipping it). If we know, however, that a chunk of memory is physically contiguous, we can compute aggressor addresses for each victim within such chunk by subtracting (or adding) the row size.

1c. Android ION

Android provides DMA Buffer Management APIs through its main memory manager called ION. This allows userland apps to access uncached, physically contiguous memory and comes with all the benefits:

• We do not have to rely on cache flush instructions. Moreover, since we bypass the cache completely, we break any defense that relies on monitoring cache misses (e.g., ANVIL).
• We do not have to rely on access to /proc/self/pagemap or transparent huge pages (which may not be enabled by default).
• We do not have to rely on fancy memory management features like memory deduplication or MMU paravirtualzation for the memory massaging phase of FFS (discussed next).

Although ION is specific to Android, we think that it is also possible to construct similar attacks on Linux/x86-64. We dedicate a section about this in our paper.

2. Deterministic Exploitation

Armed with uncached, physically contiguous memory, our third goal is to perform memory massaging in such a way that a single bit flip allows us to gain root privileges. Similar to Mark Seaborn’s attack, we use page tables as sensitive data. By flipping a bit in a Page Table Entry (PTE), we can make that entry point to a page table. This means that the associated virtual address of that PTE is now mapped to a page table which we can use to overwrite its contents. Next, we can map any physical memory address into the virtual address range defined by the page table, including kernel memory. We can use this to search for our process’ credentials structure – the data structure that the kernel uses to keep track of a process’ uid, gid, etcetera. Finally, once found, we can modify our process’ struct cred to get root privileges.

A subtle difference between the exploit from Project Zero and Drammer is determinism. Mark Seaborn sprays physical memory with pages tables and reasons that when a PTE’s physical page number changes [due to a bit flip] there’s a high probability that it will point to a page table for our process. Drammer, however, removes this non-determinism by massaging physical memory in such a way that when we flip a bit in a PTE, we make it point to its own page table. We do this by using the bit flip as addition or subtraction primitive.

2b. Flipping Bits in Page Table Entries

As an example, consider a PTE that points to a page at physical address 0x1982f000. Ignoring the lowest 12 properties bits of a 32-bit PTE, this gives the bit pattern 00011001100000101111 (0x1982f000 bit shifted 12 places to the right). If a we manage to flip the lowest 1, then the new PTE becomes 00011001100000101110. This makes the PTE point to physical address 0x1982e000, showing that a 1-to-0 flip at this offset subtracts the PTE by one page. If we flip the second 1, we would end up with PTE 00011001100000101101. This corresponds to physical address 0x1982d000; exactly two pages away from the original. Flipping the third bit moves the PTE 4 pages to the left, the 4th bit allows us to move 8 pages, etcetera.

With these primitives in hand, we ought to align physical memory in such a way that the physical address of an mmapped data page is exactly n² pages ‘away’ from its page tabl. Here n is the offset of the vulnerable bit in the PTE. Continuing previous example, if n is 5 for a 1-to-0 flip, our data page should store 16 pages before the page table. And we found a way of doing exactly this 🙂

2c. Abusing the Buddy Allocator

By releasing a large contiguous memory chunk and quickly re-allocating smaller ones, we can satisfy above requirements and make Drammer deterministic. The basic steps of our attack involve:

1. Search physical memory for potentially exploitable flips (dubbed templating). After this step, we have exhausted all large contiguous chunks (of size 4 MB), but also all medium-sized chunks – say of size 64 KB. This means that there is no physically contiguous memory left that spans 64 KB or more.
2. Release a large chunk that has an exploitable flip, but do hold the other chunks.
3. Allocate (i.e., exhaust) all medium-sized chunks again. Since, in step 1, we exhausted all of these already, we know that the buddy allocator will split the large, vulnerable chunk that we released in step 2 and give us exactly 64 chunks of size 64 KB (64 * 64 KB = 4 MB), including a chunk with the exploitable bit. We can now release all chunks that are larger than 64 KB so that we won’t go out-of-memory in the next step.
4. Release the vulnerable medium-sized chunk and force the OS to allocate a page table at the location of vulnerable page (the page with the exploitable bit).
5. Map (with mmap) the appropriate other medium-sized chunk to create a page table entry that points to a page that is exactly n² pages away from the page table.

Next is hammer time! We hammer the row that holds the PTE to induce the bit flip that makes it point to its own page. We suddenly get write access to a page table and scan kernel memory by writing new PTEs. Once we find our credentials data structure, we overwrite it with zeros and get root access.

2d. Phys Feng Shui

The figure below illustrates the memory massaging phase of Drammer. For more details, it’s best to have a look at the paper.

Due to the nature of our attack – exploiting a hardware vulnerability – implementing such comprehensive patch is not easy. It is because of this that Google first decided to disable the ION kmalloc heap. This makes it impossible for user space applications to request guaranteed contiguous physical memory through ION. However, an attacker can still exhaust the regular system heap. He can then rely on the predictable behavior of the buddy allocator to get contiguous pages anyway. In addition, the system heap allocator allocates memory from a different pool (highmem), normally separated from that used to allocate page tables and other kernel data structures (lowmem). However, an attacker can allocate many ION chunks to deplete the highmem pool and force the buddy allocator to serve new requests from lowmem. We hope that Google soon applies more fundamental changes to the Android Linux Kernel that allows for ION memory accounting. This way, Android could limit ION allocations on a per-uid base, thwarting Drammer much more. In addition, /proc filesystem entries such as /proc/pagetypeinfo that leak the state of the buddy allocator (e.g., highmem chunks available, chunks of a given size available, etc.) should be made accessible only by root.