SLAM explores the residual attack surface of Spectre on modern (and even future) CPUs equipped with Intel LAM or similar features. Instead of targeting new transient execution techniques (like BHI or Inception), SLAM focuses on exploiting a common but previously unexplored class of Spectre disclosure gadgets. Standard (so-called “masked”) disclosure gadgets involve code snippets that use secret data to index into an array:
void classical_gadget(long *secret) {
array[(*secret & 0xff) * 4096];
}
As this is a relatively uncommon code pattern, regular software does not contain many standard Spectre gadgets. For example, the Linux kernel is believed to contain no such gadgets that are exploitable (with mitigations in place) at the time of writing.
SLAM targets different kinds of code patterns, namely pointer chasing snippets. Those result in so-called “unmasked” gadgets using secret data as a pointer:
void unmasked_gadget(long **secret) {
**secret;
}
Since this is a very common code pattern, unmasked gadgets are widespread in regular software. We built a gadget scanner that found tens of thousands of such gadgets in the Linux kernel, out of which at least hundreds are practically exploitable.
Leaking ASCII Kernel Data
SLAM exploits unmasked gadgets to let a userland process leak arbitrary ASCII kernel data. In the demo below, we leak the root password hash within half a minute on a last-generation Ubuntu system, where we emulate the upcoming Intel LAM feature (see below).
Affected CPUs
SLAM is the first transient execution attack targeting future CPUs. Multiple chip vendors are working on linear address masking features in their upcoming CPUs (e.g., Intel’s Linear Address Masking or LAM and AMD’s Upper Address Ignore or UAI). Although these are (future) hardware features aimed at improving security, SLAM shows that, by loosening canonicality checks, they also enable the exploitation of unmasked Spectre gadgets. More generally, SLAM shows that microarchitectural security crucially depends on strong canonicality checks. Therefore, even existing CPUs with weak canonicality checks may be affected. In short, the following CPUs are affected:
- Existing AMD CPUs vulnerable to CVE-2020-12965;
- Future Intel CPUs supporting LAM (both 4- and 5-level paging);
- Future AMD CPUs supporting UAI and 5-level paging;
- Future Arm CPUs supporting TBI and 5-level paging.
How Does SLAM Work?
For SLAM, we developed a new covert channel to leak data via unmasked gadgets. A key ingredient is transiently bypassing canonicality checks, either by abusing linear address masking features or microarchitectural race conditions (on existing AMD CPUs). Furthermore, we replace classical cache covert channels with address translation-based covert channels, in order to bypass the SMAP mitigation. Using just-in-time reload buffer and sliding techniques, we can craft an exploitable covert channel.
Tell Me More
Check out our Leaky Address Masking paper (to appear at IEEE S&P’24). Also our code and data is available in a public GitHub repository.
Response
In response to SLAM, Intel made plans to provide software guidance prior to the future release of Intel processors which support LAM (e.g., deploying LAM jointly with LASS). Linux engineers developed patches to disable LAM by default until further guidance is available. ARM published an advisory to provide guidance on future TBI-enabled CPUs. AMD did not implement guidance updates and pointed to existing Spectre v2 mitigations to address the SLAM exploit described in the paper.
Acknowledgments
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”).