## https://sploitus.com/exploit?id=A05EA2DC-4DF0-57A8-81B7-807BDB5214E7
# Memory Tagging Extension (MTE) and Speculative Execution Bypasses
This repository contains explanatory material and proof-of-concept (PoC) code to demonstrate and mitigate the **TikTag / StickyTags** speculative execution bypasses against ARM Memory Tagging Extension (MTE) implementations, specifically focusing on the vulnerabilities found in Google's Pixel devices, as highlighted in Apple's Memory Integrity Enforcement (MIE) blog post.
## 1. Low-Level Operating System Concepts
To understand the vulnerability, you must first understand the fundamental memory security mitigations built into modern ARM64 processors.
### What is Pointer Authentication Codes (PAC)?
Before MTE, Apple introduced PAC in 2018 (A12 Bionic). PAC is a **control-flow integrity** mechanism.
- It uses the upper, unused bits of a 64-bit pointer to store a cryptographic MAC (Message Authentication Code).
- The MAC is generated using a hardware key, the actual pointer value, and a "context modifier" (usually the Stack Pointer).
- When the CPU executes an instruction to return or jump (`RET` via the `AUT` instruction), it recalculates the MAC. If the MAC fails (e.g., an attacker overwrote the return address via a buffer overflow), the CPU corrupts the pointer, and the process crashes reliably. PAC protects *the pointer itself*, preventing attackers from hijacking the execution flow.
### What is Memory Tagging Extension (MTE)?
MTE is a **spatial and temporal memory safety** mechanism. It acts as a Lock and Key system for memory allocations.
- **The Key**: MTE utilizes the Top Byte Ignore (TBI) feature of AArch64 hardware to repurpose 4 bits of the pointer (usually bits 56-59) to hold a 4-bit "Tag". Since it's 4 bits, there are only 16 possible tags.
- **The Lock**: The CPU maintains a dedicated region of physical memory space, completely hidden from the OS, where it stores a 4-bit tag for every 16-byte "granule" of regular RAM.
- **Verification**: Every time the CPU performs a load/store, it compares the pointer tag to the memory granule tag. If they do not match, the hardware throws a synchronous fault (crashing the process) or an asynchronous fault (logged for debugging). This stops use-after-free (temporal) and buffer overflows (spatial) because adjacent allocations or freed chunks have different tags assigned to them by the allocator.
### What is Enhanced MTE (EMTE)?
EMTE is Apple's specialized evolution of MTE. One of the primary weaknesses of native ARM MTE is that out-of-bounds accesses originating from *untagged* memory (like global variables) into *tagged* memory are weakly enforced, meaning attackers could leak the secrets of the MTE tags. EMTE introduces strict **Tag Confidentiality**, enforcing that any cross-boundary memory queries require the correct tag. Furthermore, Apple's MIE hardware ensures that speculative execution *never* allows an attacker to derive MTE tags through side channels (which is the vulnerability we exploit here).
## 2. The Vulnerability: Speculative Execution (TikTag/StickyTags)
The "Memory Integrity Enforcement" blog post references the Pixel MTE bypassing research (TikTag / StickyTags). The vulnerability exists because, on the ARM Cortex CPU cores used in the Pixel line, the CPU handles MTE mismatches poorly during **Speculative Execution**.
Modern CPUs guess the outcome of branches (`if` statements) to run faster (Speculative Execution). If the CPU guesses wrong, it rolls back its state. However, the CPU cannot roll back the *cache*. This is the basis of **Spectre**.
When an attacker tries to access memory with an incorrectly guessed MTE tag, they do so inside a speculatively executed code path.
1. The attacker guesses an MTE tag (0 through 15) and appends it to a pointer.
2. The CPU speculatively checks the memory address.
3. Because the CPU is only speculating, if the guessed MTE tag is WRONG, it *drops* the subsequent speculative memory loads without throwing an architectural crash.
4. If the guessed MTE tag is RIGHT, it *caches* the subsequent speculative memory loads.
5. The CPU rolls back the state, and the attacker times the cache. If the subsequent load was fast (cache hit), the attacker knows the tag was CORRECT. They have bypassed MTE without crashing the Pixel.
## 3. The Code Solutions
We've provided two source files to demonstrate the attack and the mitigation:
- **[`exploit/tiktag_poc.c`](exploit/tiktag_poc.c)**: This is the exact speculative execution snippet demonstrating the cache leakage. An attacker would use this in a tight loop to guess the 16 MTE tags and then seamlessly transition into a memory corruption chain.
- **[`patch/kernel_mitigation.c`](patch/kernel_mitigation.c)**: This demonstrates the software mitigation required to run on a vulnerable piece of hardware like the Cortex core. It shows the use of the `barrier_nospec()` (Context Synchronization Barrier / CSDB) instruction, which physically halts the CPU's speculative execution engine until all prior conditions are validated.
## Summary
This repository captures the essence of why hardware-assisted memory safety remains an incredibly complex field. The fact that an architectural security boundary (MTE) can be defeated by a microarchitectural side channel (Spectre/Cache Timing) highlights exactly why Apple invested heavily into building the Apple A19 architecture to enforce EMTE in hardware continuously, preventing speculative bypassing entirely.