Speculation barriers, in this case barriers that stop previously learned predictions from being used, are critical for computer software and cloud infrastructure to run securely. We have studied the IBPB speculation barrier in AMD and Intel systems and found several problems that undermine these security guarantees. See the paper here.
End-to-End Cross-Process Spectre Attack, Bypassing IBPB.
First, we found a microcode bug in the recent Intel microarchitectures — like Golden Cove and Raptor Cove, found in the 12th, 13th and 14th generation of Intel Core processors, and the 5th and 6th generations of Xeon processors — which retain branch predictions such that they may still be used after IBPB should have invalidated them. Such post-barrier speculation allows an attacker to bypass security boundaries imposed by process contexts and virtual machines. To demonstrate its impact, we show how an attacker can abuse post-barrier speculation to leak secrets from other processes in the system, including privileged ones, like sudo. It turns out, however, that even secuirty-senstive user programs don’t protect themselves against cross-process Spectre attackers by using IBPB — probably because noone has ever shown a real cross-process Spectre exploit. All we have seen so far are unrealistic toy-examples, carefully constructed to make a naive attack possible. Even if security-sensitive user programs were to use IBPB — which think that they should — they would be vulnerable anyway, due to the microcode bug in IBPB that we found. We are first to ever show a practical end-to-end cross-process Spectre leak, with an attack that leaks the root password has from a SUID (i.e., a process that runs with elevated privileges) process.
End-to-End Cross-Privilege Spectre Attack, Bypassing IBPB.
Second, IBPB has unclear semantics that have evolved over time. This makes it extremely difficult for OS maintainers to make the right design choises without introducing regression. Perhaps it can be compared to javascript coding in the early 2000s: even if it runs correctly in one browser, it may silenty break on a different browser. However intead of an irresponsible webpage, as we might have had with a javascript-quirk, we are facing the risk of attackers stealing secrets from their cloud provider! The unclear semantics that we refer to is that of AMD’s variant of IBPB, which neglects return branch predictions. This behavior conflicts with Intel’s specification of what IBPB should do, and also with what the most recent AMD processors in fact do. Operating systems and hypervisors use IBPB-on-entry as their strongest defense against various types of Speculation vulnerabilities. In Linux, an IBPB routine will hence be called on every transition to a higher privilege level (user-to-kernel, guest-to-host). This unfortunately does not not stop an attacker from injecting malicious return branch predictions before the IBPB operation has completed. As a consequence, we can hijack the speculative control flow where the OS/HV returns from the IBBP procedure! To demonstrate the impact of this, we resurrected the Inception attack that we introduced last year, calling it Post-Barrier Inception, or PB-Inception. Just like back then, PB-Inception leaks arbitrary privileged memory from the system, which we demonstrate by leaking the root password hash from the page cache of the system.
Reception
The discoveries made in this research were extensively covered by the media, in particular, The Register, BleepingComputer, CSO Online, Linux Security, Phoronix, TechRadar, and Fudzilla.
The patch developed by Johannes Wikner was merged in the Linux kernel to mitigate the Inception revival post-IBPB. RedHat issued CVE-2024-10041 for the PAM weakness that allowed exploitation with the Intel IBPB issue. grsecurity added a default-yes feature to their hardened kernel that protects suid processes by issuing IBPB now that our work shows Spectre exploitation in real-world cross-process scenarios.
Reception
A paper about these issues is going to be presented at IEEE Security and Privacy 2025.
FAQ
- Who is affected?
Intel Core 12th–14th generation, Xeon 5th-6th generation. Linux users on AMD Zen + and Zen 2. We also observed a faint signal on Zen 3, but it is unclear to us if it is exploitable. - Why only Linux?
We don’t know, as we don’t have the source code of other major OS vendors 😉 - What should I do?
Intel users should make sure their intel-microcode is up to date. AMD users should make sure to install kernel updates. - How do I get involved in this research?
Do a project with us or take our Hardware Security course! Have a read of the more technical write-up of the cross-process exploit on grsecurity where Johannes did part of the work.