Security1 publisher2 min readPublished
Chipmakers leave the Branch Target Reuse fix to each JIT engine that rewrites code
Intel, AMD and Arm say their IBPB barrier can block Branch Target Reuse, a Spectre v2 variant hitting all three, if JIT software calls it. Each kernel, browser and runtime that rewrites JIT code now has to add that call itself.
The Watch · Security desk
What happened
- Stale indirect-branch predictions survive after a JIT engine writes new code into old memory, letting an attacker steer speculation into the new code at outdated offsets.
- On modern Intel CPUs, the researchers' Linux kernel exploit leaked arbitrary memory past every enabled mitigation on a fully updated system with default settings.
- The kernel attack runs through classic BPF, which unprivileged programs can still load and which seccomp, socket filtering, Docker and Chrome still rely on.
- A proof of concept showed stale branch entries persisting in SpiderMonkey, Firefox's JavaScript and WebAssembly engine, on Intel long enough to be reused.
Compiled by The WatchSomething wrong?How this is made
Why it matters
- exposure Until a host runs the patched kernel, an attacker with an unprivileged foothold on Intel Linux has a demonstrated route to reading arbitrary kernel memory.
- decision Mozilla chose to finish site isolation before adding IBPB, so Firefox's defence rests on that rollout, and until it completes, content from other tabs may sit in the attacker's address space.
- precedent With the fix assigned to software, each JIT engine that reuses code memory needs its own barrier call, and the research examined only three engines.
Ranked by what has been demonstrated, the Linux kernel on Intel comes first. The researchers built two end-to-end exploits against it [4], and the attack starts from code already running on the target machine [9]. "Our exploit leaks 8 bytes per second. That may sound slow, but with careful pointer chasing we only need to leak a small amount of data to reach the secret," the researchers wrote [7]. Eight bytes a second is about 480 bytes a minute [1]. In their demo, that rate was enough to locate and leak the root password hash after it was loaded into memory [8].
Linux kernel developers have added the barrier on x86. The kernel now triggers an IBPB across every CPU core whenever a cBPF program is placed in a memory region that previously executed BPF code already used [16]. The report does not list a CVE identifier or disclosure dates, or describe any use of the technique outside the researchers' work.
The browser case is less developed. Attacks from malicious web pages appear feasible, but the researchers have not built a complete browser exploit [9]. They estimate SpiderMonkey could leak dozens of bytes per second, and say more work is needed to get there [12].
In GraalVM, BTR could let an attacker speculatively skip the memory masking that protects the runtime's strictest sandbox mode against Spectre [13]. The researchers reliably reused memory addresses, but GraalVM's own compilation and garbage collection erased the stale branch entries before they could be exploited [14]. The researchers said that limitation "does not appear fundamental" [14]. Oracle has rolled out some mitigations [17].
The researchers trace the problem to a branch predictor that can drift out of step with the code actually in memory [20]. "No current CPU has a mechanism to keep the two in sync, so until vendors add one, your CPU is vulnerable," they wrote [21].
What to watch
- A complete SpiderMonkey exploit that turns the researchers' estimate of dozens of bytes per second into a working browser attack.
- A Linux mitigation for Arm cores; the kernel change described so far covers x86.
- A GraalVM attack that survives the runtime's garbage collection, the obstacle the researchers say is not fundamental.