Exploiting QSEE Vulnerabilities In Google's Wifi Pro

Exploiting QSEE Vulnerabilities In Google's Wifi Pro

Speakers: Cristofaro Mune (Security Researcher / Founder, Raelize)

Conference: OffensiveCon

YouTube: https://www.youtube.com/watch?v=I1-D_sck2to

Overview

This talk, "Exploiting QSEE Vulnerabilities In Google's Wifi Pro," delivered by Cristofaro Mune of Raelize, delves into critical security vulnerabilities discovered within the Qualcomm QSEE (Qualcomm Secure Execution Environment) implementation on the Google Nest Wi-Fi Pro router. Mune, presenting research conducted in collaboration with Nick Teemus, details a comprehensive methodology for achieving EL3 (Exception Level 3) code execution – the highest privilege level on an ARM-based System-on-Chip (SoC) – on a widely deployed consumer device.

The significance of this research lies not only in compromising a modern, secure-boot-enabled device but also in demonstrating a novel, hardware-centric exploitation technique. Beyond traditional software vulnerabilities and MMU (Memory Management Unit) table manipulation, the speakers illustrate how understanding and directly manipulating TrustZone Address Space Controllers (XPUs) can provide more powerful and persistent exploitation primitives. This approach challenges conventional wisdom in TEE exploitation, emphasizing the lasting value of deep hardware knowledge in an ever-evolving threat landscape.

Background

▶ Watch: Introduction and talk goals (0:00)

The research presented builds upon previous work by Mune and Teemus, who began investigating Qualcomm devices, specifically the IPQ 4018, in 2021. This initial exploration uncovered several vulnerabilities affecting multiple products and was later extended to include fault injection techniques. The current target is the Google Nest Wi-Fi Pro, identified by the product code Wi-Fi Pro. This device is a 6E router featuring a 64-bit ARM CPU, 1 gigabyte of RAM, and 4 gigabytes of flash storage. Its SoC, the IPQ 518, is a successor to their previous target and comes equipped with Secure Boot and an ARM TrustZone-based Trusted Execution Environment (TEE), specifically the Qualcomm QSEE. The team analyzed firmware version 3.73, with 3.78 being the latest available at the time, and a QSEE version identified as 00024.

Initial access to the device presented several challenges. The Google Nest Wi-Fi Pro does not natively expose a serial port, and even after identifying the serial pins on the PCB, the kernel was configured not to print any output, and no user shell was available. To overcome this, the researchers performed an in-situ eMMC (embedded MultiMediaCard) dump by disconnecting the clock signal, allowing them to extract all partitions without physically removing the chip. Key partitions for their research included the PBL (Primary Boot Loader), SBL (Secondary Boot Loader), QSEE A and B, and U-Boot A and B.

The first major hurdle was bypassing Secure Boot. The device's boot process flows from the Qualcomm SoC's PBL to the SBL, then U-Boot, and finally loads the kernel. Mune and Sergey, working independently, discovered a vulnerability related to U-Boot's environment partitions. U-Boot searches for environment partitions named SBL env or U-Boot env. By resizing an existing partition and creating a U-Boot env partition, the researchers could supply their own custom U-Boot environment. Within this custom environment, they discovered that setting the environment variable ATF to any value would bypass the U-Boot signature verification (specifically, a check on line 1151 of the U-Boot source). This allowed them to boot an unsigned kernel.

With an unsigned kernel booting, they re-enabled kernel printing by modifying the console variable, which was initially blank. Root access was then achieved by modifying init.rc within the ramdisk, part of the boot image. A crucial step for their subsequent research was enabling the loading of LKMs (Loadable Kernel Modules). They found that init.rc would write 1 to a specific file, disabling LKM loading. By preventing this write operation, they could load their own LKMs. This sequence of steps provided them with a root shell in NS EL0 (Non-Secure Exception Level 0), the user space of the Rich Execution Environment (RE).

To interact with the TEE, they needed to reach its attack surface, typically exposed through the NS-SMC (Non-Secure Secure Monitor Call) interface. While dev/mem on the Wi-Fi Pro provides access to the physical address space, it's limited to non-secure memory. To send SMC (Secure Monitor Call) instructions, which require privileged access, they developed an LKM to proxy requests from user space to the kernel, enabling the kernel to issue SMCs. They then extracted the TEE OS (QSEE) and Secure Monitor binaries from the dumped partitions. The Secure Monitor operates at EL3, the highest privilege level, while the TEE OS runs at Secure EL1. Their initial analysis involved reverse engineering the SMC handlers to enumerate the available attack surface. SMC arguments are passed via registers and, importantly, must be physical addresses, as the TEE has no visibility into the RE's MMU tables. Most SMCs sent to EL3 are ultimately dispatched to the EL1 TEE OS for handling.

A fundamental challenge for all TrustZone-based TEEs is distinguishing between pointers to secure and non-secure memory, as physical addresses can point anywhere. The TEE cannot query the hardware memory controller directly for this information, nor can it trust the RE's MMU view. The common solution is for the TEE to maintain a Secure Range Table, which is a software representation of the hardware controller's configuration of secure memory. These tables define continuous ranges of memory considered secure. In the case of QSEE, two such ranges were identified, with each entry containing an ID, flags, start address, and end address. Critically, a specific bit (bit 1) in the flags determined if an entry was active; if zero, the entry was skipped. This understanding laid the groundwork for their exploitation strategy.

Key Findings

▶ Watch: Dumping firmware from eMMC without chip-off (3:20)

The research yielded a significant number of vulnerabilities, with 12 CVEs identified as either high or critical severity, demonstrating substantial weaknesses in the Qualcomm QSEE implementation on the Google Nest Wi-Fi Pro. The central contribution is the achievement of EL3 code execution through two distinct methods, showcasing both traditional and novel exploitation techniques.

The initial phase of the exploit chain involved uncovering an arbitrary TEE read primitive. This was achieved by manipulating an SMC handler that utilized a memcpy operation. While the destination of this memcpy was securely checked, the source could be controlled via the OCIMM (On-Chip Internal Memory), which was unexpectedly writable from the RE and not protected by the memory controller. This allowed the attackers to read any memory accessible by the TEE, including sensitive secure memory and ROM.

Building on the read primitive, they discovered an arbitrary null-byte write primitive. This vulnerability stemmed from an out-of-bounds array access in another SMC handler. By providing a sufficiently large index, they could cause a pointer to reference RE memory, which was then used in a memset operation to write null bytes to an arbitrary TE memory location.

These primitives were then leveraged in a "generic exploitation methodology" focused on targeting the Secure Range Tables. By writing null bytes to specific flag bits within these tables, they could effectively disable the TEE's secure memory checks. This transformed their limited read/write primitives into a full arbitrary read/write capability across all physical memory, including the entire TEE memory space.

With arbitrary read/write, EL3 code execution was achieved first through a conventional approach: patching an EL3 SMC handler directly. Surprisingly, they discovered that the TE code section was already writable, obviating the need for complex MMU table manipulation.

However, the most significant finding was the development of a more powerful and "better way" to achieve EL3 code execution, which targeted the underlying hardware memory protection mechanisms: Qualcomm XPUs (TrustZone Address Space Controllers). By analyzing XPU access violation logs and reverse engineering XPU register layouts (with insights from Coreboot research), they identified specific hardware registers that define the secure memory ranges. They demonstrated that by modifying these XPU registers directly from the RE (using their arbitrary write primitive), they could shrink the protected secure memory region, effectively exposing a portion of the secure monitor to non-secure access. This allowed them to directly patch EL3 code from user space in the RE, bypassing TEE MMU rules entirely and achieving persistent EL3 code execution until the next reboot.

Finally, the researchers demonstrated the practical impact of their EL3 access by extracting the data partition encryption key. They explained that the encryption relies on a key derived from a Storage Hardware Key (SHK). By patching a specific TA (Trusted Application) responsible for key derivation, they forced it to return the derived key to the RE, which could then be printed, revealing the encryption key. This highlights the severe consequences of compromising the TEE, especially in devices lacking robust user-input-based key protection.

Technical Deep Dive

▶ Watch: Bypassing secure boot with U-Boot environment (4:30)

The journey to EL3 code execution began with gaining control over the Rich Execution Environment (RE). The initial Secure Boot bypass exploited U-Boot's behavior. By identifying that U-Boot attempts to load environment variables from partitions named SBL env or U-Boot env, the researchers created their own U-Boot env partition. Within this custom environment, they set the ATF variable, which, as discovered in the U-Boot source code (line 1151), caused the verification of the kernel image to be skipped. This allowed them to boot an unsigned kernel. Once an unsigned kernel was running, they re-enabled console output by modifying the console variable and gained root privileges by altering init.rc in the ramdisk. Crucially, they also modified init.rc to prevent a specific write operation that would disable LKM (Loadable Kernel Module) loading, ensuring they could load their own kernel modules later.

With a root shell in NS EL0, the next step was to interact with the Trusted Execution Environment (TEE). The device exposes /dev/mem, which allows reading and writing to non-secure physical memory. To communicate with the TEE, SMC (Secure Monitor Call) instructions are required, which can only be issued from a privileged context (like the kernel). The researchers developed an LKM to act as a proxy, allowing their user-space tools to trigger SMCs. They extracted the Secure Monitor (running at EL3) and TEE OS (running at Secure EL1) binaries from the device's partitions and began reverse engineering their SMC handlers. This process involved identifying SMC IDs (passed in register X0 or R0) and their corresponding handler functions, which are typically stored in arrays of structs. A key point is that SMC arguments must be physical addresses, as the TEE's MMU operates independently and cannot translate virtual addresses from the RE.

A critical challenge for TEEs is distinguishing between secure and non-secure physical memory pointers passed via SMCs. The solution employed by Qualcomm QSEE, like many TrustZone-based TEEs, involves Secure Range Tables. These tables contain entries defining contiguous secure memory regions (e.g., QSC has two ranges). An entry includes an ID, flags, start address, and end address. Specifically, bit 1 of the flags determines if an entry is active; if zero, it's skipped.

The first major vulnerability discovered was an arbitrary TEE read primitive. This involved SMC 02000607, named get_advisory_diagnostic_info. This handler contained a memcpy function. While the memcpy destination and size parameters were subject to a secure_range_check (ensuring they only pointed to non-overlapping RE memory), the source and source size parameters were taken from OCIMM (On-Chip Internal Memory). Crucially, OCIMM was found to be entirely writable from the RE and not protected by the memory controller. By writing a desired physical address (e.g., a TE memory address or ROM address) into OCIMM, the attackers could then call SMC 02000607, causing the TEE to memcpy data from that arbitrary physical address into a user-controlled buffer in RE, thus achieving an arbitrary TEE read.

Following this, an arbitrary null-byte write primitive was found in another SMC handler. This handler took a parameter A1 (an index) that was checked to be below 13 and for specific bits not being set, but critically lacked an upper boundary check. This A1 was used as an index into a struct array. By providing a sufficiently large A1 value, the resulting pointer (base) could be made to point into RE memory. This base pointer was then used in a function that performed a memset operation: memset(STR, 0, size). Since STR was derived from the RE-controlled base pointer and size was also RE-controlled, this allowed the researchers to write null bytes to any arbitrary physical memory address, including secure TEE memory.

These primitives were then used to disable the Secure Range Tables. By using the arbitrary null-byte write to set bit 1 of the flags in all secure range table entries to 0, all secure memory checks were effectively bypassed. This meant that any subsequent SMC call with a physical pointer, even one pointing to TEE memory, would be accepted as valid. This transformed the limited read/write primitives into a full arbitrary read/write primitive across the entire physical address space, including TEE memory. For example, the memcpy in SMC 02000607 could now be directed to write to arbitrary TEE memory addresses.

With arbitrary read/write access to TEE memory, EL3 code execution could be achieved in a "usual way." This involved finding the EL3 MMU tables, modifying them to make the code section writable, and then patching an EL3 SMC handler (e.g., SMC 109) with shellcode. When that SMC was called, the shellcode would execute at EL3. Surprisingly, during their research, they discovered that the TE code section was already writable, eliminating the need for MMU table manipulation. They used their arbitrary write primitive (now able to write any byte, not just nulls, thanks to the disabled secure ranges) to patch an SMC handler with shellcode that dumped the SCR_EL3 register, specifically checking the NS bit (Non-Secure bit). An NS bit of 0 confirmed EL3 code execution.

However, the talk introduced a "better way" of achieving EL3 code execution by targeting Qualcomm XPUs (TrustZone Address Space Controllers). These are hardware entities on the bus responsible for defining and protecting secure memory regions. Secure memory is not intrinsically special; it's created by configuring these XPUs. The researchers observed that attempts to access secure memory from the RE resulted in XPU-generated access violation logs, revealing details like the non-secure request, the address accessed, and the matching XPU configuration entry (e.g., entry number 1).

Leveraging public research from Coreboot on XPU layouts, they understood that XPU configurations are stored in hardware registers. They identified the base address of the XPU control register set (0x200 bytes) and the structure of each protection entry (0x80 bytes per entry, with start and end addresses at offsets 0x40 and 0x48 respectively). By correlating the access violation logs (which indicated entry number 1 was protecting the secure monitor) with the XPU register layout, they calculated the exact hardware register address controlling the secure monitor's start address.

Using their arbitrary write primitive, they directly modified this XPU register. For example, they changed the start address from 0x4AC00 to 0x4AC0900. This effectively shrank the protected secure memory region, exposing the lower portion of the secure monitor's memory to non-secure access. With this hardware-level bypass, the RE (specifically, dev/mem from user space) could now directly read and write into the unprotected part of EL3 memory. They then patched an EL3 SMC handler directly from RE user space, again with shellcode to dump the SCR_EL3 register and verify the NS bit. This method offers significant advantages: it doesn't require patching MMU tables, it's performed directly from RE after the controller bypass, and the protection remains disabled until the next reboot, making it a persistent and powerful primitive. A specific CVE was reported because the XPU entry was not locked, allowing it to be changed.

Finally, as a practical demonstration of their EL3 control, they detailed how they could extract the data partition encryption key. The device's data partition is encrypted at rest using a key derived from a Storage Hardware Key (SHK). While the SHK itself is likely hardware-bound and inaccessible, the derived key is generated by a Trusted Application (TA) using a KDF (Key Derivation Function) in software. With arbitrary read/write access to TEE memory, they could patch this specific TA directly to force it to return the derived key to the RE, which could then be printed. This highlighted the ability to subvert even fundamental security features once the TEE is compromised at EL3.

Demo / Proof of Concept

▶ Watch: Re-enabling kernel output and gaining root shell (6:30)

Throughout the presentation, Cristofaro Mune provided live demonstrations to substantiate the technical claims, showcasing key steps in their exploitation chain:

1. OCIMM Read/Write: He first demonstrated the ability to read and write to the OCIMM (On-Chip Internal Memory) from the RE (Rich Execution Environment). This live demo involved reading a value, writing zeros to it, reading back to confirm the zeros, and then restoring the original value. This proved the critical vulnerability that allowed an arbitrary TEE read primitive.
2. Disabling Secure Ranges: Mune showed how the Secure Range Table flags were initially set to 02. Using their arbitrary null-byte write primitive, he demonstrated modifying these flags to 00, effectively disabling the secure range checks. This critical step enabled full arbitrary read/write access to all physical memory, including the TEE.
3. XPU Register Manipulation: The most compelling demonstration involved directly manipulating the Qualcomm XPU (TrustZone Address Space Controller) registers. He first showed the initial value of the XPU register protecting the secure monitor's memory range (e.g., 4AC00). Then, using their arbitrary write primitive, he changed this register's value (e.g., to 4AC0900). This action effectively "shrank" the protected secure memory region.
4. Reading Secure Monitor from RE: Following the XPU register modification, Mune live-demonstrated reading directly from the secure monitor's memory space using /dev/mem from the RE user space. This visually confirmed that a portion of the EL3 memory was now exposed and accessible to the non-secure world, validating the XPU bypass.
5. EL3 Code Execution Proof: The final live demo showcased EL3 code execution. After the XPU registers were altered, he demonstrated patching an EL3 SMC handler directly from RE user space. The shellcode injected into EL3 would dump the SCR_EL3 register. The live output clearly showed the NS bit (bit 0) of the SCR_EL3 register set to 0, definitively proving that their code was executing in the secure EL3 context.

While the demonstration of extracting the data partition encryption key via patching a TA (Trusted Application) was not shown live due to time constraints, Mune verbally confirmed its feasibility and explained the methodology. Screenshots were also provided in the slides to ensure the integrity of the demonstrations in case of "demo gods" not favoring them.

Defensive Implications

▶ Watch: Transitioning from root shell to TEE attack surface (7:50)

The findings presented in this talk have profound implications for the design and security of Trusted Execution Environments (TEEs) and secure devices in general. Defenders should consider the following measures:

1. Robust Secure Boot Implementation: The U-Boot environment variable bypass highlights the need for rigorous validation of all boot-time configurations. Environment partitions should be cryptographically signed, and any mechanism to skip signature verification (like the ATF variable) must be removed or strongly protected. Access to init.rc and other boot-critical configuration files must be restricted and integrity-checked.
2. Strict SMC Input Validation: All SMC (Secure Monitor Call) handlers must implement comprehensive validation for all input parameters, especially pointers and sizes. This includes thorough bounds checking for array indices (to prevent issues like the arbitrary null-byte write) and strict enforcement of Secure Range Table checks for memory access.
3. Protection of Internal Memory: OCIMM (On-Chip Internal Memory) or similar internal memory regions that can influence TEE operations (e.g., by providing memcpy sources) must be adequately protected from non-secure read/write access. If they must be accessible, their contents should be treated with extreme caution and validated by the TEE.
4. Immutable Secure Range Tables: The Secure Range Tables themselves should be stored in highly protected, read-only memory after initialization. The flags that determine an entry's validity should be immutable or require strong authentication for modification. Any attempts to alter these tables from the RE should trigger immediate security alerts or device resets.
5. Secure XPU/Hardware Controller Configuration:

• Qualcomm XPU (TrustZone Address Space Controller) configuration registers must be write-protected and locked after initial setup. The reported CVE where an XPU entry was not locked highlights a critical oversight.
• The TEE's initialization process should thoroughly validate XPU configurations (e.g., ensuring start addresses are less than end addresses) to prevent "default open" states.
• XPU access violation logs should be secured and not trivially exposed to the RE, as they provide valuable information for attackers to reverse engineer hardware protection mechanisms.

1. Enforce W^X (Write XOR Execute) for TEE Code: The discovery that the TE code section was surprisingly writable is a fundamental security flaw. TEE code memory should always be marked as execute-only or read-execute, never writable, to prevent code injection and patching. MMU/MPU configurations for the TEE itself must be correctly applied and enforced.
2. Strong Key Derivation and Protection: For devices without user input (like routers), relying on keys derived from a Storage Hardware Key (SHK) requires robust protection of the key derivation process. The TA (Trusted Application) responsible for key derivation should be exceptionally hardened against compromise. Ideally, keys should be ephemeral or bound to cryptographic hardware operations that cannot be easily subverted even with EL3 access.
3. Hardware-Aware Security Audits: The success of the XPU-based exploitation underscores the necessity of security audits that extend beyond software to deeply analyze hardware memory controllers and their configurations. Understanding the hardware architecture and its security features is crucial for identifying subtle vulnerabilities that software-only analysis might miss.

Key Takeaways

• Persistent TEE Vulnerabilities: Despite advancements in device security, Trusted Execution Environments (TEEs) from major manufacturers like Qualcomm still exhibit significant code integrity and configuration vulnerabilities, as evidenced by the 12 high/critical CVEs found.
• Multi-Stage Exploitation: Achieving EL3 (Exception Level 3) code execution on modern devices often requires a complex, multi-stage exploit chain, starting from Secure Boot bypass to gain kernel-level control, then leveraging SMC (Secure Monitor Call) vulnerabilities to gain arbitrary read/write within the TEE.
• Targeting Fundamental Mechanisms: Effective TEE exploitation can target fundamental TrustZone mechanisms like Secure Range Tables and TrustZone Address Space Controllers (XPUs), which are critical for defining and protecting secure memory.
• Hardware-Centric Exploitation Advantages: Exploiting hardware memory controllers (XPUs) offers powerful and persistent primitives, often bypassing the need to manipulate MMU (Memory Management Unit) tables and ignoring TEE-side memory protection rules, as the control is exerted at a lower, more fundamental hardware level.
• Value of Hardware Knowledge: Deep understanding of the underlying hardware architecture and its controllers provides more resilient and long-lasting exploitation techniques compared to software-specific vulnerabilities, as hardware designs evolve more slowly.
• Surprising Overlooks: Even recent devices from major vendors can contain surprising oversights, such as writable TEE code sections, which simplify the path to code execution once TEE memory is accessible.

About the Speaker(s)

Cristofaro Mune is a Security Researcher and the Founder of Raelize. With over 20 years of experience in the field, Mune has dedicated a significant portion of his career to investigating the security of devices. He presented this research, which was a collaborative effort with his business partner and fellow researcher, Nick Teemus. Teemus was recognized by Mune as a "great researcher" who contributed significantly to the findings, though he was not present to deliver the talk. More information about their research can be found on the Raelize blog. Their work demonstrates a deep expertise in reverse engineering and exploitation of complex embedded systems, particularly those utilizing Qualcomm SoCs and TrustZone technology.