iLeakage Under the Hood: How Safari WebAssembly and Apple Silicon Speculative Execution Leak Cross-Tab Secrets

For years, Apple Silicon has enjoyed an unassailable reputation for hardware security. Behind Apple’s custom ARM microarchitecture lies a fortress of silicon defenses: hardware-enforced Pointer Authentication Codes (PAC), Memory Tagging Extensions (MTE), and a security sandbox known as the WebKit 32-bit Gigacage. Yet in late 2023, academic researchers from Georgia Tech, University of Michigan, and Ruhr University Bochum shattered this illusion with iLeakage: the first microarchitectural speculative execution attack capable of completely breaking WebKit isolation and reading cross-tab secrets directly out of Safari’s memory.

Unlike traditional Spectre attacks that require high-precision timers like performance.now() (which Apple crippled to 1-millisecond resolution to thwart side-channel analysis), iLeakage achieves zero-permission, sub-nanosecond timing measurements using a stealthy WebAssembly cache eviction timer. Combined with a novel transient type confusion gadget, an attacker visiting a malicious webpage can silently extract passwords from Safari’s AutoFill manager, harvest private emails from open Gmail tabs, and leak authentication tokens across origins in real time.

What makes iLeakage an existential threat to modern browser security is that it targets the intersection of Apple’s wide out-of-order execution pipeline and WebKit’s architectural compromises. Here is the exhaustive, microarchitectural disassembly of how iLeakage weaponizes speculative execution, defeats Apple Silicon’s branch predictors, and turns Safari’s memory layout against itself.

1. The Illusion of Isolation: WebKit’s Shared Process Model

To understand why iLeakage is lethal on Apple devices, one must first confront the architectural divergence between Google Chrome and Apple Safari. In Chrome, the browser enforces Site Isolation: every website origin (e.g., bank.com vs. evil.com) is spawned inside a strictly separate operating system process with its own hardware Memory Management Unit (MMU) virtual address space. Even if speculative execution leaks memory in Chrome, the CPU’s page tables strictly forbid accessing memory belonging to another origin.

In Apple’s WebKit (which powers Safari on macOS, iOS, and iPadOS), strict site isolation was historically rejected due to severe memory overhead on mobile devices. Instead, Safari relies on a hybrid model where multiple cross-origin pages and nested iframes frequently share the exact same Unix process and address space:

• The Gigacage Sandbox: To prevent JavaScript from accessing unauthorized memory within this shared address space, WebKit introduced the “Gigacage”—a 4GB (32-bit) virtual memory sandbox reserved for JavaScript typed arrays. Any array indexing is masked with 32-bit bitwise AND operations: address = base + (index & 0xFFFFFFFF).
• The Shared Heap: Behind the Gigacage, the host process holds DOM structures, credential AutoFill buffers, and sensitive cryptographic session keys belonging to other open tabs and embedded web frames.

If an attacker can execute a speculative memory read that temporarily ignores the 32-bit masking constraint, they can access any 64-bit address within Safari’s memory space, obliterating cross-origin boundaries.

2. Weaponizing WebAssembly: The Zero-API Cache Eviction Timer

Every microarchitectural side-channel attack fundamentally requires a stopwatch. In Spectre-v1, an attacker measures how long it takes to read an array element: if the read takes 5 nanoseconds, the memory was cached in L1 (a cache hit, representing bit ‘1’); if it takes 80 nanoseconds, the memory had to be fetched from DRAM (a cache miss, representing bit ‘0’).

To defeat this, Apple deliberately degraded all browser timers: performance.now() was clamped to 1ms resolution and injected with artificial microsecond jitter. Furthermore, Apple blocked SharedArrayBuffer in many contexts to prevent concurrent thread counter timers.

iLeakage circumvents this software defense entirely by synthesizing a high-precision timer out of raw WebAssembly (Wasm) and cache eviction sets:

By chaining thousands of unrolled WebAssembly instructions that increment local variables without touching memory, the exploit creates an ultra-stable clock that measures CPU execution cycles with single-cycle precision (sub-nanosecond accuracy), completely bypassing Safari’s API timer clamps.

3. Apple Silicon’s 630-Entry Reorder Buffer (ROB): The Engine of Speculative Amplification

A crucial hidden fact of iLeakage is why it thrives so spectacularly on Apple Silicon (M1, M2, M3, M4 and A14 through A18) compared to conventional x86 processors. The answer lies in the radical microarchitectural dimensions of Apple’s Firestorm, Avalanche, and Everest performance cores:

• Mammoth Reorder Buffer (ROB): Apple Silicon features an astonishing 630-entry Reorder Buffer. For comparison, Intel’s high-performance Golden Cove / Raptor Cove cores feature 512 ROB entries, and AMD’s Zen 4 / Zen 5 cores feature 320 to 448 entries.
• 8-Wide to 10-Wide Instruction Decode: Apple’s front-end decodes up to 8 instructions per clock cycle and dispatches them across up to 16 execution ports.

In speculative execution attacks, the “speculative window” is the number of transient instructions the CPU can execute out-of-order before the branch misprediction is detected and the pipeline is flushed. When an unresolved branch instruction stalls waiting for a data operand from memory (an LLC or DRAM miss taking 150 to 250 cycles), Apple Silicon’s gigantic 630-entry ROB does not pause; it greedily dispatches up to several hundred speculative instructions deep down the wrong execution path!

This immense speculative depth allows iLeakage’s disclosure gadget to perform complex, multi-stage pointer arithmetic, dereference arbitrary memory locations, and complete the cache-line state change before the hardware branch predictor realizes it was tricked.

4. WebAssembly Eviction Set Synthesis: Reverse-Engineering Apple’s System Level Cache (SLC)

To perform Prime+Probe or Evict+Time side-channel leakage without administrative privileges, an attacker must construct an “Eviction Set”—a group of memory addresses that map to the exact same cache set in the processor’s Last-Level Cache (SLC).

Apple Silicon employs a complex, non-linear pseudo-random hashing function to distribute physical memory addresses across its multi-megabyte SLC cache slices. Under normal circumstances, this non-linear hashing prevents attackers from predicting cache collisions.

The authors of iLeakage solved this through an automated WebAssembly Cache Eviction Synthesis Algorithm:

1. The exploit allocates a large pool of memory (e.g., 64MB) in WebAssembly linear memory.
2. It systematically probes memory address pairs, measuring access latencies using its high-speed WebAssembly timer loop.
3. By observing latency spikes when two addresses collide in the same cache set, the exploit solves the underlying linear feedback shift register (LFSR) polynomial equations governing Apple’s cache slicing.
4. Within 15 to 30 seconds of running in a background tab, iLeakage constructs deterministic eviction sets that can evict any target cache line in Apple Silicon’s L2 and SLC with over 99% reliability.

5. Speculative Type Confusion: Escaping the 32-Bit Gigacage Sandbox

With an operational high-precision timer and deterministic eviction sets in hand, the attacker must bypass WebKit’s 32-bit Gigacage boundary to dereference arbitrary memory. iLeakage achieves this through Speculative Type Confusion in JavaScriptCore’s optimizing JIT compiler (DFG and FTL).

In JavaScript, an object property access like obj.x checks whether obj is of the expected type before reading the offset:

The exploit trains Apple Silicon’s branch predictor by repeatedly executing the gadget with valid objects thousands of times, biasing the branch history buffer (BHB). Then, the attacker passes an object containing an arbitrary 64-bit virtual memory address.

During the branch resolution pipeline stall (which takes 20 to 35 clock cycles while the CPU verifies the branch condition against memory), the out-of-order execution engine speculatively executes the instructions inside the block. Crucially, the compiler’s 32-bit masking operation is bypassed during the transient speculative window: the CPU loads data using the full unmasked 64-bit pointer, pulling a byte of victim memory from outside the Gigacage directly into the L1 data cache.

6. Cross-Tab Credential Exfiltration: Stealing Passwords and Gmail in Real Time

Once arbitrary memory can be speculatively dereferenced into the cache, iLeakage encodes the secret byte value into a cache side-channel via a classic Spectre disclosure gadget:

The attacker checks whether probe_array[0] or probe_array[4096] was loaded using their eviction-set timer, revealing the exact value of the secret bit. By repeating this process across 8 bits, an entire byte of memory is extracted.

The researchers demonstrated real-world proof-of-concept attacks against production applications running inside Safari on macOS and iOS:

• Credential Theft via Password Managers: When Safari’s built-in AutoFill or extensions (such as LastPass or 1Password) populate a login form in a background window, the plaintext password string resides in WebKit’s DOM tree memory. iLeakage traverses the DOM tree pointers and extracts the complete password in under 2 minutes.
• Gmail Inbox Harvesting: An attacker tab opening mail.google.com in a hidden window can scan the heap for HTML text strings, recovering email subjects, sender addresses, and body text with over 95% accuracy.
• Cross-Site Search (XS-Search) Leaks: By measuring how long speculative rendering takes on specific elements, the exploit reconstructs search queries and user profiles without triggering any security warnings or permission prompts.

7. Remediation Analysis: Lockdown Mode and the Cost of Defense

Mitigating iLeakage requires architectural changes at both the software and silicon microarchitecture levels. Apple acknowledged the vulnerability under CVE-2023-41993, but deploying comprehensive mitigations involves severe performance tradeoffs:

Currently, Apple users seeking absolute protection against iLeakage must enable Lockdown Mode in macOS Sonoma and iOS 17+. Lockdown Mode activates full out-of-process iframes in WebKit, disables JIT compilation optimizations, and enforces hardware MMU boundaries between origins, neutralizing the attack at the cost of battery life and complex web application speed.

8. Step-by-Step Exploit Anatomy: End-to-End Extraction Pipeline

To understand how iLeakage transforms transient microarchitectural cache states into exfiltrated credentials, the end-to-end exploit lifecycle can be deconstructed into six synchronized phases:

1. Phase 1: Ambient Microarchitectural Profiling: When a user navigates to a malicious webpage, a lightweight JavaScript script identifies the target Apple Silicon generation (M1, M2, M3, or A-series) by measuring cache line latency baselines and memory bus timing curves.
2. Phase 2: High-Resolution Timer Calibration: The exploit spins up a dedicated WebAssembly background worker. The worker executes an unrolled 64-bit integer increment loop, calibrating against standard CPU cycle frequency to establish a sub-nanosecond synthetic clock.
3. Phase 3: Eviction Set Convergence: By probing memory address pairs in WebAssembly linear memory, the exploit maps out the non-linear polynomial hashing matrix of Apple’s System Level Cache (SLC). It isolates an eviction set of 16 to 24 memory addresses that reliably conflict with the target cache line.
4. Phase 4: Branch Predictor Poisoning: The attacker executes a training loop 2,000 times with benign object references. This poisons the CPU’s Branch History Buffer (BHB) and Direction Predictor, guaranteeing that when the victim gadget is triggered, the CPU will predict the branch as “taken”.
5. Phase 5: Transient Speculative Dereferencing: The attacker passes a targeted 64-bit kernel or heap pointer. While the CPU verifies the branch condition across an L2 cache stall, the 630-entry Reorder Buffer speculatively dereferences the unmasked 64-bit pointer, loading the secret victim byte and using it to index a probe array.
6. Phase 6: Differential Cache Probing & Bit Recovery: Using the WebAssembly eviction timer, the exploit probes whether the probe array offset was loaded into cache. A timing below 12ns signals a cache hit (bit 1), while a timing above 45ns signals a cache miss (bit 0). By iterating through 8 bit positions, the secret character is extracted with over 96% confidence.

9. Institutional FAQ: Microarchitectural Security Q&A