Researchers Defeat Android OEMs' Security Mitigations

It's getting harder and harder to exploit vulnerabilities in Android, thanks to a combination of Google-enabled security mechanisms and additional protections from individual smartphone manufacturers. However, as two researchers discovered, it's still possible to break in.

Over the past few years, Google has buckled down on Android device security with new protections to reduce the number and impact of kernel-level bugs. Some of its mitigations include Stack Guard, SELinux, privileged execute never (PXN), hardened user-copy, privileged access never (PAN) emulation, and kernel address space layout randomization (KASLR).

"As far as we know, mainly mitigations are currently applied on Android kernel," explains Jun Yao, security researcher with the C0re team. "However, these mechanisms are difficult to apply to every phone due to Android fragmentation issues."

To fill the security gaps, smartphone manufacturers integrate additional mitigations into the devices they produce. Attackers need to meet certain conditions to complete an exploit on an Android phone and OEMs' extra mitigations make these conditions difficult to meet, he says.

In the second quarter of 2017, Samsung, Huawei, Oppo, and Vivo accounted for 47.2 percent of the global smartphone market share, the researchers report. Despite their standing as the world's top four Android OEMs, deep research on their security mitigations has been limited to the Samsung Knox. Yao and Lin decided to put more manufacturers' protections to the test.

At this year's Black Hat Asia conference, being held March 20-23 in Singapore, Yao and fellow Core security researcher Tong Lin will share the details of these mitigations and demonstrate how they can be stably bypassed in ways that have not been made public. One of the implementations they broke was the addr_limit checking protection on Vivo devices.

"Usually, to get root privilege on [a] target device, attackers need to be able to overwrite kernel memory," Yao explains. "The most popular way to do it is to modify the process' addr_limit."

Because the kernel checks addr_limit before the system call returns, it cannot be modified directly. The researchers had to find another way to overwrite the kernel without changing addr_limit, and they successfully did so.

"We use gadgets to overwrite the kernel without changing addr_limit," says Yao. "When we control PC in kernel mode, we force it to point to a gadget. When the gadget runs, it will overwrite a victim function pointer. And we can read or write kernel memory by calling this victim function pointer with different arguments."

They report this mitigation can be easily bypassed on a target device depending on the security mechanisms already in place.

PAN emulation works with hardened usercopy, which adds bounds checking to usercopy functions that the kernel uses to transfer data from user space to kernel space memory and back. Missing or invalid bounds checking has often caused kernel vulnerabilities in the past.

Hardened usercopy functions help detect and mitigate security issues in developers' code, but they can only help if developers use them, explains Sami Tolvanen, senior software engineer for Android Security, on the Android developer blog. Features like PAN in ARM 8.1 and Supervisor Mode Access Prevention (SMAP) in x86 prevent the kernel from accessing user space directly, and ensure developers go through usercopy functions.

"I think mitigations fall into two categories," says Yao. "One is to reduce the attack surface, and the other is to make exploits harder. The mitigations we are talking about belong to the latter one." Fewer vulnerabilities lessen the chances of defeating these mitigations, he adds.

The most important thing for OEMs to do is promptly patch kernel flaws, Yao continues. He also advises using a combination of mitigations, as single mitigation is easier to bypass.

Black Hat Asia returns to Singapore with hands-on technical Trainings, cutting-edge Briefings, Arsenal open-source tool demonstrations, top-tier solutions and service providers in the Business Hall. Click for information on the conference and to register.

Kelly Sheridan is the Staff Editor at Dark Reading, where she focuses on cybersecurity news and analysis. She is a business technology journalist who previously reported for InformationWeek, where she covered Microsoft, and Insurance & Technology, where she covered financial ... View Full Bio

Most enterprises are using threat intel services, but many are still figuring out how to use the data they're collecting. In this Dark Reading survey we give you a look at what they're doing today - and where they hope to go.

A vulnerability in DB Manager version 3.0.1.0 and previous and PerformA version 3.0.0.0 and previous allows an authorized user with access to a privileged account on a BD Kiestra system (Kiestra TLA, Kiestra WCA, and InoqulA+ specimen processor) to issue SQL commands, which may result in data corrup...

A vulnerability in ReadA version 1.1.0.2 and previous allows an authorized user with access to a privileged account on a BD Kiestra system (Kiestra TLA, Kiestra WCA, and InoqulA+ specimen processor) to issue SQL commands, which may result in loss or corruption of data.

Stored cross-site scripting (XSS) vulnerability in the &quot;Site Name&quot; field found in the &quot;site&quot; tab under configurations in ClipperCMS 1.3.3 allows remote attackers to inject arbitrary web script or HTML via a crafted site name to the manager/processors/save_settings.processor.php f...

In Apache Batik 1.x before 1.10, when deserializing subclass of `AbstractDocument`, the class takes a string from the inputStream as the class name which then use it to call the no-arg constructor of the class. Fix was to check the class type before calling newInstance in deserialization.

Some Huawei smart phones with the versions before Berlin-L21HNC185B381; the versions before Prague-AL00AC00B223; the versions before Prague-AL00BC00B223; the versions before Prague-AL00CC00B223; the versions before Prague-L31C432B208; the versions before Prague-TL00AC01B223; the versions before Prag...