InSpectre Gadget

Inspecting the Residual Attack Surface of Cross-privilege Spectre v2

TL;DR

We present InSpectre Gadget, an in-depth Spectre gadget inspector that uses symbolic execution to accurately reason about exploitability of usable gadgets. Our tool performs generic constraint analysis and models knowledge of advanced exploitation techniques to accurately reason over gadget exploitability in an automated way.

We show that our tool can not only uncover new (unconventionally) exploitable gadgets in the Linux kernel, but that those gadgets are sufficient to bypass all deployed Intel mitigations. As a demonstration, we present the first native Spectre-v2 exploit against the Linux kernel on last-generation Intel CPUs, based on the recent BHI variant and able to leak arbitrary kernel memory at 3.5 kB/sec. 

Here’s a demo of our exploit leaking /etc/shadow:

Native BHI (CVE-2024-2201) 

But wait, wasn’t BHI fixed? Let’s delve deeper.

In our prior work, we demonstrated that Spectre-V2 attacks were still possible in the kernel through Branch History Injection (BHI), and used eBPF to craft a Spectre disclosure gadget (or simply Spectre gadget for simplicity). In response, vendors suggested disabling unprivileged eBPF. This mitigation left us with a dangling question: “Is finding ‘native’ Spectre gadgets for BHI, i.e., not implanted through eBPF, feasible?”

To address this question, we developed InSpectre Gadget. With this tool, we can analyze Spectre gadgets and reason about their (advanced) exploitability. Our efforts led to the discovery of 1,511 Spectre gadgets and 2,105 so-called “dispatch gadgets”. The latter are very useful for an attacker, as they can be used to chain gadgets and direct speculation towards a Spectre gadget.

As the number of gadgets we found point to a nontrivial attack surface, vendors are now recommending to mitigate Native BHI by enabling hardware mitigations and, for older CPUs, software mitigations.

From the many gadgets we discovered, we selected one and crafted an end-to-end Native (eBPF=off) BHI exploit. The video above showcases this exploit in action.

FineIBT Bypass

Building upon CET-IBT, FineIBT introduces fine-grained control-flow integrity (CFI). Our research shows that, while FineIBT does shorten the speculation window, it falls short of completely closing it. The situation becomes even more problematic when we start a contention workload on the sibling core: the speculation window size increases and an attacker can now fit hundreds of Spectre gadgets discovered by InSpectre Gadget.

To demonstrate the issue, we created a FineIBT Bypass PoC based on Native BHI:

InSpectre Gadget

Whenever there is a chain of loads that can be executed in a speculative window, we might be able to leak memory through a side channel. However, not all double loads are created equal. In particular, finding viable gadgets for Spectre-V2 in a codebase like the Linux Kernel requires a scalable approach.

To find Spectre-V2 gadgets we used a new angr-based gadget analyzer, which we call InSpectre Gadget. We open-sourced the source code, documentation, and a database of gadgets for the Linux Kernel, version 6.6-rc4 (see below). This tool finds potential Spectre gadgets and classifies them based on properties like where can we leak from, where can we place our reload buffer, etc.

The main idea behind InSpectre Gadget is to start from a list of speculation entry points, e.g., all the indirect call targets in the kernel, run an analyzer that performs an in-depth scan of the speculation window, including attacker-controlled values, constraints and ranges, and finally pass the results to a reasoner that is aware of advanced exploitation techniques.

InSpectre Gadget overview

Tool Internals

The analyzer initially marks registers and stack locations as symbolic, then uses symbolic execution to explore each speculation window for a limited (configurable) amount of basic blocks through symbolic execution, recording all symbolic memory operations (attacker-controlled loads) and symbolic jumps (potential dispatch gadgets), together with branch conditions and other constraints. Later, the symbolic expression of potential transmissions is inspected to extract the base (e.g., position of the reload buffer for Flush+Reload) and the secret being transmitted, and a fast range analysis is performed. Finally, a database of all potential transmissions found is outputted.

The next step is to run the reasoner. Instead of looking statically for patterns that resemble a “perfect” gadget (i.e, attacker-controlled load + masking + shifting + second dependent load), we take into account different side-channels and a multitude of exploitation techniques that have shown how “imperfect” gadgets can still be exploited (Retbleed, Spec Probing, Leaky Address Mask). This strategy relaxes the common preconditions of standard gadgets, while still avoiding the common overapproximations that would otherwise report many unexploitable gadgets. Moreover, it provides the analyst with insights into exploitability characteristics, such as the exploitation techniques required, the constraints to be met, the values that can be leaked, etc.

Here’s an example of the output of the scanner (annotated assembly) and a short demo of the workflow:

Annotated assembly file generated by InSpectre Gadget. Right to the assembly instructions, we output the annotations attached to the source and destination operands (source → destination). The annotations include the origin of the value, which is either the instruction pointer of the source load or a register (e.g., @rdi). As we generate for each detected gadget an annotated assembly file, we do not print annotations that are irrelevant to the gadget flow and we replace all secret annotations with an attacker annotation that are, for this specific gadget, not used as a secret but as an attacker-controlled value. In the case of a branch instruction, we show the branch condition to hold instead.
As shown by the annotations, the attacker-controlled value rdi is used in the first load ①, followed by a series of loads whose controllability is tracked ②. The encountered branch condition is recorded ③. Subsequently, the secret value is loaded from an attacker-controlled value ④ and transmitted using an attacker-controlled value as the base ⑤. We output key details after the assembly code, including the symbolic expression and the range—i.e., (min, max, stride)—for each transmission component ⑥, insights about the transmitted secret bits ⑦, details about which registers an attacker should control to exploit the gadget ⑧ as well as the constraints and branches encountered ⑨.
Annotated assembly file generated by InSpectre Gadget. Right to the assembly instructions, we output the annotations attached to the source and destination operands (source → destination). The annotations include the origin of the value, which is either the instruction pointer of the source load or a register (e.g., @rdi). As we generate for each detected gadget an annotated assembly file, we do not print annotations that are irrelevant to the gadget flow and we replace all secret annotations with an attacker annotation that are, for this specific gadget, not used as a secret but as an attacker-controlled value. In the case of a branch instruction, we show the branch condition to hold instead.
As shown by the annotations, the attacker-controlled value rdi is used in the first load ①, followed by a series of loads whose controllability is tracked ②. The encountered branch condition is recorded ③. Subsequently, the secret value is loaded from an attacker-controlled value ④ and transmitted using an attacker-controlled value as the base ⑤. We output key details after the assembly code, including the symbolic expression and the range—i.e., (min, max, stride)—for each transmission component ⑥, insights about the transmitted secret bits ⑦, details about which registers an attacker should control to exploit the gadget ⑧ as well as the constraints and branches encountered ⑨.
Annotated assembly file generated by InSpectre Gadget. Right to the assembly instructions, we output the annotations attached to the source and destination operands (source → destination). The annotations include the origin of the value, which is either the instruction pointer of the source load or a register (e.g., @rdi). As we generate for each detected gadget an annotated assembly file, we do not print annotations that are irrelevant to the gadget flow and we replace all secret annotations with an attacker annotation that are, for this specific gadget, not used as a secret but as an attacker-controlled value. In the case of a branch instruction, we show the branch condition to hold instead.
As shown by the annotations, the attacker-controlled value rdi is used in the first load ①, followed by a series of loads whose controllability is tracked ②. The encountered branch condition is recorded ③. Subsequently, the secret value is loaded from an attacker-controlled value ④ and transmitted using an attacker-controlled value as the base ⑤. We output key details after the assembly code, including the symbolic expression and the range—i.e., (min, max, stride)—for each transmission component ⑥, insights about the transmitted secret bits ⑦, details about which registers an attacker should control to exploit the gadget ⑧ as well as the constraints and branches encountered ⑨.

Demo of the gadget-analysis workflow with InSpectre Gadget (Click on it to expand)
Demo of the gadget-analysis workflow with InSpectre Gadget (Click on it to expand)
Demo of the gadget-analysis workflow with InSpectre Gadget (Click on it to expand)

More details

InSpectre Gadget paper (PDF) is accepted for publication at the 33rd USENIX Security Symposium 2024. Checkout the paper, code and documentation:

FAQ

How does Native BHI differ from BHI?

The original BHI attack was demonstrated by using eBPF. As a response, unprivileged eBPF was disabled and the BHI attack demonstrated in the paper was mitigated. We now show that BHI is possible without eBPF, thus Native BHI.

Which systems are affected by Native BHI?

Short answer: All Intel systems that were affected by BHI are also affected by Native BHI.

How can I protect my system?

Please refer to the security advisory:
https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/branch-history-injection.html

Acknowledgements

We would like to thank the anonymous reviewers for their feedback. This work was supported by Intel Corporation through the “Allocamelus” project, by the Dutch Research Council (NWO) through project “INTERSECT”, and by the European Union’s Horizon Europe programme under grant agreement No. 101120962 (“Rescale”).