The 2013 Android Vulnerability of the Year

Were we to pick the most notorious 2013 Android vulnerability – the dubious award would undoubtedly go to CVE-2013-6282. A privilege escalation flaw released in October and affects all Android versions 4.0-4.3.

What makes this vulnerability so abysmal? After all, it hardly gained any press coverage and was mainly discussed in smaller highly technical and focused forums. However, both our research and that of fellow researchers, has proved that behind the scenes lies a basic operating system vulnerability that:

1. Affects most devices running Android versions 4.0-4.3
Including Samsung Galaxy S3/4, Samsung Galaxy Note 2/3, Sony and Motorola. Essentially, affected devices include all Android devices running Linux Kernel 3.0-3.5.4
2. Is exploitable through multiple local and remote attack vectors
Infection can be done through a remote access as well as through a cable or physical access. For example, exploitation means include:

• Embedding the exploit within an Android application. In turn, the application may be distributed in Google Play or through 3rd-party exploits
• Combining the exploit with a Web browser remote code execution exploit (for example through the recent vulnerabilities released in the Pwn2Own competition). This allows the attacker to trigger a full drive-by exploitation.
• Connecting the mobile device to the computer. In fact, this was how VROOT – a rooting tool in the wild which we detailed in our last blog post – exploited this vulnerability.

3. Enables root access to any application regardless of privilege level
As opposed to the popular MasterKey vulnerability – which enabled an attacker to receive Android system level permissions by installing an application posing as an existing system application but with suspicious permissions – this vulnerability gives the attacker more to leverage on. An exploit of this vulnerability can be run from any application, with any amount of permissions asked, say, a child’s game or a clock widget. The root permissions that the attacker gains with this vulnerability allows the attacker to remain persistent even after the malicious application is uninstalled, and bypass any additional security and container solutions.

4. Allows the bypassing of SEAndroid – Android’s new security enhancement feature
The nature of the vulnerability allows an attacker to disable SELinux – the component that is the basis for SEAndroid (see the technicalities section for more information). Consequently, any Android app – with any level of privileges – can run root privileged code (i.e. this is the privilege escalation part). Similarly, it is highly likely that an exploit can bypass KNOX – Samsung’s security enhancement features. The reason is that the the KNOX implementation relies on SEAndroid access control and validation that the SEAndroid was not compromised. The validation of SEAndroid is checked by KNOX’s TrustZone component, and it is only a question of how easy it is to bypass it. Admittedly, we have not tested this against KNOX but our argument receives support by the fact that a patch for certain KNOX devices was rolled out.

5. Corresponding exploits bypass various 3rd party security protections such as:
MDM, secure containers, wrappers protections, as well as mobile anti-virus (AV) and other signature-based technologies
Since this vulnerability can be exploited using a myriad of system calls there is no simple way to block the different possible exploits without fixing the security flaw. Additionally, signature analysis on applications will not be able to sign on all possible exploit possibilities.
Furthermore, such an exploit can easily lead the way to the installation of a mobile remote access trojans (mRAT) which can bypass MDM solutions, as we’ve demonstrated at Blackhat.

6. Remains unpatched by most vendors
We do know that the official Google devices, branded as Nexus, running Android version 4.4 are patched. It is also seems that some Samsung Galaxy devices running Open Europe ROM are patched. What about the rest? It’s not clear which and when the devices were or will be patched.

Some Technicalities

Now that we’ve surfaced the severity of the vulnerability, it’s time to dive into the technical waters.

The vulnerability exists in the Linux Kernel on ARM devices. In certain scenarios when the kernel copies data between user-space and kernel-space, certain checks are not enforced. This means that a normal application can read and write to/from arbitrary places in the kernel.

A common way to exploit this vulnerability is to overwrite the uevent_helper field in the kernel. This field specifies which process the kernel is currently running in order to notify the user-space of hardware events. Although this field is generally not used by Android (a different mechanism is typically used for event notification), it usually remains active.

Similarly, an attacker can exploit this vulnerability to disable SELinux. This is usually trivially done by overwriting the value of the selinux_enforcing field in the kernel.

Predictions, Predictions, Predictions

While many believed that SEAndroid would provide the adequate protection that enterprise users so desperately need, this vulnerability demonstrates that SEAndroid does not provide the silver bullet.

Looking forward towards 2014, we can assume that Google will continue its work towards fortifying the Android operating system. Consequently, we believe that attackers will become more creative in their attempts to bypass SEAndroid. More so, we can expect to see more focus on other attack surfaces, especially:

• Specific OEM changes and additions to the standard Android operating systems
• Hardware drivers relevant to the various device models