AI Accelerated Exploiting: Compromising MTE Enabled Pixel from DSP Coprocessor

AI Accelerated Exploiting: Compromising MTE Enabled Pixel from DSP Coprocessor

Speakers: Bing-Jhong Jheng (Principal Researcher, STAR LABS); Pan ZhengPeng (Principal Researcher, STAR LABS SG)

Conference: CODE BLUE

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

Overview

This talk, presented by Bing-Jhong Jheng (Billy) and Pan ZhengPeng (Peter) from STAR LABS, delves into the discovery and exploitation of a novel vulnerability within the Graphics System Processor (GSP) Digital Signal Processor (DSP) coprocessor found in Google Pixel devices, specifically targeting models from Pixel 7 onwards. The researchers detail a "write to read-only" primitive that allows an attacker to bypass memory protections and achieve local privilege escalation (LPE) on Android. A significant aspect of their research is demonstrating how this logical vulnerability can circumvent Memory Tagging Extension (MTE), a cutting-edge hardware-based mitigation designed to prevent memory corruption bugs, which is being progressively rolled out in newer ARM processors and Pixel devices.

The significance of this research lies in several key areas. Firstly, it uncovers a new attack surface within Google's custom Tensor chip architecture, specifically the GSP, which was introduced with the Pixel 7 in 2022 and had very little public security research prior to this work. Secondly, it provides a comprehensive methodology for reverse engineering and exploiting closed-source coprocessors, a common challenge in modern mobile security. Most importantly, the talk highlights the limitations of even advanced hardware mitigations like MTE against certain classes of vulnerabilities, specifically logical flaws that manipulate memory access permissions rather than directly corrupting memory. This work offers crucial insights for both Android platform defenders and security researchers aiming to understand and counter sophisticated threats on contemporary mobile devices.

Background

▶ Watch: Introduction: Targetting the new GSP coprocessor (0:00)

The Android ecosystem is fortified with a layered defense strategy, incorporating numerous security mitigations to protect against exploits. These include kernel-level protections such as Page No-Execute (PN), Privileged System No-Execute (PSN), Use-After-Free (UAF) detection, Control Flow Integrity (CFI), Pointer Authentication Codes (PAC), Memory Tagging Extension (MTE), and Kernel Address Space Layout Randomization (KASLR). Google further enhances security with kernel configurations like IT-SE and an init heap blocklist, while manufacturers like Samsung add their own mitigations such as KO-defs and physical ASLR. Despite these robust defenses, the ever-evolving landscape of attack surfaces continues to present challenges.

Exploits can be categorized by their attack surface. Universal exploits target foundational Android components (e.g., kernel, Binder IPC, TCP/UDP sockets), affecting a wide range of devices. Chipset exploits leverage vulnerabilities in specific GPU or DSP architectures (e.g., Mali, Qualcomm). Vendor exploits are limited to specific drivers or modules unique to a particular vendor's hardware (e.g., Samsung MPU/GPU). The research presented here falls into the module-specific category, targeting Google Pixel's custom drivers, specifically the GSP (Graphics System Processor).

The researchers chose to focus on the GSP for several compelling reasons. It was a newly introduced attack surface in 2022 with the Pixel 7, meaning there was scant public information, tools, or prior research available, and no known CVEs related to it. While initially, untrusted Android Package (APK) content cannot directly open the GSP device, it can perform ioctl syscalls. Access to the GSP device file descriptor (FD) can be obtained through specific services like HTTP_AP_Service, which utilizes the libgtu_client.so library's google_dsp_fd function. This service, however, performs signature verification, only allowing applications on an internal whitelist to access the GSP FD. Crucially, the researchers noted that if an attacker could execute code within a whitelisted application or bypass this signature verification, the GSP attack surface would become accessible.

Prior research on other coprocessors, such as Mali GPUs, Qualcomm GPUs/DSPs, and Samsung GPUs, provided a foundation for understanding potential bug patterns. These included "write to read-only" vulnerabilities (e.g., CVE-2022-0847, known as Dirty Pipe, which allowed modifying normally read-only files), page Use-After-Free (UAF) in imported GPU memory, and shrinker page UAF (e.g., CVE-2024-32929), often triggered under memory pressure. The GSP, while distinct from the HTPU (another Google coprocessor that suffered from CVE-2023-35645 due to a race condition), presented a similar opportunity for novel vulnerability discovery due to its complex interaction with kernel memory.

Key Findings

▶ Watch: Proof of Concept: Successfully writing to read-only memory (18:15)

The central discovery of this research is a critical vulnerability located within the GSP kernel driver, specifically in the gxp_mapping_create function. This function, directly reachable via the gxp_map_buffer ioctl, is responsible for mapping user-provided memory regions for the GSP coprocessor. The core flaw stems from insufficient validation of user-supplied parameters.

The researchers identified that a user-controlled dir parameter, intended to specify the DMA direction (e.g., read, write, bidirectional), was passed into the kernel. While the FO_flex (file operation flags) were initially set to allow both read and write access and later updated based on memory attributes, a critical synchronization issue existed. The mapping_dir_attributes field, which dictates the DMA direction for the GSP's Memory Management Unit (MMU), was assigned directly from the user-supplied dir parameter without any subsequent validation or checks. This allowed an attacker to continuously pass the DMA_bidirectional flag, even if the CPU-side memory region was marked as read-only. Consequently, the GSP's MMU would treat the system memory as both readable and writable, effectively creating a "write to read-only" primitive.

This theoretical primitive was then successfully validated and weaponized. The researchers demonstrated that even if a memory region was explicitly marked as read-only on the CPU side, the GSP could be tricked into writing data to it. This "write to read-only" capability forms the foundation of their local privilege escalation (LPE) exploit chain.

In response to the report, Google undertook a significant refactoring of the GXP driver. The patch ensures that the driver now correctly obtains the Get User Page (GUP) flags from the host address VMA. These GUP_flags are then used to derive GCIP_map_flags, which are subsequently passed to the GCIP_MMU_domain_map_buffer_sgt function to perform the device-side MMU mapping. This corrected flow ensures that the GSP's MMU respects the original permissions of the host memory, preventing the read-only bypass. Furthermore, Google also took the defensive measure of directly removing the feature that allowed third-party applications to utilize the GSP driver, significantly reducing the attack surface.

Crucially, the research also highlights a fundamental limitation of Memory Tagging Extension (MTE). While MTE is highly effective at detecting memory corruption vulnerabilities like out-of-bounds access or use-after-free, it is inherently ineffective against logical vulnerabilities such as the "write to read-only" primitive discovered here. MTE operates by tagging memory and pointers to ensure valid access patterns, but it cannot prevent a legitimate, albeit misconfigured, hardware component (like the GSP) from performing an operation that violates the intended access policy if the underlying logic allows it. This confirms that logical bugs, especially those involving complex coprocessor interactions, can bypass even advanced hardware mitigations.

Technical Deep Dive

▶ Watch: Exploitation: Hijacking camera provider for LPE (21:20)

The vulnerability resides within the gxp_mapping_create function, which is invoked by the gxp_map_buffer ioctl. This function is critical for preparing user-space memory regions for access by the GSP coprocessor. During its execution, the function receives a user-controlled dir parameter. This parameter is intended to specify the direction of data transfer for Direct Memory Access (DMA) operations, such as DMA_TO_DEVICE (write), DMA_FROM_DEVICE (read), or DMA_BIDIRECTIONAL (read and write).

The core of the flaw is a logical inconsistency in how memory access permissions are handled. Initially, the FO_flex (file operation flags) are set to allow both read and write access. While these flags are later updated based on the memory attributes retrieved from user space, there is a critical disconnect concerning the mapping_dir_attributes. The mapping_dir_attributes field, which is directly responsible for configuring the GSP's internal Memory Management Unit (MMU), is assigned its value directly from the user-supplied dir parameter without any further validation against the actual memory permissions (e.g., whether the CPU-side VMA is read-only). This means that if an attacker provides the DMA_BIDIRECTIONAL flag in the dir parameter, the GSP's MMU will configure the imported memory region as both readable and writable, regardless of whether the CPU-side virtual memory area (VMA) is marked as read-only. This creates a powerful "write to read-only" primitive.

Validating this theoretical primitive posed significant challenges. Standard GPU exploitation techniques often involve remapping the imported GPU memory back into a different CPU VMA with read-write permissions, or using existing OpenCL frameworks or reverse-engineered IOCTLs to trigger GPU-side writes. However, the GSP presented a unique situation: it does not remap imported memory back into another CPU address space, and there is no public documentation, tooling, or an OpenCL stack available for it. This meant that traditional methods for validating GPU-side writes were not readily applicable.

The researchers initially attempted to emulate the GSP firmware. This involved several steps:

1. Locating the firmware: The firmware resource was found in the device tree, with the R.start field holding its physical start address.
2. Mapping the firmware: The device_mem_map function was used to map this physical region into the kernel virtual address space.
3. Dumping and analysis: The mapped memory was dumped for offline analysis using tools like IDA Pro, confirming it contained strings related to DSPs, ring buffers, and mailboxes.

However, this emulation approach proved impractical. The firmware's hardware architecture was not fully supported by QEMU, leading to numerous instructions (e.g., MSR, MRS) behaving incorrectly. Compounding this, the firmware lacked symbols, making reverse engineering extremely tedious.

Faced with these hurdles, the researchers pivoted to a replay attack methodology. The core idea was to dynamically instrument and trace applications that use the GSP driver to observe actual memory access patterns.

1. Identifying target applications: From earlier analysis of the SELinux policy, Google Camera was identified as a commonly installed, default application that frequently interacts with the GSP driver.
2. Library identification: Inspecting Google Camera's memory mappings revealed libgxp.so, a shared library responsible for communicating with the GSP driver, analogous to libmali.so for Mali GPUs. Function names within libgxp.so (e.g., create_device, create_buffer) hinted at its functionality, similar to OpenCL interfaces.
3. Dynamic instrumentation: Frida was employed for dynamic instrumentation, hooking the ioctl function within Google Camera. This allowed tracing function calls and sequences.
4. Discovery of the problematic call: Through this process, the GXP_copy_open_name_library_from_buffer function in libgxp.so was identified as the entry point that eventually reached the vulnerable driver code.

With this knowledge, a working Proof of Concept (PoC) was developed. By creating a block of read-only memory initialized to zero, then calling GXP_copy_open_name_library_from_buffer and tweaking specific ioctl parameters, the researchers successfully demonstrated that the GSP coprocessor could write the string "aaa" into this supposedly read-only memory region. This conclusively validated the "write to read-only" primitive.

The exploit chain for local privilege escalation leveraged this primitive. The initial idea was similar to Dirty Pipe, where libc.so or liblog.so could be modified to hijack the init process, then use setprop to trigger init to write a kernel module payload, which would then be loaded to disable SELinux and gain root. However, a significant obstacle was that the init process, due to SELinux policies, lacked the necessary permissions to ioctl and open the GSP device.

The researchers then targeted the android.hardware.camera.provider process. This process does have the necessary SELinux permissions to interact with the GSP. The challenge was hijacking it from an untrusted application, as the PID of camera.provider is generally unknown. The solution involved using the init process, which can set its Group ID (GID) to prop (3009), allowing it to obtain the PID of camera.provider from the next_kernel_call. By forcing init to kill camera.provider, the process would restart, providing an opportunity for hijacking.

The full LPE exploit process was as follows:

1. Override libandroid_runtime.so: A malicious version of this library was prepared.
2. Hijack libc and liblog: The "write to read-only" primitive was used to modify libc.so and liblog.so, targeting both the init process and the camera.provider.
3. Force camera.provider restart: The hijacked init process was used to terminate camera.provider, forcing it to restart.
4. Load malicious library: During restart, camera.provider would load the attacker's controlled libandroid_runtime.so.
5. Write kernel payloads: The now-hijacked camera.provider utilized the "write to read-only" primitive to write two payloads: a mod payload (which launched a reverse shell) and a libc_2_b_list.so payload (which installed a kernel module).
6. Execute and gain root: Finally, init executed mod_pop, loading the kernel module to disable SELinux and obtain a root shell on the Pixel device. A screenshot of the resulting reverse shell was presented as proof.

To achieve this from a low-privileged untrusted application, two methods were discussed:

1. "Bring Your Own Vulnerability" (BYOV) application: Exploiting a vulnerable version of a whitelisted application (e.g., YouTube Kids, YouTube Music) to gain code execution, then chaining it with the GSP exploit.
2. UID reuse attack via PackageManagerService (PMS) crash: This more general method exploits a flaw in how Android manages UIDs. Normally, the M_first_available_ap_id prevents UID reuse. However, if the PackageManagerService crashes and restarts, M_first_available_ap_id resets to PROCESS_FIRST_AID. The attack sequence is: install attacker APK, uninstall it, crash the PMS, then install a whitelisted app (e.g., YouTube Kids). This results in the whitelisted app being assigned a UID under the attacker's control, granting access to the GSP driver. This combined with the GSP bug leads to kernel execution from a show user.

Demo / Proof of Concept

▶ Watch: Analysis: MTE (Memory Tagging Extension) limitations (27:00)

The talk included a clear demonstration of the core vulnerability and its exploitation. For the "write to read-only" primitive, the researchers presented a screenshot showing a block of memory that was initially created as read-only and initialized to all zeros. After invoking the relevant GSP functions and leveraging the vulnerability through a hooked ioctl call to manipulate the DMA direction, the coprocessor successfully wrote the hexadecimal value 0x616161 (representing "aaa") into this otherwise protected memory region. This visual confirmation served as definitive proof of the primitive's functionality.

Furthermore, the full local privilege escalation exploit chain was demonstrated, culminating in the acquisition of a reverse shell on a target Pixel device. A screenshot of this reverse shell was displayed, confirming that the multi-stage attack successfully bypassed Android's security mechanisms, including SELinux, to achieve root privileges. The demonstration effectively illustrated the practical impact of the vulnerability and the sophisticated chaining required to achieve full system compromise.

Defensive Implications

▶ Watch: VRP Timeline: From $250 to $32K bounty (30:50)

The research by STAR LABS carries significant defensive implications for Android security, particularly concerning coprocessor interactions and advanced hardware mitigations.

Firstly, Google's response to the reported vulnerability provides a direct defensive measure. The GXP driver was refactored to correctly obtain Get User Page (GUP) flags from the host address VMA and derive GCIP_map_flags from them, ensuring that the GSP's MMU respects the original memory permissions. Beyond this specific patch, Google also directly deleted the feature that allowed third-party applications to use the GSP driver, effectively removing the attack surface for untrusted applications altogether. This highlights a critical strategy: reduce attack surface by removing unnecessary functionality.

Secondly, the findings underscore the limitations of hardware-based mitigations like Memory Tagging Extension (MTE). While MTE is a powerful defense against memory corruption (e.g., out-of-bounds writes, use-after-free), it is ineffective against logical vulnerabilities such as the "write to read-only" primitive discovered in the GSP. MTE tags memory and pointers to ensure valid access patterns, but it cannot detect when a legitimate operation, albeit based on flawed permission logic, bypasses intended security boundaries. Defenders should recognize that MTE is not a panacea and that logical flaws will continue to be a potent threat vector. This implies a continued need for thorough security audits of complex logic, especially in driver code interacting with coprocessors.

Thirdly, the success of the replay attack methodology for reverse engineering closed-source firmware and drivers offers a valuable lesson. For highly opaque components like DSPs and GPUs, dynamic instrumentation (e.g., using Frida) combined with observing application-level interactions can be a highly efficient way to understand driver functionality and identify potential vulnerabilities, especially when static analysis is hampered by lack of symbols or non-standard architectures.

Finally, the discussion on the UID reuse attack via PackageManagerService (PMS) crashes points to a broader systemic issue. Exploiting the reset of M_first_available_ap_id allows an attacker to control the UID of a whitelisted application, effectively granting access to privileged resources like the GSP driver from a low-privileged starting point. This highlights the importance of robust error handling and state management in critical system services like PMS to prevent such control flow manipulation. Defenders should ensure that system services are resilient to crashes and that their state management prevents security-sensitive resets. The talk also implicitly calls for runtime signature checks on Android phones to prevent logical bugs from being exploited, as such checks could verify the integrity of loaded components and prevent malicious modifications.

Key Takeaways

• Closed-Source Exploitation: For closed-source products and devices, a record and replay attack strategy, leveraging dynamic instrumentation tools like Frida, is an efficient and effective method for reverse engineering driver interactions and identifying vulnerabilities.
• MTE Bypass: Page-level memory corruptions in coprocessors or logical bugs that manipulate memory access permissions (like a "write to read-only" primitive) are inherently capable of bypassing Memory Tagging Extension (MTE), as MTE primarily targets memory corruption patterns, not logical flaws.
• Logical Bugs Prevail: Without robust runtime signature checks or stringent logical validation, vulnerabilities such as "write to read-only" primitives will remain a potent threat on Android phones, even against advanced hardware mitigations.
• New Attack Surfaces: Newly introduced hardware components and their associated drivers, such as the GSP in Pixel devices, represent significant, under-researched attack surfaces that can yield critical vulnerabilities.
• UID Reuse for Privilege Escalation: A vulnerability in PackageManagerService (PMS) that allows UID reuse upon a PMS crash can be chained with other bugs to achieve local privilege escalation from a low-privileged user by allowing an attacker to control the UID of a whitelisted application.
• Complex Exploit Chains: Achieving full system compromise on modern Android devices often requires multi-stage exploit chains that combine multiple vulnerabilities and techniques (e.g., UID reuse, process hijacking, kernel module injection) to bypass layered defenses like SELinux.

About the Speaker(s)

Bing-Jhong Jheng (Billy) is a Principal Researcher at STAR LABS. His research focuses on security vulnerabilities and exploitation techniques across both iOS and Android platforms. He has previously shared his findings and expertise as a speaker at renowned security conferences such as HACKON, ONE, and POC.

Pan ZhengPeng (Peter) is also a Principal Researcher at STAR LABS SG, specializing in security research for iOS and Android platforms. He has a distinguished history of presenting his past research at prominent international conferences, including Pwn2Own, ZeroCon, Offensive Con, and other notable events in the cybersecurity community.