For the first time, we show that speculative execution enables attackers to leak sensitive information also across cores on many Intel CPUs, bypassing all the existing intra-core mitigations against prior speculative (or transient) execution attacks such Spectre, Meltdown, etc. Until now, all the attacks assumed that attacker and victim were sharing the same core, so that placing mutually untrusting code on different cores would thwart such attacks. Instead, we present a new transient execution vulnerability, which Intel refers to as “Special Register Buffer Data Sampling” or SRBDS (CVE-2020-0543), enabling attacker-controlled code executing on one CPU core to leak sensitive data from victim software executing on a different core.
To uncover the new vulnerability, we built CrossTalk, a profiler to inspect the behavior of complex (“microcoded”) x86 instructions beyond the CPU core boundaries. With CrossTalk, we discovered that various instructions perform offcore requests to read data from a staging buffer shared between all the CPU cores. We observed that the staging buffer contains sensitive data, including the output of the hardware digital random number generator (DRNG), and that such data can be leaked across cores using RIDL (aka MDS) attacks. We show this vulnerability can be exploited in practice against victim applications running in Intel Software Guard Extension (SGX) secure enclaves. In particular, our end-to-end exploit can leak the entire private key of a secure enclave running on a separate CPU core after only a single digital signature operation.
Our CrossTalk paper (PDF) is accepted for publication at the IEEE Symposium on Security & Privacy 2021.
Background
In the past few years attacks like Meltdown, Spectre, Foreshadow, and RIDL demonstrated that information leakage is possible across all security domains supported by many modern CPUs. This is due to the speculative/out-of-order execution performed by modern CPU pipelines, which allows an attacker to observe side-effects of transiently executed code over internal CPU core components, as shown in Figure 2 for instance Line Fill Buffer, Load Port, Store Buffer, etc.. These microarchitectural components are all shared among the hardware threads (or hyperthreads) running on the same CPU core. As we will show below, CrossTalk forces information from other cores to be transferred to on-core resources such as the Line Fill Buffers (LFBs) and then uses RIDL to inspect the content of the LFBs.
From On-Core to Off-Core Leakage Sources
Cross-core transient execution attacks are enabled by instructions that perform offcore accesses to shared buffers. In particular, as shown in Figure 1, we found a variety of complex microcoded instructions that perform offcore accesses to a microarchitectural buffer shared across all the CPU cores, which we refer to as the staging buffer. Interestingly, the staging buffer retains the results of previously executed offcore-instructions across all CPU cores. For instance, it contains the random numbers returned by the offcore hardware DRNG (Figure 3), bootguard status hashes, and other sensitive data. With CrossTalk, we show reading from this staging buffer during transient execution may leak sensitive data accessed by previously executed victim instructions.
The CrossTalk Profiler
In order to investigate this behavior, we built CrossTalk, a profiler for examining the behavior of all x86 instructions beyond the CPU core boundary. CrossTalk (Figure 4) profiles all the x86 instructions that make offcore memory requests―generating the instructions with different contexts (e.g., providing different operands). We use the output of the instruction generation stage in combination with the existing RIDL attack to understand the interaction between on-core Line Fill Buffers (LFBs) with the global staging buffer. Essentially, we use RIDL to inspect what is in the LFBs after we execute one of these instructions.
Profiling Vulnerable Instructions
The design of CrossTalk’s instruction-profiling stage (Figure 5) is as follows. First, on one CPU core, we run the target instructions that potentially interact with the staging buffer. Then, on another CPU core, we try to observe whether the contents of the staging buffer change due to the execution of the target instructions. To make sure that we observe the contents of the staging buffer, we need to ensure that we continuously pull data from the staging buffer. We use what we call staging buffer leaking primitives (e.g. CPUID 0x80000002) for this purpose.
To profile a target instruction (Figure 6), the CrossTalk-controlled CPU core first primes the staging buffer by executing leak primitives which write controlled data to known offsets within the buffer. In parallel, on another core, we execute the target instruction. Finally, we observe any overwritten bytes by comparing against the controlled data.
Intel SGX Exploitation
To demonstrate the security impact of the vulnerability we discovered, we implemented the first transient execution attack across CPU cores. Our attack can leak the output of the RDRAND and RDSEED instructions from the staging buffer, which together represent the only available source of randomness provided by the CPU for any Intel SGX secure enclave. In fact, we show that, with this capability, an attacker can leak the entire ECDSA private key of an Intel SGX enclave running on a separate CPU core after only one single signature operation.
Affected CPUs
Here is the list of the CPUs we tested in our experiments:
Mitigations
Intel has implemented its mitigation for the SRBDS vulnerability in a microcode update distributed to software vendors on Tuesday June 9, 2020 or earlier. The mitigation locks the entire memory bus before updating the staging buffer and only unlocks it after clearing its content. This strategy ensures no information is exposed to offcore requests issued from other CPU cores. Due to the considerable performance overhead of locking the entire system’s memory bus, Intel only applied the mitigation to harden a small number of security-critical instructions, specifically RDRAND, RDSEED, and EGETKEY (a leaf of the ENCLU instruction). This means that output from any other instruction (e.g., RDMSR) that issues offcore requests can be still leaked across CPU cores.
Disclosure
We disclosed an initial PoC (Proof-Of-Concept) showing the leakage of staging buffer content in September 2018, followed by a PoC implementing cross-core RDRAND/RDSEED leakage in July 2019. Following our reports, Intel acknowledged the vulnerabilities, rewarded CrossTalk with the Intel Bug Bounty (Side Channel) Program, and attributed the disclosure to our team with no other independent finders. Intel also requested an embargo until May 2020 (later extended), due to the difficulty of implementing a fix for the cross-core vulnerabilities identified in this paper. Intel describes our attack as “Special Register Buffer Data Sampling” or SRBDS (CVE-2020-0543), classifying it as a domain-bypass transient execution attack.
Update: On June 12th 2020 after disclosure (June 9th), Intel informed us that the Special Register Buffer Data Sampling issue had also been found by an internal Intel team. We would like to acknowledge the work done by Intel’s internal finders, Rodrigo Branco (formerly Intel), Kekai Hu (formerly Intel), Gabriel Negreira Barbosa (Intel), and Ke Sun (Intel).
PoC||GTFO
You can find a complete ready-to-run PoC here (see cpuid_leak and rdrand PoCs).
Paper
FAQs
If you’re using an Intel CPU, it’s quite likely. Intel’s higher-end server CPUs don’t appear to be vulnerable, and some of the very latest Intel CPUs aren’t vulnerable to MDS/TAA. You can find a list of the Intel CPUs we tested in Table 2 above.
We recommend installing Intel’s latest microcode, which includes the mitigation against SRBDS for RNG output and SGX keys. This is usually distributed through the standard software update mechanism.
Strictly speaking, in CVE parlance, yes. At the same time, the underlying issue stems from the original RIDL (aka MDS) class of vulnerabilities, except the source of leakage is now a previously undocumented (staging) buffer. Since the buffer is shared across CPU cores, the vulnerability enables cross-core transient execution attacks for the first time.
Yes. Our cross-core attack does not rely on SMT. In fact, as you can see in Table 2, our attack works on an Intel Xeon E3-1220V6 (Kaby Lake) CPU which does not support SMT at all.
In theory, yes. The underlying vulnerability enables cross-core leaks of some data – like RNG output – between arbitrary applications. However, Intel SGX enclaves are more amenable to practical exploitation, since attackers can easily slow down the execution of the victim and control the leakage. We expect practical exploitation beyond Intel SGX enclaves to be more difficult but not impossible.
The logo is free to use, rights waived via …. ah, no, wait, we don’t have a logo, but if you really insist you can grab one here.
We do not take long embargoes lightly, as we believe a short (ideally 90-day) vulnerability disclosure period is a good balance between giving vendors sufficient time to mitigate a vulnerability and informing the public early. Our original report (Sep 2018) only described same-core (CPUID) leaks and we did not discuss this PoC further with Intel until July 2019, when we reported that we had reproduced cross-core leaks for a number of instructions including RDRAND. Up to that point, we had not investigated thoroughly the implications of the attack (and, apparently, neither had Intel). We recognize the complexity of fixing bugs like this one, but as we made clear in the past, Intel should have fixed the MDS vulnerability – and dealt with our reported PoCs – properly from the outset, rather than play whac-a-mole with its symptoms.
Acknowledgements
This work was supported by the European Union’s Horizon 2020 research and innovation programme under grant agreements No. 786669 (ReAct) and No. 825377 (UNICORE), by Intel Corporation through the Side Channel Vulnerability ISRA, by the United States Office
of Naval Research (ONR) under contract N00014-17-1-2782, and by the Netherlands Organisation for Scientific Research through grants NWO 639.021.753 VENI ”PantaRhei”, and NWO 016.Veni.192.262. The public artifacts reflect only the authors’ view. The funding agencies are not responsible for any use that may be made of the information they contain.