A 0-Click Exploit Chain For The Pixel 10

A 0-Click Exploit Chain For The Pixel 10

Speakers: Natalie Silvanovich, Security Researcher, Google Project Zero; Seth Jenkins, Security Researcher, Google Project Zero

Conference: OffensiveCon

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

Overview

This talk, presented by Google Project Zero researchers Natalie Silvanovich and Seth Jenkins, details a sophisticated zero-click exploit chain targeting Google Pixel 9 and Pixel 10 devices. The primary objective was to achieve root access on these modern Android phones with no user interaction, initiated merely by sending a text or RCS message containing a malicious audio attachment. This research highlights critical vulnerabilities across the Android media processing pipeline and kernel drivers, demonstrating how seemingly isolated bugs can be chained together to achieve full system compromise.

The significance of this work lies in its comprehensive attack surface analysis and the successful bypass of multiple Android security mitigations, including ASLR (Address Space Layout Randomization) and SELinux (Security-Enhanced Linux). The findings underscore the continuous challenge of securing complex software stacks, particularly those involving proprietary binary blobs and kernel-level components. The talk also provides a valuable retrospective on the effectiveness of current defenses and offers concrete recommendations for improving mobile platform security.

The exploit chain involved three distinct vulnerabilities: an audio codec bug in the Dolby Unified Decoder (UDC), and two separate privilege escalation vulnerabilities in Pixel-specific kernel drivers – one in /dev/bigwave for the Pixel 9 and another in /dev/vpu for the Pixel 10. This talk serves as a stark reminder that even well-sandboxed components can become critical entry points when overlooked or improperly secured, especially as new features like automatic transcription expand the zero-click attack surface.

Background

▶ Watch: Zero-click exploit chain goal for Pixel 10 (1:00)

The motivation for this research stemmed from Google Project Zero's ongoing mission to identify and mitigate severe vulnerabilities in widely used software and hardware. Their specific goal was ambitious: to achieve full root compromise of a modern Pixel device (initially the Pixel 9, later the Pixel 10) through a zero-click vector. This meant gaining control without any user interaction, such as clicking a link or opening a file, merely from receiving a message.

A key enabler for this zero-click scenario on Android is the platform's automatic transcription feature for audio messages. When an RCS or text message containing an audio attachment is received, the device automatically decodes the audio locally to transcribe it. This process exposes every audio codec on the device to a zero-click attack, vastly expanding the potential attack surface for remote code execution. Project Zero's increased interest in audio codecs led to a team hackathon specifically targeting the Dolby format, where the initial vulnerability was discovered within an hour by Ivan Fratric.

The security landscape of Android often focuses on the untrusted_app SELinux context as the primary point of attack for privilege escalation. However, the speakers emphasized the danger of this narrow mindset, highlighting that other less-audited contexts, such as media_codec, isolated_app, media_extractor, and even platform_app, can also be untrusted and offer pathways to system compromise. The media_codec context, where the initial audio vulnerability resided, is intended to be sandboxed, recognizing the inherent risk of processing untrusted media. However, as the research demonstrated, this sandboxing was not sufficiently robust to prevent a full chain exploit.

Furthermore, the talk touched upon the challenges posed by proprietary, closed-source components, such as the Dolby UDC, which are shipped as binary blobs without symbols. This significantly increases the difficulty of security auditing and vulnerability discovery. The subsequent kernel privilege escalation bugs in Pixel-specific drivers (/dev/bigwave and /dev/vpu) underscore the importance of auditing custom hardware drivers, which often handle sensitive operations and can introduce critical flaws if not developed with rigorous security in mind.

Key Findings

▶ Watch: Introducing EMDF, the Extensible Metadata Delivery Format (4:10)

The Project Zero team uncovered a sophisticated, multi-stage zero-click exploit chain that successfully compromised Google Pixel devices. The core findings revolved around three distinct vulnerabilities, each contributing a crucial step towards root access:

1. Zero-Click Remote Code Execution (RCE) in Dolby Unified Decoder (UDC): A critical integer overflow vulnerability was found within the proprietary Dolby Digital Plus (AC3/EAC3) audio codec, specifically in its handling of EMDF (Extensible Metadata Delivery Format). This bug allowed for an out-of-bounds write and an information leak within the media_codec process. Due to Android's automatic audio message transcription, this vulnerability became a zero-click entry point, granting initial code execution within a sandboxed context.

1. Privilege Escalation on Pixel 9 via /dev/bigwave: For the Pixel 9, a use-after-free (UAF) vulnerability was discovered in the custom Google-made bigwave kernel driver, responsible for AV1 video acceleration. This UAF, triggered by a deterministic race condition between the ioctl handler and a kernel worker thread, allowed attackers to achieve an arbitrary write primitive in the kernel. This primitive, combined with a novel KASLR bypass technique leveraging the Linux kernel linear map and proc/self/mounts to leak the ASLR slide, enabled the team to establish a robust arbitrary read/write capability.

1. Privilege Escalation on Pixel 10 via /dev/vpu: Recognizing that the bigwave driver was removed from the Pixel 10, the team identified a new, significantly simpler privilege escalation bug in the /dev/vpu driver. This vulnerability stemmed from a lack of bounds checking in the mmap handler, specifically in how remap_pfn_range was called. This allowed an attacker to map the entire physical kernel memory, including code and data regions, directly into the userland process as read-write, effectively granting full arbitrary kernel read/write and arbitrary code execution with minimal effort.

Key Exploitation Techniques and Mitigation Bypasses:

• Heap Manipulation: Creative use of the Dolby UDC's simple slab allocator ("Evo heap") and Scudo secondary heap properties enabled controlled memory corruption for arbitrary write-what-where.
• SELinux Bypass (media_codec): Initial code execution in media_codec was escalated by mapping shellcode into memory and using a complex ROP chain to call pwrite via proc/self/mem, bypassing seccomp which was unexpectedly not enabled.
• KASLR Bypass: The Pixel's fixed physical kernel address and the ARM64 Linux kernel linear map were leveraged to gain predictable access to kernel .data regions. A further KASLR leak was achieved by hijacking the SELinux_type struct's .name pointer and reading proc/self/mounts.
• Arbitrary Read/Write Primitive: An existing technique involving hijacking the ashmem_fops table was re-implemented, creating a type confusion on struct file's private_data to achieve a flexible kernel read/write primitive.
• Shellcode Simplification: Custom shellcode was developed to operate within tight memory constraints (32KB), minimizing libc dependencies and leveraging LLMs to generate necessary syscall implementations.
• Final Root: The final stage involved disabling SELinux by flipping the SELinux_enforcing flag and then patching the process's cred pointer to point to init_cred, granting full root privileges.

The research also highlighted significant issues with bug prioritization and patching timelines for "low impact" individual bugs that are critical components of a chain, although this aspect showed improvement for the Pixel 10 vulnerability.

Technical Deep Dive

▶ Watch: Detailed explanation of the integer overflow vulnerability (6:20)

The exploit chain commences with a zero-click remote code execution in the media_codec process, which then escalates privileges to root through a kernel vulnerability. The initial entry point was a bug in the Dolby Unified Decoder (UDC), a proprietary binary blob responsible for decoding Dolby Digital (AC3) and Dolby Digital Plus (EAC3) audio formats.

The core vulnerability in the Dolby UDC resided in its handling of the Extensible Metadata Delivery Format (EMDF), a "format within a format" akin to JavaScript or images within a PDF. The critical sequence involved the read_variable_bits function, which reads a size_t value directly from the EMDF bitstream (attacker-controlled). This size was then used by an internal evil_malloc function to allocate memory. The evil_malloc performs an addition for padding: total_size + padding. If the total_size (from the attacker) is sufficiently large (e.g., 0xFFFFFF9), this addition results in an integer overflow, causing the allocated size to become zero.

Crucially, after malloc(0) returns a valid, zero-sized buffer, the code proceeds to write data into this buffer based on the original, large attacker-controlled length from the bitstream. This results in a highly controlled out-of-bounds write where the attacker dictates both the length and contents of the write. Furthermore, the process of copying the EMDF data into an internal skip_buffer before parsing uses different size values for allocation and copying, creating an out-of-bounds read primitive as well. This "super good bug" allowed for arbitrary data read and write.

Exploiting this bug required understanding the UDC's memory management. The decoder uses a simple slab allocator (dubbed the "Evo heap") which operates on a large chunk of memory and does not support freeing individual allocations; instead, the entire heap is reset after each sync frame (independently decodable audio chunks). The key to exploitation was that the skip_buffer pointer, which the attacker could overflow, was located directly before the heap_length and payload_extra variables in memory. By overflowing the skip_buffer with a controlled value, the attacker could partially or fully overwrite these adjacent variables.

Initially, targeting faraway function pointers (161KB away) was impractical due to the limited overflow size and potential crashes. The breakthrough came from manipulating heap_length and payload_extra. Overwriting heap_length allowed for allocations outside the intended heap boundaries. Overwriting payload_extra (a value added to allocation sizes) with a large number allowed for a subsequent allocation to target a specific, distant memory region (e.g., where function pointers were located) without corrupting the intermediate memory.

The challenge remained in providing a valid pointer to overwrite the skip_pointer in the presence of ASLR. The solution involved leveraging the properties of the Scudo secondary heap, used for large allocations. Scudo secondary chunks have a prev_chunk pointer that, in the absence of churn, points back to the chunk itself. By overflowing the next_pointer in a Scudo header, the attacker could cause the next allocation to be at a slightly higher address (e.g., 0x100 bytes higher), while the original chunk remained inactive. Repeating this three times created a scenario where a known, valid pointer (the inactive chunk's address) could be used to overwrite the skip_pointer, providing a reliable base for subsequent heap manipulations. This introduced a 1 in 16 reliability factor due to guessing a byte of the page size.

With arbitrary function pointer control, the next hurdle was SELinux. Direct dlopen or creating executable pages were blocked. The strategy pivoted to using fopen("/proc/self/mem") to obtain a file descriptor, then pwrite into a rarely called function (e.g., the decoder's init function) to inject shellcode. As pwrite wasn't directly imported by the decoder, a complex ROP chain was devised. This involved using a "worst gadget ever" (an instruction that adds a constant 0x157 to a register) multiple times to increment a memcpy pointer until it pointed to pwrite in libc, followed by a partial overwrite to precisely target pwrite. This allowed the attacker to execute arbitrary shellcode within the media_codec process, albeit with a 32KB size limit.

Privilege Escalation (Pixel 9: /dev/bigwave)

With code execution in media_codec, the next step was privilege escalation to root. Seth Jenkins focused on less-audited SELinux contexts, specifically media_codec, which could access kernel drivers like /dev/bigwave – a custom Google driver for AV1 video acceleration.

The bigwave driver contained a use-after-free (UAF) vulnerability arising from a race condition. The big_o_ioctl_unlocked function queues an inst object (the main object tied to the struct file) onto a priority queue for processing by big_o_worker_thread. The ioctl function waits up to 16 seconds for job completion, but the worker_thread's internal wait_for_completion_timeout only lasts 1 second. By submitting 15 dummy jobs, followed by the target job, the attacker could ensure the target job was in active processing by the worker_thread precisely when the ioctl returned. Upon ioctl exit, the struct file's reference count drops, and an attacker-controlled close() call frees the inst object while the worker_thread is still using it, leading to UAF.

This UAF was exploited by heap spraying with Unix domain sockets to reallocate the freed inst object. This allowed the attacker to control the regs_pointer within the reallocated inst. Subsequently, the big_o_poll_regs function (called by the worker_thread) would write hardware registers (controlled by the attacker from userland via big_o_push_regs) to the attacker-controlled regs_pointer. This yielded a powerful arbitrary write primitive of 2144 bytes, without needing to leak KASLR (Kernel ASLR).

However, to turn this into a general arbitrary read/write, KASLR still needed to be defeated. The Pixel's fixed physical kernel address and the ARM64 Linux kernel's linear map (a 1:1 physical-to-virtual mapping that is not randomized on ARM64) meant that kernel .data and .code were at predictable virtual addresses. While these linear map aliases were read/write but not executable, they provided a way to access kernel data.

To achieve a full arbitrary read/write, the team re-implemented a known technique: hijacking the ashmem_fops table. This involved forging a fops (file operations) table that mixed ashmem and configfs handlers, creating a type confusion on the private_data member of a struct file. By setting the name of an ashmem file descriptor (via ashmem_ioctl_set_name) to a target kernel address, the private_data would be interpreted as a pointer to that address by configfs read/write operations. Subsequent read() and write() syscalls on that ashmem FD would then operate directly on the target kernel memory.

To get the KASLR slide for the ashmem_fops table, a minor leak was needed. The SELinux_type struct in kernel .data has a .name pointer whose contents are exposed when reading /proc/self/mounts. By using the arbitrary write to overwrite this .name pointer with the linear map alias of the ashmem_fops table, reading /proc/self/mounts would leak the address of ashmem_read_it, thereby revealing the KASLR slide.

Privilege Escalation (Pixel 10: /dev/vpu)

For the Pixel 10, the bigwave driver was removed. A new driver, /dev/vpu, was identified as a target. Within minutes, a critical vulnerability was found: a lack of bounds checking in the mmap handler. The remap_pfn_range function, used to map physical pages into userland, was called with vma->vm_end - vma->vm_start as the length. This length is directly controlled by userland through the mmap syscall. Combined with the Pixel's consistent core_PA_address (base physical address) for the kernel, this meant an attacker could map the entire kernel memory (including .code and .data sections) into their process as read/write. This provided an immediate and trivial arbitrary kernel read/write primitive, rendering the complex KASLR bypass and ashmem_fops hijacking unnecessary. The POC for this bug took only two minutes to write.

Final Shellcode and Root

With an arbitrary kernel read/write primitive (either via ashmem_fops hijacking on Pixel 9 or direct mmap on Pixel 10), the final steps to root were straightforward. The shellcode, limited to 32KB from the media_codec stage, was carefully crafted: libc dependencies were removed, syscalls were implemented manually (with LLM assistance), and compilation flags (-mcmodel=tiny) and objcopy were used to reduce its size to 8KB.

Root privilege was achieved by:

1. Disabling SELinux: The SELinux_enforcing flag within the SELinux_state struct (located in kernel .data at a predictable linear map address) was flipped from 1 to 0.
2. Changing Credentials: The process's cred pointer was located by walking the task list and then overwritten to point to init_cred, Google's pre-existing root credential structure, avoiding the need to craft a new one.

This full chain allowed the researchers to execute arbitrary code with root privileges, demonstrating a complete compromise of the Pixel devices.

Demo / Proof of Concept

▶ Watch: Revealing an even better bug: an information leak (7:45)

The talk culminated in a video demonstration of the entire zero-click exploit chain working on a Google Pixel device. The demo showcased the attack starting from the receipt of an audio message. On screen, a timer was displayed, indicating the real-world duration of the exploit, which took approximately 10 minutes to complete in the simulated environment (sped up for the presentation).

The target phone, presumably idle and not actively being used, received the specially crafted audio message. As the Android system automatically processed and attempted to transcribe the audio, the exploit chain was triggered. The visual cue of success was the device's camera activating to take a picture, which was then immediately exfiltrated to a pre-configured IP address controlled by the attackers. The picture showed the two researchers (Natalie and Seth) looking at their monitors, initially perplexed why the exploit seemed to be failing, before realizing it had already worked. This tangible outcome dramatically illustrated the severity and effectiveness of a zero-click, full-chain compromise.

Defensive Implications

▶ Watch: Exploitation strategy: simple slab allocator, no free (9:10)

The detailed analysis of this exploit chain provides crucial insights for improving the security posture of Android and other mobile platforms. The speakers highlighted both successful mitigations and critical areas for improvement:

1. Zero-Click Attack Surface Reduction: The primary takeaway is the urgent need to re-evaluate and reduce the zero-click attack surface. The Dolby UDC, designed for streaming services like Netflix and YouTube, has no legitimate reason to be automatically transcribed from untrusted messages. Removing such codecs from the zero-click processing pipeline would have entirely prevented the initial RCE. This applies to other audio and media codecs not intended for message-based transcription.

1. Strengthen seccomp for media_codec: The media_codec process, despite being sandboxed by SELinux, was found to have an incomplete seccomp policy, notably lacking restrictions on syscalls like pwrite. Had pwrite been blocked, the ROP chain required for initial shellcode execution would have been significantly more complex, potentially taking weeks longer to develop. Ensuring robust seccomp policies for all untrusted contexts is critical.

1. Improved Bug Prioritization and Patching: Initially, the Dolby UDC and Big Wave driver bugs were not treated as high-impact issues individually, leading to prolonged patching times (193 and 199 days, respectively, with 84 and 114 days public before fix). This highlighted a flaw in bug prioritization that failed to account for the cumulative impact of chained vulnerabilities. Google has since improved this, as evidenced by the VPU bug being fixed within 71 days (and within Project Zero's 90-day disclosure deadline), marking a significant improvement for Android driver patching.

1. Adopt Memory-Safe Languages: The speakers emphasized that using managed code or memory-safe languages like Rust for critical components, especially codecs and kernel drivers, could prevent entire classes of memory safety bugs (e.g., integer overflows, use-after-frees, out-of-bounds accesses). While the specific Dolby bug might have been complex to prevent with Rust due to its nature, many audio and driver bugs would be mitigated. Seth noted that the Pixel 9's Big Wave UAF would have been prevented by MTE (Memory Tagging Extension), though the Pixel 10's VPU bug would not.

1. Enhanced Memory Mitigations (MTE/MIE): While ASLR and SELinux proved challenging but ultimately bypassable, memory mitigations like MTE or MIE (Memory Isolation Extension) offer a stronger defense. The Dolby bug's exploit path within a single struct was intricate, but MTE would significantly raise the bar for many other memory corruption vulnerabilities.

1. Leverage Compiler-Level Protections (e.g., Fbound Safety): A notable finding was that the same Dolby UDC bug did not affect iPhones or macOS. This was attributed to Apple compiling the library with the Fbound_safety flag, which injects runtime instructions to check for out-of-bounds accesses. This demonstrates that compiler-level instrumentation can be a highly effective, proactive defense against memory safety issues, even in complex, proprietary binary blobs.

1. Rethink Kernel ASLR: The reliance on the Linux kernel linear map and the Pixel's fixed physical kernel address to bypass KASLR highlights a potential weakness. While the Linux kernel community may consider KASLR less critical post-Spectre/Meltdown, its erosion on specific platforms can simplify kernel exploitation significantly.

In summary, a multi-layered defense strategy is essential: aggressively reducing the attack surface, implementing comprehensive seccomp policies, prioritizing chained vulnerability impacts, embracing memory-safe languages, adopting advanced hardware memory mitigations, and leveraging compiler-level safety features.

Key Takeaways

• Audio Codecs are Critical Zero-Click Attack Surfaces: Android's automatic audio message transcription feature turns all audio codecs into potential zero-click attack vectors, drastically expanding the remote attack surface.
• Don't Ignore "Constrained" SELinux Contexts: Security research should extend beyond the untrusted_app context to other sandboxed environments like media_codec, media_extractor, and platform_app, as they are often less audited but can still provide paths to root.
• Kernel ASLR is Not a Panacea on All Platforms: On Pixel devices, specific properties like a fixed physical kernel address and the ARM64 Linux kernel linear map can significantly weaken KASLR, simplifying kernel exploitation.
• Chained Vulnerabilities Elevate Impact: Individual "low impact" bugs, such as an integer overflow in a media codec or a UAF in a driver, become critical when chained together to form a full system compromise. Patching prioritization should reflect this reality.
• Proactive Mitigations are Essential: Compiler flags like Fbound_safety (as seen on iOS/macOS preventing the Dolby bug) and robust seccomp policies can prevent entire classes of vulnerabilities or significantly increase exploit complexity.
• Memory-Safe Languages are the Future of Security: Moving critical components like media codecs and kernel drivers to memory-safe languages such as Rust would eliminate many common memory corruption vulnerabilities that form the basis of these exploit chains.

About the Speaker(s)

Natalie Silvanovich is a Security Researcher and Manager at Google Project Zero. Her work focuses on discovering and mitigating high-impact vulnerabilities in widely used software and hardware. In this research, she led the discovery and exploitation of the initial zero-click vulnerability in the Dolby Unified Decoder, navigating complex heap manipulations and SELinux bypasses to achieve code execution in the media_codec process.

Seth Jenkins is a Security Researcher at Google Project Zero. He is known for his expertise in "hacking Android drivers and getting root without a password," a skill vividly demonstrated in this talk. Seth was responsible for developing the privilege escalation exploits for both the Pixel 9 (/dev/bigwave UAF) and Pixel 10 (/dev/vpu mmap bug), including novel KASLR bypass techniques and the final steps to achieve root privileges.

Ivan Fratric, also a Security Researcher at Google Project Zero, contributed to the initial discovery of the Dolby UDC vulnerability, finding the critical integer overflow within an hour during a team hackathon. He also presented earlier at OffensiveCon, underscoring his expertise in vulnerability research.