Vulnerabilities > CVE-2016-6728 - Permissions, Privileges, and Access Controls vulnerability in Google Android

047910
CVSS 7.8 - HIGH
Attack vector
LOCAL
Attack complexity
LOW
Privileges required
NONE
Confidentiality impact
HIGH
Integrity impact
HIGH
Availability impact
HIGH
local
low complexity
google
CWE-264

Summary

An elevation of privilege vulnerability in the kernel ION subsystem in Android before 2016-11-05 could enable a local malicious application to execute arbitrary code within the context of the kernel. This issue is rated as Critical due to the possibility of a local permanent device compromise, which may require reflashing the operating system to repair the device. Android ID: A-30400942.

Common Attack Pattern Enumeration and Classification (CAPEC)

  • Accessing, Modifying or Executing Executable Files
    An attack of this type exploits a system's configuration that allows an attacker to either directly access an executable file, for example through shell access; or in a possible worst case allows an attacker to upload a file and then execute it. Web servers, ftp servers, and message oriented middleware systems which have many integration points are particularly vulnerable, because both the programmers and the administrators must be in synch regarding the interfaces and the correct privileges for each interface.
  • Leverage Executable Code in Non-Executable Files
    An attack of this type exploits a system's trust in configuration and resource files, when the executable loads the resource (such as an image file or configuration file) the attacker has modified the file to either execute malicious code directly or manipulate the target process (e.g. application server) to execute based on the malicious configuration parameters. Since systems are increasingly interrelated mashing up resources from local and remote sources the possibility of this attack occurring is high. The attack can be directed at a client system, such as causing buffer overrun through loading seemingly benign image files, as in Microsoft Security Bulletin MS04-028 where specially crafted JPEG files could cause a buffer overrun once loaded into the browser. Another example targets clients reading pdf files. In this case the attacker simply appends javascript to the end of a legitimate url for a pdf (http://www.gnucitizen.org/blog/danger-danger-danger/) http://path/to/pdf/file.pdf#whatever_name_you_want=javascript:your_code_here The client assumes that they are reading a pdf, but the attacker has modified the resource and loaded executable javascript into the client's browser process. The attack can also target server processes. The attacker edits the resource or configuration file, for example a web.xml file used to configure security permissions for a J2EE app server, adding role name "public" grants all users with the public role the ability to use the administration functionality. The server trusts its configuration file to be correct, but when they are manipulated, the attacker gains full control.
  • Blue Boxing
    This type of attack against older telephone switches and trunks has been around for decades. A tone is sent by an adversary to impersonate a supervisor signal which has the effect of rerouting or usurping command of the line. While the US infrastructure proper may not contain widespread vulnerabilities to this type of attack, many companies are connected globally through call centers and business process outsourcing. These international systems may be operated in countries which have not upgraded Telco infrastructure and so are vulnerable to Blue boxing. Blue boxing is a result of failure on the part of the system to enforce strong authorization for administrative functions. While the infrastructure is different than standard current applications like web applications, there are historical lessons to be learned to upgrade the access control for administrative functions.
  • Restful Privilege Elevation
    Rest uses standard HTTP (Get, Put, Delete) style permissions methods, but these are not necessarily correlated generally with back end programs. Strict interpretation of HTTP get methods means that these HTTP Get services should not be used to delete information on the server, but there is no access control mechanism to back up this logic. This means that unless the services are properly ACL'd and the application's service implementation are following these guidelines then an HTTP request can easily execute a delete or update on the server side. The attacker identifies a HTTP Get URL such as http://victimsite/updateOrder, which calls out to a program to update orders on a database or other resource. The URL is not idempotent so the request can be submitted multiple times by the attacker, additionally, the attacker may be able to exploit the URL published as a Get method that actually performs updates (instead of merely retrieving data). This may result in malicious or inadvertent altering of data on the server.
  • Target Programs with Elevated Privileges
    This attack targets programs running with elevated privileges. The attacker would try to leverage a bug in the running program and get arbitrary code to execute with elevated privileges. For instance an attacker would look for programs that write to the system directories or registry keys (such as HKLM, which stores a number of critical Windows environment variables). These programs are typically running with elevated privileges and have usually not been designed with security in mind. Such programs are excellent exploit targets because they yield lots of power when they break. The malicious user try to execute its code at the same level as a privileged system call.

Seebug

bulletinFamilyexploit
description## Project Description Drammer is a new attack that exploits the Rowhammer hardware vulnerability on Android devices. It allows attackers to take control over your mobile device by hiding it in a malicious app that requires _no permissions_. Practically all devices are possibly vulnerable and must wait for a fix from Google in order to be patched. Drammer has the potential to put millions of users at risk, especially when combined with existing attack vectors like [Stagefright](https://en.wikipedia.org/wiki/Stagefright_(bug)) or [BAndroid](https://vusec.net/projects/bandroid). Drammer is the first Android root exploit that relies on _no software vulnerability_ and is an instance of the [Flip Feng Shui](https://vusec.net/projects/flip-feng-shui) exploitation technique. After [Dedup Est Machina](https://www.vusec.net/projects/dedup-est-machina/) and [Flip Feng Shui](https://www.vusec.net/projects/flip-feng-shui/), Drammer is our group’s third in a series of Rowhammer exploitation research. Our Drammer exploit and companion Drammer test app (see below) were implemented in collaboration with the [University of California, Santa Barbara](https://seclab.cs.ucsb.edu/). #### 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. ## Papers [1] V. van der Veen, Y. Fratantonio, M. Lindorfer, D. Gruss, C. Maurice, G. Vigna, H. Bos, K. Razavi, C. Giuffrida,[Drammer: Deterministic Rowhammer Attacks on Mobile Platforms](https://vvdveen.com/publications/drammer.pdf), in: CCS, 2016. ## Drammer Test App We developed an Android app – **not yet** in Google Play, but [available](https://vvdveen.com/drammer/drammer.apk) directly – to test your device for the Rowhammer bug. The app uses a native binary for which we also released the [source code](https://github.com/vusec/drammer). After a successful run, the app uploads anonymized output. We will use this to get a better understanding of how widespread the Rowhammer bug is. Of course, you can opt out of sharing results. Please note the following: * Currently, when finished its hammering session, **the app does not give you a nice popup that tells you whether you are vulnerable or not**. We will try to add this as soon as possible. Meanwhile, you can easily spot induced bit flips by glancing over the output and looking for the obvious keyword _FLIP_. * **Your phone might still be vulnerable, even if the app detected zero flips!** There are two main reasons for this. First, our current implementation of address selection is conservative: we recently discovered that the current code is only hammering **half** of the rows on a Nexus 5\. On your device, the DRAM geometry might be different enough for our app to completely fail selecting addresses for double-sided rowhammer. Second, the app may only have tested a very small fraction of your DRAM. Ideally, a single run takes at least an hour and scans a couple hundred of MB. The current code already tries to free as much memory as possible to hammer (affected by the aggressiveness factor), but there are probably better ways of doing this. ## Hammertime simulator We developed [Hammertime](https://github.com/vusec/hammertime), an open-source Rowhammer simulator – available on [github](https://github.com/vusec/hammertime) – to foster further research on the Rowhammer bug. The simulator allows researchers and practitioners to simulate hardware bit flips in software, using bit-flip patterns (or fliptables) from a large set of DRAM chips. We plan to integrate bit-flip patterns we observed with Drammer on ARM soon. ## Statistics Not every phone is susceptible for the Rowhammer bug. For our paper, we tested 27 devices and were able to flip bits on 18 of them. In the table below, you can find statistics on devices that were tested so far. <table style="width: 100%;"> <tbody> <tr> <th>Model</th> <th>#devices</th> <th>#vulnerable</th> </tr> <tr> <td colspan="3"><strong>ARMv7 (32-bit) devices</strong></td> </tr> <tr> <td>LG Nexus 4</td> <td>1</td> <td>1</td> </tr> <tr> <td>LG Nexus 5</td> <td>15</td> <td>12</td> </tr> <tr> <td>Motorola Moto G (2013)</td> <td>1</td> <td>1</td> </tr> <tr> <td>Motorola Moto G (2014)</td> <td>1</td> <td>1</td> </tr> <tr> <td>OnePlus One</td> <td>2</td> <td>2</td> </tr> <tr> <td>Samsung Galaxy S4</td> <td>1</td> <td>1</td> </tr> <tr> <td>Samsung Galaxy S5</td> <td>2</td> <td>1</td> </tr> <tr> <td colspan="3"><strong>ARMv8 (64-bit) devices</strong></td> </tr> <tr> <td>HTC Desire 510</td> <td>1</td> <td>0</td> </tr> <tr> <td>Lenovo K3 Note</td> <td>1</td> <td>0</td> </tr> <tr> <td>LG G4</td> <td>1</td> <td>1</td> </tr> <tr> <td>LG Nexus 5X</td> <td>1</td> <td>0</td> </tr> <tr> <td>Samsung Galaxy S6</td> <td>1</td> <td>0</td> </tr> <tr> <td>Xiaomi Mi 4i</td> <td>1</td> <td>0</td> </tr> </tbody> </table> We encourage everybody to try our [Drammer test app](#app) and help figuring out how widespread mobile Rowhammer is. We expect, for example, that devices equipped with LPDDR4 are less vulnerable. This is because the LPDDR4 standard includes **optional** hardware support for the so-called [target row refresh](https://en.wikipedia.org/wiki/Row_hammer#TRR) mitigation. ## Technical Walkthrough Drammer presents two novel contributions: 1) being able to do _Rowhammer on mobile devices_, and 2) doing _deterministic Rowhammer exploitation_ without relying on fancy memory management features. What follows is a technical summary of our paper, but only if you’re interested. ### 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](https://iss.oy.ne.ro/ANVIL.pdf)). * 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](https://googleprojectzero.blogspot.nl/2015/03/exploiting-dram-rowhammer-bug-to-gain.html), 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](https://android.googlesource.com/kernel/msm/+/android-msm-hammerhead-3.4-marshmallow-mr2/include/linux/cred.h#116) – 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_<sup>2</sup> 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_<sup>2</sup> 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. ![drammer-ffs](https://www.vusec.net/wp-content/uploads/2016/09/drammer-ffs.png) ## Responsible Disclosure We contacted the Android Security Team on July 25\. In conjunction with Google, we did not publicly disclose any details about Drammer prior to the [CCS conference](https://www.sigsac.org/ccs/CCS2016/) in Vienna. Google informed their partners about this issue on October 3, 2016 and provides a patch for it in their November Android Security Bulletin. Ultimately, [CVE-2016-6728](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6728) was assigned to this issue. Our bug report and Proof-of-Concept received a reward from the [Android Security Reward Program]( https://www.google.com/about/appsecurity/android-rewards). The vulnerability was marked as _Critical_ by Google. Note that, although Google’s patch round from November complicates our attack, it does not eradicate it. We hope to see a more sophisticated fix soon. 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. ## Reception * Drammer was covered by both [WIRED](https://www.wired.com/2016/10/elegant-physics-dirty-linux-tricks-threaten-android-phones/) and [Ars Technica](http://arstechnica.com/security/2016/10/using-rowhammer-bitflips-to-root-android-phones-is-now-a-thing/). * Dutch news site [nu.nl](http://www.nu.nl/mobiel/4339484/nederlandse-onderzoekers-vinden-opnieuw-groot-lek-in-android.html) also wrote an article about Drammer. ## Reference * https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6728 * http://weibo.com/ttarticle/p/show?id=2309404034511389214467 * https://www.vusec.net/projects/drammer/ * poc: https://github.com/vusec/drammer
idSSV:92489
last seen2017-11-19
modified2016-10-25
published2016-10-25
reporterRoot
sourcehttps://www.seebug.org/vuldb/ssvid-92489
titleAndroid Rowhammer attack vulnerability (Drammer)