Bypassing Hardware Security: How Cross-Core Attacks Compromise Mobile TEEs

TLDR: This research demonstrates how to achieve arbitrary code execution in the ARM TrustZone Secure Monitor (EL3) by chaining vulnerabilities across heterogeneous SoC cores. By exploiting flaws in inter-core communication interfaces like ION memory management and mailbox handlers, an attacker can escalate from a non-secure Android application to full control of the secure world. This technique effectively bypasses hardware-backed security boundaries, including screen password verification, on modern mobile devices.

Mobile security research often hits a wall at the hardware boundary. We spend our time hunting for kernel exploits or user-space sandbox escapes, but the Trusted Execution Environment (TEE) usually remains a black box. The assumption that the secure world is isolated from the "normal" world is a dangerous oversimplification. When you have a heterogeneous system with multiple cores—each with different privilege levels and memory access rights—the communication channels between them become the most critical attack surface.

The Anatomy of a Cross-Core Escalation

The core of this research lies in the realization that the hardware-based security mechanisms, such as ARM TrustZone, are only as strong as the interfaces that bridge the secure and non-secure worlds. If an attacker can manipulate the communication between the Application Processor (ACPU) and secondary cores like the Image Signal Processor (ISP) or the Low-Power MCU (LPMCU), they can trick the secure world into executing malicious code.

The attack chain begins by identifying vulnerabilities in the inter-core communication protocols. Specifically, the researcher targeted the ION memory management system and mailbox handlers. By finding an integer overflow in the mailbox handler, an attacker can manipulate memory pointers that the secure world trusts implicitly.

Consider the vulnerability identified in CVE-2020-36600. The mailbox handler fails to properly validate the input parameters passed from the non-secure world. By crafting a specific command, an attacker can force the secure world to perform a memory copy operation to an arbitrary destination. This is not just a memory corruption bug; it is a primitive that allows for the overwriting of critical secure-world structures.

Chaining Primitives for EL3 Access

Once you have the ability to write to arbitrary memory, the goal is to reach the Secure Monitor (EL3). The researcher achieved this by targeting the firmware loading process. By exploiting CVE-2022-46762, which involves improper input validation in the ION memory management, the attacker can map physical memory pages that should be inaccessible.

The exploit flow is elegant in its simplicity:

1. Gain root access on the Android user-space (a prerequisite for interacting with the drivers).
2. Use the ION driver to allocate a buffer and trigger the integer overflow to gain a write-what-where primitive.
3. Overwrite the firmware of a secondary core, such as the IOMCU, which acts as a "secure master."
4. Use the IOMCU to perform a DMA transfer that overwrites the Secure Monitor (BL31) code in memory.

The following command demonstrates how a simple shellcode injection can be used to bind a malicious firmware image to the ISP, effectively hijacking its execution flow:

mount --bind isp_fw_mod.elf /odm/etc/firmware/isp_fw.elf

By replacing the legitimate firmware with a patched version that includes a custom Secure Monitor Call (SMC) handler, the attacker gains the ability to execute code at the highest privilege level on the SoC.

Real-World Impact and Testing

For a pentester, this research changes the threat model for mobile engagements. If you are testing a device that relies on TEE-based features like biometric authentication or secure storage, you cannot assume the TEE is impenetrable. The impact of this escalation is total device compromise. As shown in the live demo, the researcher successfully bypassed the screen password verification on a Huawei device. By patching the weaver trust application, which handles password verification, the device accepted any input as a valid password.

During an engagement, you should look for custom drivers that facilitate communication between the ACPU and secondary processors. Use tools like Ghidra to reverse-engineer the firmware of these secondary cores. Look for functions that handle mailbox messages or DMA transfers. If you find a function that takes a pointer and a length from a user-space buffer without rigorous bounds checking, you have found a potential entry point for a cross-core attack.

Defensive Considerations

Defending against these attacks is notoriously difficult because they exploit the fundamental architecture of the SoC. However, the primary mitigation is to minimize the attack surface of the secure world. Vendors must implement strict input validation for all inter-core communication. Every message passed from the non-secure world to a secure core must be treated as untrusted.

Furthermore, hardware-based firewalls like the CFGBUS should be configured to restrict memory access for secondary cores. If a core does not need access to the entire physical memory range, it should be locked down to only the memory regions required for its specific tasks. The principle of least privilege must be applied not just to software, but to the hardware components themselves.

The complexity of these systems is the enemy of security. Every additional core added to an SoC increases the attack surface exponentially. As researchers, we need to keep pushing on these hardware boundaries. The next time you are looking at a mobile device, don't just look at the Android kernel. Look at what is running underneath it, and ask yourself how those cores are talking to each other. That is where the real vulnerabilities are hiding.