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.
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 gernations of Xeon processors --
which retains 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 security-sensitive
user programs don't protect themselves against cross-process Spectre attackers
by using IBPB --- probably because nobody 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 we 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 hash from a SUID (i.e., a process that runs with
elevated privileges) process via a speculatively executed ROP-gadget chain.
https://www.youtube.com/watch?v=VYEVcj-vnbs
Second, IBPB has unclear semantics that have evolved over time. This makes it extremely difficult for OS maintainers to make the right design choices without introducing regressions. Perhaps it can be compared to javascript coding in the early 2000s: even if it runs correctly in one browser, it may silently break on a different browser. However instead of an irresponsive 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 IBPB 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.
https://www.youtube.com/watch?v=eODoOyhqtaQ
-
Who is affected? Intel Core 12th--14th generation, Xeon 5th-6th generation. Linux users on AMD Zen + and Zen 2.
-
Only Linux? We don't know what MS and Apple do. Other open source projects are in general lacking Spectre mitigations.
-
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. CPU vendors should communicate with OS maintainers better, and also with eachother.
-
How do I get involved in this research? Do a project with us, take our courses. Have a read of the more technical write-up of the cross-process exploit on https://grsecurity.net/