Racing for Privilege

Racing for Privilege: Leaking Arbitrary Memory on Intel Systems via a Microarchitectural Race Condition

Speakers: Sandro (PhD student) and Johannes Wikner (PhD, COMSEC, ETH Zurich)

Conference: Black Hat USA 2025 — August 6-7, 2025, Mandalay Bay, Las Vegas

YouTube: https://www.youtube.com/watch?v=ULXuhxj-WgA

Reading Time: ~9 minutes

Type: Briefing

TL;DR

Researchers from COMSEC at ETH Zurich discovered a microarchitectural race condition in Intel processors that undermines both Enhanced Indirect Branch Restricted Speculation (eIBRS) and the Indirect Branch Prediction Barrier (IBPB) — the primary hardware mitigations against Spectre-class branch target injection attacks. The vulnerability affects every recent Intel CPU with in-silicon Spectre mitigations, is demonstrated by leaking /etc/shadow on a fully patched Ubuntu system, and extends into VM-to-host cross-privilege attack scenarios. A microcode fix was issued by Intel.

Introduction

Since the disclosure of Spectre and Meltdown in January 2018, the relationship between CPU vendors and the security research community has followed a familiar pattern: a new speculative execution attack is discovered, a mitigation is issued, and within months or years, researchers find a way around it. The ETH Zurich COMSEC group — previously responsible for Retbleed, Phantom Speculation (branch type confusion), and Inception (SRSO) — now adds another link in that chain.

The core of the new attack is a race condition inside Intel's branch predictor update pipeline. By issuing a system call at precisely the right moment after training the branch predictor, an unprivileged user-space program can inject predictions across privilege boundaries in a way that eIBRS — Intel's long-trusted in-silicon mitigation — is designed to prevent but fails to block. The attack requires only local code execution (achievable via a browser, for example), bypasses all enabled mitigations on the target kernel, and is demonstrated live during the talk on a 13th-generation Intel (Raptor Lake) system running Ubuntu 24.04.

Background: How Branch Target Injection Works

▶ Watch: Spectre and Branch Target Injection Primer (02:00)

Modern CPUs execute instructions speculatively: rather than waiting for a branch target to be computed, the processor guesses where control flow will go and begins executing along that path. If the guess is wrong, speculative work is discarded. The key insight from Spectre is that even discarded speculative execution leaves microarchitectural side effects — typically, cache state changes — that can be measured to leak information.

Branch target predictions are stored in hardware structures (branch target buffers, indirect branch predictors) that are indexed by virtual address rather than physical address. Because virtual addresses are shared or aliased across programs and privilege levels, an attacker in one privilege domain can train the predictor to point at an address it controls, then induce the victim domain (e.g., the OS kernel) to use that poisoned prediction during its own execution. Speculatively executing attacker-chosen code in the kernel's context allows reading kernel memory and leaking it through cache timing (Flush+Reload or Prime+Probe).

The standard disclosure gadget consists of just two instructions: load a value from a pointer in one register, then use that value as an offset in a second memory access. This pattern, compiled into the kernel, enables transmitting a secret byte back to the attacker.

Intel's eIBRS Mitigation — and Why It Fails

▶ Watch: eIBRS Design and Observed Failure (08:00)

Intel's response to Spectre v2 went through two generations. The first, Indirect Branch Restricted Speculation (IBRS), required software to toggle a control register on every privilege transition and was harshly criticized (including by Linus Torvalds, who called the interface "misdesigned by morons"). The successor, Enhanced IBRS (eIBRS), is a set-and-forget operation: write once to the IA32_SPEC_CTRL MSR at boot and the CPU adds privilege-domain tagging to branch predictions, preventing cross-privilege injection.

The COMSEC team began investigating eIBRS behavior on newer processors and found an anomalous signal: once in a million measurement iterations, something resembling a cross-privilege injection success would appear — even with eIBRS enabled. The signal was too weak to build an attack from, but it was reproducible enough to pursue.

After more than a month of systematic experimentation — including creating hundreds of micro-variants of the same experiment to isolate variables — the team discovered that moving cache preparation steps into the kernel made the injection reliable. More strangely, inserting getpid system calls in certain positions also dramatically strengthened the signal. This combination implied a connection between system call timing and branch predictor injection.

The Race Condition: How the Attack Actually Works

▶ Watch: Race Condition Discovery and Mechanism (14:00)

The explanation the team developed is that branch predictor updates are not instantaneous. When the CPU executes a branch and decides to record a prediction, that update enters a queue before being committed to the predictor structure. During the brief window while the prediction is in-flight in this queue, a privilege switch — triggered by a system call — can cause the CPU to record the prediction with the wrong privilege tag: specifically, the privilege level currently in effect at commit time rather than the privilege level at training time.

In practical terms: an unprivileged attacker trains the branch predictor, immediately issues a system call, and if the syscall executes while the prediction is still queued, the prediction is tagged as kernel-mode. eIBRS then happily uses this poisoned prediction for a kernel indirect branch, producing speculative execution under attacker control.

The timing relationship is cleanly demonstrable: plotting injection success rate against NOP-inserted delay between training and the system call produces a sharp cliff — success when delay is very short, failure when the delay exceeds a threshold. This confirms the race is real and the timing dependency is tight but exploitable.

IBPB Is Also Broken

A secondary finding: Indirect Branch Prediction Barrier (IBPB), the mechanism used when switching between virtual machines, is similarly affected. If new predictions arrive in the update queue while IBPB is executing, those predictions commit after the barrier completes, defeating the isolation IBPB is supposed to enforce. This creates guest-to-host attack scenarios across VM boundaries.

An additional observation: a mitigation Intel introduced against Branch History Injection (BHI) — called BHIDIS (BHI Disable in Supervisor mode), which simply disables a history-based predictor in supervisor mode — inadvertently makes the new attack easier on modern processors. By disabling one predictor, Intel eliminates it as a competing source of predictions, making the attacker's injected prediction more likely to win.

Live Demonstration: Leaking /etc/shadow

▶ Watch: Live Attack on 13th-Gen Intel (22:00)

The talk included a live demonstration on a 13th-generation Intel processor (Raptor Lake) running the newest Ubuntu LTS with all mitigations enabled and no access to the password file or sudo.

The attack proceeds in several steps:

1. Find an indirect branch in the kernel — the keyctl syscall contains a function pointer call where the attacker controls two registers (buffer and buffer length).
2. Scan for a disclosure gadget in the kernel — a two-instruction sequence that loads from a pointer then performs a secret-dependent memory access.
3. Locate the kernel via KASLR bypass — achieved by brute-forcing candidate memory locations.
4. Find shared memory for the side channel and locate /etc/shadow in kernel memory by scanning for the known prefix (Ubuntu shadow files always begin with a predictable string when a password is set).
5. Execute the attack — inject the prediction, trigger the misprediction via system call, observe the cache side channel.

The result: /etc/shadow content, including root password hashes, appeared on screen within the demonstration time. The exploit shown at Black Hat was 10x faster than the version originally developed, because the team wanted a clean on-stage demo.

The vulnerability traces back to the first Intel CPU with in-silicon Spectre mitigations. For earlier CPUs lacking in-silicon mitigations, IBPB is still broken. Processors that had not shipped at time of disclosure were also tested and found vulnerable.

Intel's Response and Remaining Uncertainty

▶ Watch: Disclosure, Microcode Fix, and Conclusions (26:01)

Intel provided a microcode patch as a black box — encrypted, with no documentation of the mechanism. The researchers verified that their PoC no longer worked against it, but because the fix is opaque, they cannot confirm that all variants are addressed or that no alternative injection path exists.

The team also published gadget scanners to help researchers locate disclosure gadgets in other kernels or software targets.

Notable Quotes

"We found a race condition that undermines the long-trusted eIBRS mitigation, and actually also the IBPB mitigation."

— Johannes Wikner ▶ 26:01

"The mitigation to a previous attack actually makes our attack really easy."

— Sandro ▶ 18:00 (on BHIDIS inadvertently aiding the new attack)

"This whole Spectre thing is a kind of cat-and-mouse game. It's been going on since 2018 at least. We keep finding new things, and we think it's not too late for people to jump on the wagon because this is not going to be over very soon."

— Johannes Wikner ▶ 26:01

"We have to assess these black box mitigations that hardware vendors provide to us, because we start to see more and more software-like vulnerabilities in them — vulnerabilities like type confusions."

— Johannes Wikner ▶ 26:01

Key Takeaways

• eIBRS, Intel's primary Spectre v2 mitigation, is broken on all recent Intel CPUs. A microarchitectural race condition between branch predictor training and the subsequent system call allows cross-privilege prediction injection despite eIBRS's privilege-domain tagging.
• IBPB — used for VM isolation — is also affected. Predictions queued during IBPB execution commit after the barrier, enabling guest-to-host attacks.
• The attack requires only local code execution. Browsers, document readers, and any sandboxed environment that runs untrusted code are in-scope attack surfaces.
• Intel mitigations for one vulnerability can introduce exposure to another. BHIDIS, deployed to block BHI attacks, made the race condition attack easier by eliminating a competing predictor.
• Black-box microcode patches cannot be fully verified. The community needs access to mitigation mechanisms to confirm correctness — hardware security mitigations are increasingly exhibiting software-style bugs and deserve the same degree of scrutiny.

No slides PDF was listed for this briefing.