Breaking ARM TrustZone: Exploiting System Bus Faults for Code Execution

TLDR: Researchers have demonstrated a non-invasive fault injection technique targeting the system bus of ARM TrustZone-enabled SoCs, effectively bypassing signature verification. By using electromagnetic fault injection to trigger register sweeping during load operations, an attacker can force a zero-value into a register, tricking the system into accepting unauthorized code. This research, associated with CVE-2022-47549, proves that the security boundary between the Rich Execution Environment and the Trusted Execution Environment is vulnerable to physical manipulation.

Hardware security often relies on the assumption that the physical boundary of a chip is impenetrable. We assume that if we cannot physically depackage a chip or probe its internal traces, the code running inside the Trusted Execution Environment (TEE) is safe from the untrusted world. This research shatters that assumption by targeting the system bus, a component that is often exposed on the PCB of common embedded devices like the Raspberry Pi 3.

The Mechanics of Bus Fault Injection

The core of this attack is not about finding a software vulnerability in the TEE code itself, but about manipulating the data transit between the processor and memory. When the processor executes a load instruction to fetch data from memory, the data travels across the system bus. If an attacker can inject a fault at the exact moment this data is in transit, they can corrupt the value before it reaches the destination register.

The researchers used an electromagnetic fault injection (EMFI) probe to induce these faults. By positioning the probe over the exposed bus traces on the PCB, they could introduce transient electromagnetic pulses that interfere with the signal. The brilliance of this technique lies in its precision. They combined power side-channel analysis with the fault injection to identify the exact clock cycle where the signature verification logic performs its check.

Once the timing is locked, the attacker can induce a fault that forces the loaded data to zero. In the context of signature verification, this is catastrophic. If the verification function expects a non-zero success code but receives a zero due to the fault, the logic flow is altered. As the researchers demonstrated, this effectively bypasses the check, allowing the system to proceed as if the signature were valid.

Register Sweeping and Privilege Escalation

The most significant finding here is the concept of "register sweeping." Previous fault injection research often focused on instruction skipping or bit-flipping, which are notoriously difficult to control. Register sweeping, however, provides a more reliable path to exploitation. By forcing the register to zero, the attacker can reliably manipulate the control flow of the TEE.

Consider the following snippet of assembly logic often found in verification routines:

ldr w0, [sp, #76]  ; Load the result of the signature verification
cmp w0, #0x0       ; Compare the result to zero
b.eq <success>     ; If zero, proceed to success

If an attacker can use an EM probe to force the value in w0 to zero at the moment of the ldr instruction, the cmp operation will always evaluate to true, regardless of the actual signature validity. This is a classic Identification and Authentication Failure at the hardware level. The attacker effectively gains the ability to load their own malicious Trusted Application (TA) into the secure world, achieving privilege escalation from the Rich Execution Environment (REE) to the TEE.

Real-World Applicability for Researchers

For those of us working in penetration testing or hardware security, this technique changes the threat model for embedded devices. If you are assessing a device that uses ARM TrustZone, you can no longer assume that the TEE is a black box. If the system bus is accessible on the board, you have a viable attack vector.

This is not a theoretical exercise. The researchers worked with Linaro to address the vulnerability, resulting in the publication of CVE-2022-47549. The fix involves implementing a "check-result-not-zero" pattern in the TEE kernel, which adds a layer of stateful verification to ensure that the result of sensitive operations hasn't been tampered with.

During an engagement, your focus should be on identifying where the TEE handles sensitive data and whether the system bus is physically accessible. If you can monitor the power consumption of the device, you can use that as a trigger to time your fault injection. The equipment required—an oscilloscope and an EM probe—is standard for any serious hardware security lab.

Defensive Considerations

Defending against physical fault injection is notoriously difficult because it requires hardening the hardware itself. However, software-level mitigations are possible. Developers should avoid simple "if-success" checks and instead use redundant, stateful verification logic that is harder to bypass with a single fault. Furthermore, sensitive operations should be designed to be constant-time and resistant to side-channel analysis, which makes it harder for an attacker to time their fault injection accurately.

The industry needs to move away from the assumption that the OEM is the only entity capable of loading code into the TEE. As we move toward a post-quantum world, the implementation of Post-Quantum Cryptography (PQC) algorithms like Kyber will become standard. If these implementations are not hardened against bus-level fault injection, the entire security foundation of these devices will be at risk. We need to start treating the system bus as an untrusted medium, just as we treat network traffic. If you are building or testing these systems, start looking at the traces on your board as potential entry points.