The Way To Android Root: Exploiting Smartphone GPU

The Way To Android Root: Exploiting Smartphone GPU

Speakers: Xiling Gong, Security Researcher, Android Red Team (Google); Eugene Rodionov, Tech Lead, Android Red Team (Google); Shishin, Manager, Android Red Team (Google)

Conference: DEF CON 32

YouTube: https://www.youtube.com/watch?v=BN07rjaNqXk

Overview

In "The Way To Android Root: Exploiting Smartphone GPU," members of the Android Red Team — Shishin, Xiling Gong, and Eugene Rodionov — unveiled a critical vulnerability, CVE 2024 23380, within Qualcomm Adreno GPU drivers that allowed for an unprivileged application to achieve root privileges on Android smartphones. The talk dissects the architecture of Adreno GPUs, highlights the inherent security risks associated with GPU drivers, and details the specific memory management flaw that was exploited. This research underscores the persistent challenges in securing complex hardware-software interfaces in modern mobile devices.

The significance of this work stems from several factors. Firstly, GPU drivers operate with high privileges and are directly exposed to unprivileged user-space applications, making them an attractive target for attackers seeking to bypass Android's robust security model. Secondly, the widespread adoption of Qualcomm's Adreno GPUs across numerous Android devices amplifies the potential impact of such vulnerabilities. The presentation not only reveals a severe weakness but also provides a comprehensive methodology for identifying and exploiting similar issues, offering valuable insights for both offensive and defensive security practitioners.

Background

▶ Watch: Talk introduction and speaker overview (0:00)

The Android Red Team, a specialized unit focused on enhancing the security of Android and Pixel devices, operates by simulating advanced adversaries to identify and mitigate potential threats. Their methodology involves offensive security research, verifying security assumptions, developing tools like continuous fuzzing and static analysis, creating proof-of-concept exploits to demonstrate real-world impact, and rigorously assessing the efficacy of implemented security mitigations. This talk exemplifies their commitment to making Android more secure by proactively identifying vulnerabilities in critical system components.

The team's decision to focus on GPU drivers is strategic, driven by several key characteristics that make them a high-value target for privilege escalation. Crucially, GPU drivers require no special permissions for user-space applications to interact with them. Unprivileged applications, through libraries like OpenGL or Vulkan, communicate directly with the GPU device node in the kernel. This direct exposure means that any vulnerability in the driver can be triggered without prior authorization, bypassing Android's permission model.

Furthermore, GPU drivers are designed for extreme performance, necessitating powerful functions that often involve direct access to system physical RAM. This capability allows them to map user-space memory directly into kernel space and to the hardware without costly memory copying operations. While essential for performance, this primitive is extremely powerful and, if misused, can be leveraged by attackers to achieve arbitrary kernel memory read/write capabilities. The speakers also noted that Qualcomm's Adreno GPU is a dominant force in the smartphone System-on-Chip (SoC) market, making it a high-impact target. The constant evolution of GPU architectures to meet the demands of high-resolution gaming and faster frame rates introduces significant changes in both hardware and software, often leading to the introduction of new bugs. The recent introduction of a new architecture, starting from Adreno Generation 7, was a specific catalyst for this research, as new architectures often mean new opportunities for vulnerabilities.

The core of the Adreno GPU's interaction with user space is the KGSL driver, which acts as the intermediary between applications and the hardware. User-space applications interact with KGSL through a set of interfaces:

• Context interfaces: To identify applications and manage GPU resources.
• Memory interfaces: To share memory with the GPU hardware. These include basic memory, user-space memory, and DMA memory, with sparse memory having been deprecated.
• Command interfaces: To send custom GPU commands.
• Synchronization interfaces: To synchronize operations with the GPU hardware.

In older Adreno architectures, a command queue received user-space commands, which a software dispatcher then processed, modified, and sent to a ring buffer for execution by GPU firmware and hardware. However, with the Adreno Generation 7 and later architectures, a significant change occurred: the software dispatcher was replaced by a hardware scheduler. In this newer model, the driver sends commands directly to a high-fi command queue, and a simple firmware takes over the dispatching role. This architectural shift, designed for efficiency, inadvertently introduced new complexities and potential vulnerabilities in how commands and memory are managed, particularly concerning the IOMMU (Input/Output Memory Management Unit), which controls GPU memory access. Analysis of recent Qualcomm security bulletins showed a concentration of issues in the IOMMU area, validating the team's focus on physical memory and memory management.

Key Findings

▶ Watch: Reasons for targeting Qualcomm Adreno GPU (4:30)

The primary finding of this research is the identification and successful exploitation of CVE 2024 23380, a critical vulnerability in Qualcomm Adreno GPU drivers that allows unprivileged Android applications to gain root privileges. This vulnerability specifically impacts devices utilizing the newer Adreno Generation 7 and later architectures, highlighting the security implications of significant architectural shifts in complex hardware components.

The root cause of CVE 2024 23380 was determined to be an IOMMU misconfiguration related to the handling of Virtual Buffer Objects (VBOs). VBOs, a memory type introduced in newer Adreno generations, are designed to provide virtual GPU address space without initially being backed by physical memory. While intended to offer flexible memory management, the interactions between VBOs and other memory types, particularly during remapping operations, presented a critical attack surface. The speakers emphasized that vulnerabilities in memory management, especially those affecting the IOMMU, are often easy to exploit and yield stable primitives, making them highly attractive to attackers.

The exploitation of this flaw provided the Android Red Team with a powerful primitive that could be leveraged for arbitrary kernel memory manipulation or information leakage, ultimately enabling them to achieve full root access on a vulnerable Android device. This finding reinforces the notion that even subtle flaws in the intricate dance between user-space drivers, kernel modules, and specialized hardware components like the GPU can have profound security consequences, undermining the entire system's security posture.

Technical Deep Dive

▶ Watch: Overview of Adreno GPU architecture (6:00)

The technical core of CVE 2024 23380 lies within the management of Virtual Buffer Objects (VBOs) and their interaction with the Adreno GPU's memory management unit. VBOs, introduced in Adreno Generation 7 and later, represent a departure from traditional memory objects. When a user-space application creates a VBO using an ioctl call like KGSL_IOC_GPUOBJ_CREATE with the KGSL_GPUOBJ_MEM_TYPE_VIRTUAL flag, the driver allocates a virtual GPU address range. Crucially, this address space is initially mapped to a dummy zero page and lacks its own dedicated physical backend memory. Consequently, any attempt to read from or write to this initial VBO via the GPU hardware would have no effect, as it's merely a placeholder.

The utility of a VBO comes from its ability to bind existing basic memory objects – which do have their own backend physical memory – into its virtual address space. This is achieved through another ioctl, KGSL_IOC_GPUOBJ_BIND_RANGE. The process involves several critical steps:

1. Removal of existing mappings: The driver first removes any existing mappings from the VBO. This includes the initial dummy zero page mapping or any previously bound basic memory objects.
2. Insertion of new mappings: The driver then establishes a new connection between the specified basic memory object and the VBO. This is typically managed through data structures like an interval tree (e.g., interval_tree_insert), which tracks the mapping of physical memory ranges to the VBO's virtual address space.

Once this binding is complete, the GPU's IOMMU is configured to allow the GPU hardware to access the physical pages of the bound basic memory object via the VBO's GPU virtual address. The vulnerability, as stated by the speakers, stems from an IOMMU misconfiguration during this complex remapping process. While the precise details of the flaw (e.g., a specific race condition, an integer overflow, or an incorrect permission check) were not fully elaborated in the public talk to prevent "tipping off" other parties, the context strongly suggests that the misconfiguration arises from an error in how the driver manages the IOMMU's translation tables or access controls during the KGSL_IOC_GPUOBJ_BIND_RANGE operation.

For instance, potential scenarios could involve:

• Use-After-Free (UAF): If a basic memory object is unmapped or freed while its entry in the IOMMU translation tables remains active or is incorrectly re-used by a VBO, it could lead to the GPU accessing freed kernel memory.
• Incorrect Permissions/Range Checks: The driver might fail to properly validate the memory ranges or permissions of the basic memory object being bound to the VBO, potentially allowing an unprivileged application to map sensitive kernel memory regions or memory belonging to other processes.
• Race Conditions: Concurrent KGSL_IOC_GPUOBJ_BIND_RANGE or unmapping operations on the same VBO or related memory objects could lead to an inconsistent state in the IOMMU, where a VBO's virtual address points to an unintended physical address.

Such an IOMMU misconfiguration provides a powerful primitive: the ability to read from or write to arbitrary physical memory addresses from the GPU's perspective. Since the GPU operates with high privileges, this translates directly into an arbitrary kernel memory read/write primitive for the attacker. With this primitive, an attacker can:

1. Bypass Kernel Address Space Layout Randomization (KASLR): By reading kernel memory, an attacker can locate critical kernel structures and bypass KASLR.
2. Modify Kernel Data Structures: Overwrite pointers, alter security-critical flags (e.g., changing process cred structures to gain root privileges), or inject arbitrary code into kernel modules.
3. Execute Arbitrary Kernel Code: By modifying function pointers or injecting shellcode into writable kernel memory, an attacker can achieve arbitrary code execution in kernel mode, leading to full root access.

The complexity of the new hardware scheduler architecture and the firmware's role in command dispatching, combined with the intricate memory management of VBOs, created a fertile ground for this type of subtle yet devastating vulnerability. The team's deep dive into these new architectural changes proved instrumental in uncovering CVE 2024 23380.

Demo / Proof of Concept

▶ Watch: Analysis of common Adreno GPU vulnerability patterns (8:00)

The speakers explicitly stated that they developed a proof of concept (PoC) to demonstrate the real-world impact of CVE 2024 23380, successfully exploiting the vulnerability to gain root privileges on a vulnerable Android device. While the transcript mentions "So that's the demo" at one point, it immediately transitions to the agenda, indicating that the visual or auditory details of the actual demonstration were not included in the provided text. However, the successful development of a PoC to achieve root privilege underscores the severity and exploitability of this IOMMU misconfiguration. The PoC would have involved crafting specific ioctl calls to manipulate VBOs and basic memory objects in a way that triggers the IOMMU misconfiguration, followed by leveraging the resulting memory primitive to achieve kernel code execution and elevate privileges.

Defensive Implications

▶ Watch: Introduction to CVE 2024-23380 for root privilege (9:15)

The discovery and exploitation of CVE 2024 23380 offer several crucial defensive implications for Android security, GPU driver development, and general system hardening:

1. Enhanced Scrutiny of GPU Drivers: The most immediate implication is the need for increased security auditing and fuzzing of GPU drivers. Given their unprivileged access from user space and their powerful direct memory access capabilities, GPU drivers represent a significant and often underestimated attack surface. Manufacturers must prioritize their security as much as other kernel components.

1. Robust IOMMU Implementation and Verification: The vulnerability highlights critical weaknesses in IOMMU configuration and memory management. Defenders, and particularly GPU vendors like Qualcomm, must implement stricter checks and validation processes for all memory mapping and unmapping operations involving the IOMMU. This includes rigorous range and permission checks, careful state management during remapping, and robust handling of race conditions in memory allocation and deallocation.

1. Security-Aware Architectural Design: Major architectural changes, such as the transition to a hardware scheduler in Adreno Generation 7, must undergo thorough security reviews from their inception. New components, especially those that take over critical tasks previously handled by software (like command dispatching), introduce new attack surfaces and interaction complexities that require dedicated security analysis.

1. Continuous Patch Analysis and Variant Analysis: The Android Red Team successfully identified this vulnerability through manual code review and patch analysis, specifically by examining security fixes published in the Android Qualcomm security bulletin and reviewing research from other security researchers. This methodology proved highly effective for a complex target like the GPU driver, emphasizing that understanding previous vulnerabilities and their fixes can lead to the discovery of variant bugs in related code paths. This approach should be a standard practice for security teams.

1. Scalable Fuzzing Strategies: While fuzzing is recognized as a highly efficient method for finding bugs, its application to GPU kernel modules presents unique challenges. On-device fuzzing, though effective for hardware-dependent bugs like IOMMU misconfigurations, is less scalable than pure software fuzzing. GPU vendors should explore enabling architecture-independent builds of kernel mode components to allow for software-only fuzzing of generic functionality. Furthermore, emulation-based fuzzing, while requiring significant upfront effort to accurately model hardware behavior, offers a scalable alternative for uncovering complex hardware-software interaction bugs. Investing in these advanced fuzzing capabilities is vital for proactive security.

1. Improved Memory Safety Measures: The underlying issue points to potential memory safety problems. Implementing modern memory safety features and leveraging languages or compiler options that reduce the likelihood of memory corruption bugs in kernel drivers could significantly mitigate similar vulnerabilities.

1. Collaboration and Information Sharing: The speakers mentioned the importance of reviewing external security research. Continued collaboration and responsible disclosure between security researchers, device manufacturers, and SoC vendors are essential to collectively raise the security bar for Android devices.

Key Takeaways

• GPU drivers are a critical, high-impact attack surface due to their direct exposure to unprivileged user applications and their ability to access system physical RAM.
• New GPU architectures, like Adreno Generation 7 and later, introduce novel attack surfaces, necessitating dedicated security research to uncover vulnerabilities like CVE 2024 23380.
• IOMMU misconfigurations, particularly in complex memory management schemes like Virtual Buffer Objects (VBOs), can lead to severe privilege escalation by enabling arbitrary kernel memory access.
• Patch analysis and variant analysis are highly effective methodologies for identifying new vulnerabilities in complex, actively developed codebases like GPU drivers, building upon prior disclosed issues.
• On-device fuzzing is essential for hardware-dependent vulnerabilities, but overcoming scalability challenges through architecture-independent driver builds or emulation-based fuzzing is crucial for comprehensive security testing.
• Robust memory management, stringent IOMMU configuration, and proactive security reviews during architectural changes are paramount for enhancing the security of modern smartphone GPUs.

About the Speaker(s)

The presentation was delivered by a team from the Android Red Team at Google, dedicated to improving the security posture of Android and Pixel devices.

Shishin is the Manager of the Android Red Team. He introduced the team's mission to increase Android and Pixel security by simulating adversaries, conducting offensive security research, developing tools, and assessing security mitigations.

Xiling Gong is a Security Researcher on the Android Red Team. He was credited with performing "most of the technical work" involved in discovering and exploiting the vulnerability, leading the deep dive into the Adreno GPU architecture and the specifics of CVE 2024 23380.

Eugene Rodionov serves as a Tech Lead on the Android Red Team. He played a significant role in assisting with the presentation, including slide creation and ensuring the smooth execution of the demo. He also discussed the methodologies used for vulnerability discovery, such as patch analysis and fuzzing.

The team's work is part of Google's broader efforts in Android security, with their research often published on Android offsec with google.com.