The IBM X-Force Application Security Research Team recently discovered an arbitrary write vulnerability in Nexus 9’s kernel (the Tegra kernel branch). Google’s Android Security Team acknowledged the vulnerability, which allows a privileged attacker to arbitrary write values within kernel space, and assigned it a high severity rating.

Kernel arbitrary write primitives can be used to achieve kernel code execution, which completely compromises the security of the device, not including TrustZone. It increases the TrustZone attack surface and allows attackers to access application data and override the Security-Enhanced Linux (SELinux) policy.

The vulnerability has existed since Nexus 9’s inception back in November 2014. It was reported to the Android Security Team on June 20, 2016, and fixed on Sept. 5, 2016. This flaw was verified on what were then the latest Nexus 9 images:

Vulnerable Code in the Nexus 9

The registers debugfs file node is initialized with the following write file operation:

That is, on write system call, cl_register_write() securely copies a user space buffer and parses its contents as two numeric values: val, a value to be written, and offs, an offset from a constant address. Cl_dvfs_writel() is then fed with val and offs (cast into a four-byte aligned address).

Eventually, __raw_writel() is used to write value val at offs+, which results in an arbitrary kernel write.

The vulnerability is reminiscent of an issue previously disclosed by security researcher Marco Grassi.

Attack Surface Analysis

We analyzed the Discretionary Access Control (DAC) and Mandatory Access Control (MAC; SELinux on Android) to find out which active processes can trigger the vulnerability.

DAC-wise, who can write to the file?

The attacker must execute code under root within the debugfs SELinux context:

SELinux-wise, what contexts can write to a debugfs file?

To find out which SELinux contexts can trigger the vulnerability, we analyzed Nexus 9’s (MOB30M) sepolicy. We need to find SELinux domains with allow rules that have target type debugfs with the open and write permissions on the file class.

Analyzing Nexus 9’s sepolicy (MOB30M) yields:

That is, SELinux-wise, any domain can open, write and append to any file with the debugfs context.

What active processes can trigger the vulnerability? Analyzing active processes on the device yields the following:

Code execution within any of the processes above can trigger and exploit the vulnerability.

Last Words

To exploit the vulnerability from an untrusted application security context, start by escalating privileges from an untrusted app to one of the contexts of the aforementioned processes. For instance, CVE-2016-0807, disclosed by Zach Riggle, may be used, since it allows an untrusted app to execute code within debuggerd.

The commit that fixed the vulnerability indicates that Google simply removed the registers file from the debug file system. Clearly, the registers file node was not needed on production builds.

Visit the X-Force exchange to learn more about vulnerabilities

More from Software Vulnerabilities

X-Force releases detection & response framework for managed file transfer software

5 min read - How AI can help defenders scale detection guidance for enterprise software tools If we look back at mass exploitation events that shook the security industry like Log4j, Atlassian, and Microsoft Exchange when these solutions were actively being exploited by attackers, the exploits may have been associated with a different CVE, but the detection and response guidance being released by the various security vendors had many similarities (e.g., Log4shell vs. Log4j2 vs. MOVEit vs. Spring4Shell vs. Microsoft Exchange vs. ProxyShell vs.…

MSMQ QueueJumper (RCE Vulnerability): An in-depth technical analysis

13 min read - The security updates released by Microsoft on April 11, 2023, addressed over 90 individual vulnerabilities. Of particular note was CVE-2023-21554, dubbed QueueJumper, a remote code execution vulnerability affecting the Microsoft Message Queueing (MSMQ) service. MSMQ is an optional Windows component that enables applications to exchange messages via message queues that are reachable both locally and remotely. This analysis was performed in collaboration with the Randori and X-Force Adversary Services teams, by Valentina Palmiotti, Fabius Watson, and Aaron Portnoy. Research motivations…

X-Force prevents zero day from going anywhere

8 min read - This blog was made possible through contributions from Fred Chidsey and Joseph Lozowski. The 2023 X-Force Threat Intelligence Index shows that vulnerability discovery has rapidly increased year-over-year and according to X-Force’s cumulative vulnerability and exploit database, only 3% of vulnerabilities are associated with a zero day. X-Force often observes zero-day exploitation on Internet-facing systems as a vector for initial access however, X-Force has also observed zero-day attacks leveraged by attackers to accomplish their goals and objectives after initial access was…

Topic updates

Get email updates and stay ahead of the latest threats to the security landscape, thought leadership and research.
Subscribe today