Four new Android privilege escalations

The "QuadRooter" vulnerabilities are currently making lots of headlines, at least partly because they could impact up to 900 million Android devices. There are four separate bugs, each with its own CVE number. Interestingly, all are found in code that lives outside of the mainline kernel—but is obviously shipped in a lot of devices.

QuadRooter, which was announced with great fanfare by Check Point Software Technologies, consists of privilege escalation vulnerabilities that could be used by malicious apps to take control of an Android device—and, of course, the personal data stored on it. The four bugs were found in drivers for Qualcomm system-on-chips (SoCs) that are found in many Android phone models, including the flagship Google Nexus 5X, 6, and 6P handsets. The bugs are serious, but users can mitigate the risk somewhat by avoiding dubious apps.

The bugs are detailed in a report [registration required] from Check Point. Note that unchecking the "please send me email" box on the registration form does not actually seem to stop Check Point from sending emails. The vulnerabilities are found in three different subsystems of the Qualcomm kernel: the ipc_router interprocess communication (IPC) module, the ashmem shared-memory allocation subsystem, and two bugs in the kernel graphics support layer (kgsl) that is used to render graphics provided by user-space programs. None of those modules is in the mainline kernel, though ashmem is in the staging tree but that version does not contain the function that caused the vulnerability.

For the most part, the bugs themselves are fairly standard kinds of flaws. The two in kgsl are use-after-free vulnerabilities, the ashmem bug provides a way to get attacker-controlled data into the kernel, while the ipc_router bug is a memory corruption that can lead to code execution. It is noteworthy that, because the code is out of the mainline, it probably didn't get the attention, testing, fuzzing, and review that it might otherwise have received—from the kernel development community, anyway. Given its prevalence in Android devices, though, it did garner some amount of attention, from Check Point, at least, and perhaps from others who are far less likely to report on what they found.

A look inside the flaws is instructive. CVE-2016-2059 is the ipc_router code-execution bug. The module provides a new address family (AF_MSM_IPC) that can be used to create sockets. Users can convert "client" sockets to "control" sockets by way of an ioctl() call. Unfortunately, the conversion function locks the wrong list, which allows (malicious) callers to corrupt a different list. Elements on that list can be made to point to freed memory, which the attacker can control using "heap spraying".

The report goes into some detail on how that corruption can be used to call arbitrary kernel functions with attacker-controlled parameters, which makes for interesting reading. But the upshot is clear: root privileges can be gained and SELinux disabled, which gives the attacker complete control over the device and its contents.

The first of the kgsl bugs (CVE-2016-2503) is caused by a race condition in the function used to destroy a "syncsource" object in the kgsl_sync subsystem, which synchronizes graphics data between user space and the kernel. If two or more threads call the function with the same syncsource, the reference count can be decremented incorrectly, leading to a negative count. That will allow attackers to control the memory contents of the object that the kernel still thinks is in use, which can then be used to execute code of the attacker's choosing. The recent reference count hardening work might help avoid reference-count underflows like this.

The second kgsl use-after-free (CVE-2016-2504) vulnerability is even easier to trigger. There is an ioctl() that allows users (or attackers) to directly free a specific kgsl_mem_entry object by its ID number, without any access control, which means that another thread can free the object while the kernel still has a reference to this newly freed object. The usual use-after-free games can be played at that point.

The bug (CVE-2016-5340) in ashmem, which is a memory allocator that allows processes to easily share memory, is a bit different. The Qualcomm version of ashmem has diverged from the one in staging, with some new functions provided to access the struct file from a file descriptor as long as the file is an ashmem shared-memory file. But the is_ashmem_file() function simply tests if the file name is /ashmem, which is the file name used by the subsystem. However, a, perhaps obscure, deprecated feature of Android, to allow for large files that accompany an app's .apk file, also allows apps to mount a filesystem with an ashmem entry in the root:

Thus a malicious app could fool the ashmem subsystem into using attacker-controlled data in what it thinks is a file with contents that are normally completely under its control.

Check Point has created a QuadRooter Scanner app that is available in the Google Play store. It scans an Android device and reports which, if any, of the vulnerabilities affect it. There is some skepticism about how good of a job it actually does, however. On my Nexus 6P, the scanner reports that the phone is vulnerable to CVE-2016-2504 and CVE-2016-5340, which were not reported as fixed in the July Android Security Bulletin—the phone is updated with the July 5 update.

That would seem to indicate that a recently purchased flagship phone is still vulnerable to two of the bugs, though the August bulletin does mention a fix for CVE-2016-2504, but there is no mention of CVE-2016-5340. That update has not been made available over Google's Project Fi carrier as of yet, however. According to the report, Qualcomm was informed about the bugs in April and it confirmed that it has released updated code to OEMs.

But, as we have seen rather often in the Android world, those fixes are taking some time to make their way out to users. Even users of Google's phones and network are awaiting some fixes. Other carriers and device makers tend to lag even further behind—or fail to ever get updates out at all. That leaves lots of phone owners in a tricky spot.

Users who are not running random side-loaded apps are likely to be less vulnerable to problems from QuadRooter, though. That is not to say it is impossible for a malicious app to slip into the Google Play store, but it is definitely less probable. The source of these kinds of malicious apps will be some dodgy app store that promises to deliver the latest exciting game or other app. Users of vulnerable phones should steer clear of such sites and generally try to be alert to odd behavior. That's good advice even well after QuadRooter is fixed on phones, as there are undoubtedly other, similar bugs lurking out there, both in the mainline and various vendor kernels.