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.
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.
As such, existing attacks require the attacker and the victim to share the same CPU core in order to exploit the on-core shared internal resources and be able to leak the victim’s secret data within the same or different per-core hardware threads. This constraint has consolidated the belief that isolating (spatially or temporally) different security domains on their own cores would prevent all these attacks. A variety of existing mitigations explicitly build on this assumption.
For instance, to counter the recent RIDL attacks, an option is to disable Simultaneous MultiThreading (SMT)—allowing only a single hardware thread per CPU core—and flush microarchitectural buffer at security domain switch within the same hardware thread. A less expensive alternative to disabling SMT is to deploy secure scheduling policies which only allow a single security domain per CPU CORE. Unfortunately, albeit already costly, these mitigations cannot stop cross-core transient execution attacks. With CrossTalk, we show that such attacks are possible and that the attack surface is thus larger than previously assumed.
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.
Since different instructions write to different offsets in the staging buffer, attackers can craft instructions so as to leak all the information they want. In particular, CrossTalk’s instruction profiling stage uses the fact that the instructions write to different offsets within the staging buffer to automatically discover how information leaks between instructions. As output, it produces a number of instructions, capable of leaking the entire staging buffer including any offcore information requested from other instructions that are executed on different cores in the system.
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.
Our profiler helped us find staging buffer leaks for a number of vulnerable instructions (Table 1). Among others, RDRAND and RDSEED are of particular (security) interest, since their output includes random numbers returned by the offcore hardware DRNG.
Intel SGX Exploitation
Intel Software Guard Extensions (SGX) is a hardware extension introduced in 2015 with the Intel Skylake microarchitecture. SGX provides a set of instructions to allow unprivileged user programs to create and manage encrypted memory regions called secure enclaves, allowing sensitive data (such as encryption keys) to be protected from potentially compromised operating systems and hypervisors.
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.
Here is the list of the CPUs we tested in our experiments:
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.
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).
You can find a complete ready-to-run PoC here (see cpuid_leak and rdrand PoCs).
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.
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.