Bypassing ARM's Memory Tagging Extension with a Side-Channel Attack

Bypassing ARM's Memory Tagging Extension with a Side-Channel Attack

Speakers: Juhee Kim (PhD Student, Seoul National University), Jinbon Park (Samsung Research), Taso Kim (Samsung Research), Byong Young Lee (Seoul National University), Sian Ro (Seoul National University), Jong Chong (Seoul National University), Young Julie (Seoul National University)

Conference: Black Hat USA

YouTube: https://www.youtube.com/watch?v=DoPb4mG-7TY

Overview

ARM's Memory Tagging Extension (MTE) has been hailed as a transformative hardware-based defense against memory corruption attacks, promising to revolutionize software security with its speed and compatibility. Introduced last year and prominently featured in devices like the Google Pixel 8 and 8 Pro, MTE employs a novel "lock and key" mechanism, assigning a unique, random 4-bit tag to both memory objects and the pointers accessing them. This ensures that only a pointer with a matching tag can successfully interact with a memory location, otherwise triggering a tag check fault that crashes the program. The security community, including tech giants like Google and Microsoft, has largely anticipated MTE to be a "game changer."

This talk, presented by Juhee Kim, a PhD student at Seoul National University, alongside collaborators from Samsung Research and Seoul National University, unveils a critical flaw in the current implementation of ARM MTE. Their research demonstrates the discovery of a side-channel attack that can reliably leak the memory tags, effectively bypassing MTE's intended protection. By exploiting common CPU features—specifically, the cache side channel and speculative execution—the researchers have devised a method to infer the correct tag of any memory address without triggering a program crash.

The implications of this research are significant. While MTE remains a powerful mitigation, this work highlights that even cutting-edge hardware defenses can be vulnerable to sophisticated side-channel attacks leveraging microarchitectural behaviors. The ability to reliably leak memory tags undermines MTE's core security premise, allowing attackers to construct precise memory corruption exploits that would otherwise be blocked. The presentation culminates with a demonstration of a real-world MTE bypass against the Google Chrome V8 engine, underscoring the practical threat posed by this vulnerability and emphasizing the need for further hardware and software enhancements to truly secure MTE-enabled systems.

Background

▶ Watch: Introduction to MTE bypass research (0:00)

Memory corruption vulnerabilities have long been the bane of software security, consistently ranking among the most prevalent and severe threats. Historically, exploits like Heartbleed (2014), which leveraged a buffer overflow to compromise millions of servers, or more recent high-profile attacks such as Bad Binder and Blast Pass targeting Android and iOS devices with zero-click capabilities, underscore the devastating impact of these flaws. Attackers have evolved sophisticated techniques, from simple buffer overflows to complex Return-Oriented Programming (ROP) chains, to seize control of vulnerable systems.

In response, the security community has developed a layered defense strategy. Early software-based mitigations included stack canaries to detect stack buffer overflows, Address Space Layout Randomization (ASLR) to randomize memory locations, and Control-Flow Integrity (CFI) to restrict program execution paths. More recently, hardware-based defenses have emerged to offer more robust and performant protection. Examples include Intel's Memory Protection Keys (MPK) and ARM's Pointer Authentication (PAC), which aims to protect against pointer corruption by cryptographically signing pointers.

The latest evolution in this arms race is the ARM Memory Tagging Extension (MTE), introduced last year. MTE represents a significant leap forward by providing hardware-based memory corruption detection that is both fast and compatible, requiring minimal effort for adoption. Its fundamental mechanism is a "lock and key" system:

• Each 16-byte chunk of memory is assigned a random 4-bit memory tag.
• Pointers accessing this memory also carry a 4-bit pointer tag, stored in the unused upper bits of the 64-bit address.
• New MTE instructions allow programs to generate random tags, assign them to memory, and manipulate pointer tags.
• When a program accesses memory through a pointer, the MTE hardware automatically compares the pointer's tag with the memory's tag.
• A tag match results in a valid access.
• A tag mismatch triggers a tag check fault, which immediately crashes the program, preventing memory corruption.

Despite its promise, MTE faces challenges when confronted with a determined attacker. The primary goal for an attacker attempting to exploit a memory corruption vulnerability on an MTE-enabled system is to bypass MTE's tag checks. Two conventional approaches present significant hurdles:

1. Tag Collision: Since tags are only 4 bits, there are 16 possible tag values. If memory objects are randomly tagged, there's a 1-in-16 chance that two distinct objects will coincidentally share the same tag. An attacker could theoretically wait for such a collision to occur and then exploit a memory corruption. However, this method is inherently unreliable and depends on chance.
2. Corrupting the Pointer's Tag: If an attacker can corrupt an entire 64-bit pointer, they could theoretically set its tag to match the target object's memory tag. The critical challenge here is that memory tags are generated randomly at runtime, and the attacker has no prior knowledge of them. Without knowing the target memory's tag, brute-forcing all 16 possible tags would lead to a program crash in 15 out of 16 attempts, resulting in an unacceptably low success rate of approximately 6%. This lack of reliable tag knowledge renders memory corruption attacks against MTE largely impractical.

The core problem, therefore, is the need for a reliable method to leak the memory tag of any arbitrary address. This research directly addresses this challenge by demonstrating how such leakage is possible, undermining MTE's robust protection.

Key Findings

▶ Watch: Challenges in reliably bypassing MTE (4:30)

The central discovery of this research is the identification of a Memory Tagging Extension (MTE) tag leakage side channel present in current ARM MTE implementations, specifically demonstrated on Google Pixel devices. This side channel allows an attacker to reliably determine the 4-bit memory tag associated with any given memory address without causing the program to crash.

The key findings can be summarized as follows:

1. Discovery of a Novel Side Channel: The researchers uncovered a microarchitectural side channel that leaks information about MTE tag check results. Unlike previous attempts (e.g., by Google Project Zero) that failed to find such a channel, this work demonstrates that MTE's tag checks, when performed under specific speculative execution conditions, can leave observable traces in the CPU's cache.
2. Exploitation of Cache Side Channel and Speculative Execution: The attack successfully combines two common CPU features:

• Cache side channel: Used to detect whether a memory access occurred by measuring the time it takes to access a specific memory location (fast for cached, slow for uncached).
• Speculative execution: Leveraged to trigger MTE tag checks in a way that avoids program crashes. This is crucial because a tag mismatch during normal execution would immediately terminate the program. Speculative execution allows an attacker to "test" different tags and observe the side effects without consequence if the speculation is later deemed incorrect.

1. Identification of Two "Tag Leakage Gadgets": The research pinpointed specific memory access patterns, termed tag leakage gadgets, that reliably induce the necessary cache differences to leak MTE tags. These gadgets are microarchitectural sequences that cause the CPU's speculative execution engine to behave differently depending on the MTE tag check outcome.

• Gadget 1 (Multiple Loads): Requires at least two memory loads within a speculatively executed block.
• Gadget 2 (Store-to-Load Forwarding): Involves a store instruction immediately followed by a load instruction from the same address within the speculative block, exploiting the CPU's internal forwarding mechanisms.

1. Reliable Memory Tag Leakage: By repeatedly probing a target memory address with different pointer tags using these gadgets and observing the cache side channel, the attacker can reliably deduce the correct 4-bit memory tag. This elevates the success rate from a mere 6% (brute-force) to near 100%.
2. Real-World MTE Bypass Demonstration: The researchers successfully implemented a practical MTE bypass attack against the Google Chrome V8 JavaScript engine. This demonstration showcased how malicious JavaScript code could construct a tag leakage gadget to extract the MTE tags of the entire renderer process memory, effectively neutralizing MTE's protection in a production environment.

These findings fundamentally challenge the immediate robustness of ARM MTE as a standalone defense against sophisticated memory corruption attacks. While MTE significantly raises the bar for attackers, the existence of these side channels necessitates further scrutiny and mitigation at both hardware and software levels.

Technical Deep Dive

▶ Watch: Our approach: Cache and speculative execution (5:45)

The core of this MTE bypass attack lies in the ingenious combination of two fundamental CPU microarchitectural features: the cache side channel and speculative execution. By understanding how these features interact with MTE's tag checks, the researchers were able to construct a reliable tag leakage mechanism.

Cache Side Channel

A cache side channel exploits the timing differences inherent in memory access patterns. CPUs use a small, fast memory called a cache to store frequently accessed data.

• When the CPU accesses data for the first time, it must fetch it from the slower main memory, storing a copy in the cache. This access is slow.
• Subsequent accesses to the same data are fetched directly from the fast cache. This access is fast.

By precisely measuring the time it takes to access a specific memory location, an attacker can infer whether that data was recently accessed (fast, implying it's cached) or not (slow, implying it's not cached and had to be loaded from main memory). This timing difference provides a covert channel for information leakage.

Speculative Execution

Speculative execution is a critical CPU optimization technique designed to improve performance by avoiding stalls. When a CPU encounters a conditional branch (like an if statement) and the condition's value is not immediately known, it can "speculate" on the most likely outcome. It then proactively executes instructions from the predicted branch path, even before the condition is officially resolved.

• If the speculation is correct, the CPU commits the speculative state, and execution continues seamlessly.
• If the speculation is incorrect, the CPU reverts the speculative state, discarding the results and restarting execution from the correct path.

Crucially for this attack, tag check faults occurring during speculative execution do not crash the program. Instead, if a tag mismatch happens on a speculatively executed path, the CPU simply discards that path when the speculation is proven incorrect. This property allows attackers to "probe" memory addresses with various pointer tags without the risk of an immediate program crash, which would normally occur with MTE.

The MTE Tag Leakage Side Channel Mechanism

The researchers combined these two features to create an MTE side-channel attack:

1. Goal: To leak the memory tag of a target check object.
2. Setup: The attacker crafts code that uses a check pointer to access the check object within a speculatively executed block. This block also contains a dependent access to a test object using a test pointer.
3. Probing with Speculation: The attacker iteratively tries all 16 possible 4-bit tags for the check pointer. For each tag, the following sequence occurs:

• The CPU speculatively executes the block containing the check pointer access.
• Case A: Valid Tag Match: If the check pointer's speculative tag matches the check object's memory tag, the MTE hardware passes the tag check. The CPU proceeds to execute the subsequent instructions in the speculative block, including loading the test object into the cache. When the speculation is later reverted (because the condition was false), both the check object and test object remain in the cache.
• Case B: Invalid Tag Mismatch: If the check pointer's speculative tag does not match the check object's memory tag, the MTE hardware raises a tag check fault. At this point, the CPU, recognizing that the speculative path encountered a fault, may decide to stop or significantly reduce further speculative execution down that path. This means the instruction accessing the test object might not be executed, or its effects might not be committed to the cache. When the speculation is later reverted, only the check object (or potentially neither, depending on the exact microarchitecture) is in the cache, but the test object is definitely not.

1. Cache Side Channel Measurement: After each speculative probe, the attacker measures the access time for the test object.

• If the test object access is fast, it implies Case A (valid tag): the test object was cached, meaning the speculative path with the correct tag was executed further.
• If the test object access is slow, it implies Case B (invalid tag): the test object was not cached, meaning the speculative path with an incorrect tag was terminated early.

By observing which speculative pointer tag leads to a "fast" access for the test object, the attacker can reliably deduce the correct 4-bit memory tag of the check object.

This mechanism addresses the challenge faced by Google Project Zero, who previously attempted to find such a side channel but failed. Their attempts involved only a single load in the speculative block, which did not generate the necessary cache differences. The researchers' success stemmed from identifying specific memory access patterns, termed tag leakage gadgets, that reliably induce these differences.

Tag Leakage Gadgets

The researchers identified two distinct microarchitectural patterns that serve as reliable tag leakage gadgets:

1. Gadget 1: Multiple Loads in the Check Block

• Mechanism: This gadget requires at least two memory load instructions within the speculatively executed "check block" (the part where the check pointer is accessed). The test block can be any subsequent memory access to the test pointer.
• Reason for Success: Google Project Zero's previous attempts only tested with a single load. The researchers found that at least two loads were necessary to trigger the observable cache difference.
• Suspected Hardware Root Cause: While ARM does not disclose internal hardware details, the researchers, based on additional experiments and relevant ARM patents, suspect that the CPU's speculative execution engine might "respeculate" or reduce its speculative behavior if it encounters multiple faults (even speculative ones) within a short sequence. In other words, if a speculative path incurs too many MTE tag check faults, the CPU might interpret this as a strong indicator of an incorrect speculative path and prematurely halt subsequent speculative execution, preventing the test object from being cached.

1. Gadget 2: Store-to-Load Forwarding

• Mechanism: This gadget involves a store instruction immediately followed by a load instruction from the same address (check pointer) within the speculative check block. This pattern triggers store-to-load forwarding, a CPU optimization where the value written by the store is directly forwarded to the subsequent load from internal buffers, bypassing the cache hierarchy for speed. The test block then performs a memory access dependent on the value loaded in the check block.
• Observed Behavior: The researchers observed that when an MTE tag check fault occurs during this store-to-load forwarding sequence (either on the store, the load, or both), the dependent memory access in the test block is not executed. This means the data is not forwarded, and consequently, the test object is not cached.
• Suspected Hardware Root Cause: It is suspected that the CPU explicitly blocks store-to-load forwarding on faults. This is likely a defensive measure implemented by hardware designers to mitigate other potential side-channel issues that could arise from forwarding sensitive data or control flow information under fault conditions. By blocking forwarding on an MTE tag check fault, the CPU inadvertently creates the observable difference needed for this side channel.

Both gadgets provide a reliable way to differentiate between valid and invalid MTE tags by observing the caching behavior of a test object using the cache side channel. This orthogonal discovery of one of the gadgets by another research group, Vsec, and ARM's subsequent acknowledgment, further validates the significance and accuracy of these findings.

Demo / Proof of Concept

▶ Watch: How cache side-channels leak memory access (6:10)

The talk culminates with a demonstration of a real-world MTE bypass attack targeting the Google Chrome V8 JavaScript engine. This proof of concept highlights the practical applicability of the discovered MTE tag leakage side channel in a widely used software system.

The attack operates within the context of Chrome's renderer process. This process is responsible for handling untrusted content, including JavaScript, HTML, and CSS. It comprises several components:

• The V8 JavaScript engine, which compiles and executes JavaScript code.
• The Blink rendering engine, which handles page layout and rendering.
• Various third-party libraries.

The primary threat model for the renderer process involves an attacker providing malicious web content (JavaScript, HTML, CSS) to trigger memory corruption vulnerabilities. While the V8 sandbox is designed to isolate untrusted JavaScript code and prevent it from accessing arbitrary memory, vulnerabilities can still exist in the Blink engine or other third-party libraries within the renderer. Therefore, an attacker who can exploit a memory corruption bug in these components, even with the V8 sandbox enabled, can still compromise the renderer.

The researchers successfully constructed a tag leakage gadget directly from JavaScript code. This is a critical step, as it demonstrates that the low-level microarchitectural behaviors exploited by the side channel can be triggered and observed from a high-level scripting language, making the attack highly accessible. By running specially crafted JavaScript, the attacker can:

1. Trigger speculative execution paths involving MTE-protected memory within the V8 engine or other parts of the renderer.
2. Iteratively probe different 4-bit pointer tags for target memory addresses.
3. Observe cache timing differences using the cache side channel, which is also accessible from JavaScript (e.g., via high-resolution timers or by measuring array access times).

The outcome of this demonstration was the ability to leak the MTE tag of the entire renderer memory. This means that an attacker, having identified a memory corruption vulnerability within Chrome's renderer process, can now reliably determine the correct MTE tag for any memory object they wish to target. With this knowledge, they can craft a corrupted pointer with the precise matching tag, bypass MTE's tag check, and successfully exploit the underlying memory corruption vulnerability without crashing the browser. This effectively neutralizes MTE's protection for the Chrome renderer, turning a previously unreliable 6% success rate into a near-certain compromise.

This practical demonstration underscores that while MTE offers a robust new layer of defense, microarchitectural side channels can still undermine its effectiveness, even in complex, sandboxed environments like a web browser.

Defensive Implications

▶ Watch: Speculative execution prevents MTE tag check crashes (7:15)

The discovery of MTE tag leakage side channels has significant defensive implications for software developers, hardware architects, and security practitioners who rely on ARM MTE for memory safety.

1. MTE is Not a Silver Bullet (Yet): While ARM MTE remains a highly promising security feature and a significant step forward in hardware-assisted memory corruption detection, this research demonstrates that its current implementation is not impervious to sophisticated side-channel attacks. Defenders should understand that MTE, in its current form on devices like the Google Pixel 8, provides a strong deterrent but can be bypassed under specific microarchitectural conditions.

1. Awareness of Microarchitectural Vulnerabilities: The attack highlights the persistent threat posed by microarchitectural side channels, even against new, cutting-edge hardware security features. Defenders need to be aware that the interaction between software execution, CPU optimizations like speculative execution, and hardware security mechanisms can inadvertently create information leakage paths.

1. Need for Software and Hardware Enhancements: To fully realize MTE's potential, both software and hardware enhancements are necessary:

• Hardware Enhancements: CPU architects should investigate and mitigate the root causes of these side channels. This could involve modifying speculative execution engines to ensure that MTE tag check faults on speculative paths do not leave observable traces in the cache or other microarchitectural state. For instance, completely squashing any microarchitectural effects of a speculative fault, or ensuring that store-to-load forwarding is always blocked on faults without leakage, could be considered.
• Software Enhancements: Software developers adopting MTE should be aware of these leakage gadgets. While directly preventing their creation might be challenging in complex systems like JavaScript engines, compilers and runtime environments could potentially be hardened to avoid generating code patterns that inadvertently form these gadgets, or to introduce noise that obscures the side-channel signal. Additionally, critical security components might need to avoid relying solely on MTE for protection, especially in scenarios where high-resolution timers or other side-channel-enabling primitives are available to attackers.

1. Impact on MTE Adoption: As MTE support becomes more widespread (e.g., in Android, Chrome, and the Linux kernel), the findings of this research become increasingly relevant. Software vendors adopting MTE must consider these vulnerabilities and factor them into their overall security posture. While MTE still provides significant protection against simpler or non-side-channel-aware exploits, it cannot be considered a complete solution against highly motivated and skilled attackers.

1. Ongoing Research: This work underscores the dynamic nature of security research. As new defenses are introduced, the security community continues to probe their weaknesses. This iterative process drives continuous improvement in hardware and software security. The research serves as a call for continued collaboration between academia, hardware vendors (ARM), and software developers (Google, Microsoft) to refine and strengthen MTE against future attack vectors.

In summary, while ARM MTE offers a powerful new layer of defense against memory corruption, defenders should not treat it as an infallible solution. A comprehensive security strategy for MTE-enabled systems must account for potential microarchitectural side channels and integrate further software and hardware hardening to ensure robust protection.

Key Takeaways

• ARM Memory Tagging Extension (MTE) is a promising hardware-based defense mechanism designed to prevent memory corruption attacks by assigning 4-bit tags to memory and pointers.
• This research discovered a Memory Tagging Extension (MTE) tag leakage side channel on Google Pixel devices, demonstrating that MTE's protection can be bypassed.
• The attack leverages a combination of the cache side channel and speculative execution to infer memory tags reliably without crashing the program.
• Two specific tag leakage gadgets (memory access patterns)—"Multiple Loads" and "Store-to-Load Forwarding"—were identified as critical for inducing the observable cache differences.
• A real-world MTE bypass attack was demonstrated against the Google Chrome V8 JavaScript engine, allowing an attacker to leak the tags of the entire renderer memory from JavaScript.
• While MTE significantly raises the bar for attackers, current implementations require further hardware and software enhancements to mitigate these side-channel vulnerabilities and fully secure MTE-enabled systems.

About the Speaker(s)

The primary presenter of this research was Juhee Kim, a PhD student at Soul National University. Her research interests are broadly focused on general software system security, with a particular emphasis on identifying vulnerabilities and developing effective mitigations.

This research was a collaborative effort involving several distinguished individuals:

• Jinbon Park and Taso Kim from Samsung Research contributed to the project.
• From Soul National University, Juhee Kim collaborated with her advisor, Byong Young Lee, and colleagues Sian Ro, Jong Chong, and Young Julie.

The collective expertise of this team, spanning both academic research and industry, was instrumental in uncovering and detailing the sophisticated side-channel attack against ARM's Memory Tagging Extension.