Attacks on the newly-disclosed "MDS" hardware vulnerabilities in Intel CPUs
The RIDL and Fallout speculative execution attacks allow attackers to leak private data across arbitrary security boundaries on a victim system, for instance compromising data held in the cloud or leaking your data to malicious websites. Our attacks leak data by exploiting the 4 newly disclosed Microarchitectural Data Sampling (or MDS) side-channel vulnerabilities in Intel CPUs. Unlike existing attacks, our attacks can leak arbitrary in-flight data from CPU-internal buffers (Line Fill Buffers, Load Ports, Store Buffers), including data never stored in CPU caches. We show that existing defenses against speculative execution attacks are inadequate, and in some cases actually make things worse. Attackers can use our attacks to leak sensitive data despite mitigations, due to vulnerabilities deep inside Intel CPUs.
RIDL (Rogue In-Flight Data Load) shows attackers can exploit MDS vulnerabilities to mount practical attacks and leak sensitive data in real-world settings. By analyzing the impact on the CPU pipeline, we developed a variety of practical exploits leaking in-flight data from different internal CPU buffers (such as Line-Fill Buffers and Load Ports), used by the CPU while loading or storing data from memory.
Fallout demonstrates that attackers can leak data from Store Buffers, which are used every time a CPU pipeline needs to store any data. Making things worse, an unprivileged attacker can then later pick which data they leak from the CPU's Store Buffer.
We show that Fallout can be used to break Kernel Address Space Layout Randomization (KASLR), as well as to leak sensitive data written to memory by the operating system kernel.
Ironically, the recent hardware countermeasures introduced by Intel in recent Coffee Lake Refresh i9 CPUs to prevent Meltdown make them more vulnerable to Fallout, compared to older generation hardware.
We presented our paper titled Fallout: Leaking Data on Meltdown-resistant CPUs at the 26th ACM Conference on Computer and Communications Security, on November 13th 2019.
RIDL attacks were independently discovered and reported by:
Fallout attacks were independently discovered and reported by:
MDS-class vulnerabilities were also reported by (in alphabetical order):
Our attacks can leak confidential data across arbitrary security boundaries in real-world settings (cloud, browsers, etc.). The reason our attacks are impervious to all the existing defenses against speculative execution attacks is that they can leak in-flight data. Unlike other recent attacks such as Spectre, Meltdown, and Foreshadow which are based on vulnerabilities leaking data from the CPU caches, RIDL and Fallout collect data from internal CPU buffers (Line Fill Buffers, Load Ports, Store Buffers). Intel describes the exploited vulnerabilities as "Microarchitectural Data Sampling" (MDS) - where "sampling" is another way of saying that we can leak in-flight (or "sampled") data from many of these microarchitectural buffers. A total of 5 CVEs were assigned by Intel for RIDL ([MFBDS] CVE-2018-12130, [MLPDS] CVE-2018-12127, [MDSUM] CVE-2019-11091, [TAA] CVE-2019-11135) and Fallout ([MSBDS] CVE-2018-12126) exploits. Additional RIDL variants were later assigned 2 CVEs ([L1DES] CVE-2020-0549, [VRS] CVE-2020-0548).
Most importantly, our research shows that what last year appeared to be exceptional one-time speculative execution bugs are actually systemic, and the problems in modern CPUs may go much deeper than we initially thought. If CPUs have become so complex that chip vendors cannot keep their security under control, hardware vulnerabilities will be the new hunting ground for sophisticated attackers. And we may have no idea how many zero-day hardware vulnerabilities are still up for grabs. If we can no longer trust our hardware, the foundation on which we build all security solutions is crumbling away.
Click on the various components to interact with them. The full interactive version can be found here and the raw SVG can be found here. There is also a more vibrant colored version (the one used in our paper), which can be found here. These diagrams have been made by Stephan van Schaik ( @themadstephan).
Very likely. Our attacks affect all modern Intel CPUs in servers, desktops and laptops. This includes the latest 9th-generation processors, despite their in-silicon mitigations for Meltdown. Ironically, 9th-generation CPUs are more vulnerable to some of our attacks compared to older generation hardware.
Processors from other vendors (AMD and ARM) do not appear to be affected. Official statements from these vendors can be found in the RIDL and Fallout papers.
Multiple teams and researchers independently discovered, studied, and reported MDS-class vulnerabilities and attacks to Intel. Unfortunately, the different timelines (see below), as well as the fine-grained vulnerability classification and embargo strategy enforced by Intel (which coordinated the disclosure process) made proper coordination across teams difficult. The year-long disclosure process (the longest to date) ultimately resulted in independent finders of even closely related MDS-class vulnerabilities to be completely unaware of one another until very late in the process.
At the same time, VUSec would like to thank Intel for sharing the full list of finders in advance -- which was crucial to give proper credit to everyone involved in the disclosure of MDS vulnerabilities in academia and industry -- and for allowing it to share information with all the other academic finders as of May 1. We made an effort to coordinate the different academic finders and present a unified message to the community and the public.
Unfortunately, as some teams felt unable to share their findings before the May 14 disclosure date, this effort was only partially successful, resulting in the present website (mdsattacks.com) presenting only the two independent RIDL and Fallout papers. See the timeline below for more information.
MDS attacks exploit hardware security flaws deep inside the processor and this makes malware that exploit MDS vulnerabilities very hard to distinguish from benign software. While anti-virus software could theoretically detect MDS exploits, it is very unlikely to happen in practice.
Intel has provided CPU microcode updates, and recommendations for mitigation strategies for operating system (and hypervisor) software. See Intel's Security Advisory for more details. We recommend you install the software updates provided by your operating system and/or hypervisor vendor.
In addition, we recommend disabling Simultaneous Multi-Threading (SMT), also known as Intel® Hyper-Threading Technology, which significantly reduces the impact of MDS-based attacks without the cost of more complex mitigations. Note that you might still be vulnerable despite disabling SMT, as MDS does not strictly rely on the presence of SMT.
A Virtual Machine (VM for short) is a software emulation of the computer's physical hardware. VMs are often used by clouds to allow customers to rent time on the cloud's physical hardware, rather than maintaining their own infrastructure. As clouds often run multiple VMs from different clients on the same physical hardware, it is important that cloud vendors maintain isolation between VM (security) boundaries.
To guarantee even stronger isolation (e.g., with protection against a compromised operating system), cloud providers can also run software inside secure (SGX) enclaves.
As shown in the RIDL paper, an attacker can exploit hardware security vulnerabilities inside the processor to break VM and SGX boundaries. However, countermeasures deployed by cloud providers resulting from our work should make MDS hard to exploit.
The kernel is the operating system core, and as such is responsible for most operations performed by the operating system. In particular, the kernel has access to all the data stored in the machine's memory, and to the secrets in it. As such, it is vital to properly isolate the kernel from other applications running on the machine.
Both the RIDL and Fallout attacks violate the kernel privacy by extracting information from within it. Moreover, both attacks can expose the kernel's location in the system's memory, simplifying other exploits.
RIDL and Fallout are related to, and inspired by, previous speculative execution attacks, including Spectre and Meltdown. In contrast to previous attacks, MDS attacks do not need to make assumptions about the memory layout of the victim data and do not depend on the processor cache.
This makes our attacks very difficult to mitigate. For instance, RIDL's ability to observe data used by other code running on the same physical core (hyperthread) is not trivial to mitigate without disabling the hyperthreading functionality entirely. However, note that both RIDL and Fallout can read recently accessed data across security boundaries even if hyperthreading is disabled.
A detailed analysis of the many existing speculative execution vulnerabilities, their relationship to each other and to RIDL and Fallout, can be found in the RIDL and Fallout papers.
Detailed information about these in-flight buffers can be found in the papers above.
As a quick preview, the first diagram below shows the relevant parts of Intel's CPU pipeline and the relationship to the Line Fill Buffers, Load Ports, and Store Buffers used by our attacks. All data read/written from/to memory goes through some of these buffers.
The second diagram shows an example of how we leak data from these buffers. We perform a carefully crafted speculative load to an address the CPU is not immediately prepared to handle (e.g., resulting in a page fault). This lures the CPU into incorrectly pulling in-flight data from the target buffers, and then similarly to other speculative execution attacks, we leak this data using a Flush+Reload attack before the CPU realizes the mistake.
While performing some experiments on a rainy Amsterdam day, we realized we were able to leak data across security boundaries. We knew we could leak arbitrary in-flight (the "I" in RIDL) data but the cause was initially a big riddle to us. We came to know we were leaking from various CPU buffers only later...
It is also a reference to Intel's formal name for Meltdown: RCDL (related to RIDL, but instead leaking "C"ached data).
Internally, we referred to RIDL (and MDS in general) as the `cat pictures' vulnerability. :)
We started working on Fallout immediately after Meltdown, and Fallouts are typically a direct consequence of Meltdowns.
The following is the fine-grained vulnerability classification adopted by Intel, together with their CVSS score (their rating of the severity of the bug):
CVE-2018-12126: "Microarchitectural Store Buffer Data Sampling (MSBDS)" (CVSS score 6.5: Medium). See the Fallout paper for more information.
CVE-2018-12127: "Microarchitectural Load Port Data Sampling (MLPDS)" (CVSS score 6.5: Medium). See the RIDL paper for more information.
CVE-2018-12130: "Microarchitectural Fill Buffer Data Sampling (MFBDS)" (CVSS score 6.5: Medium). See the RIDL paper for more information.
CVE-2019-11091: "Microarchitectural Data Sampling Uncacheable Memory (MDSUM)" (CVSS score 3.8: Low). See the RIDL paper for more information.
CVE-2019-11135: "TSX Asynchronous Abort (TAA)" (CVSS score 6.5: Medium). See the RIDL paper (with addenda) for more information.
CVE-2020-0549: "L1D Eviction Sampling (L1DES)" (CVSS score 6.5: Medium). See the RIDL paper (with addenda) for more information.
CVE-2020-0548: "Vector Register Sampling (VRS)" (CVSS score 2.8: Low). See the RIDL paper (with addenda) for more information.
CVE-2020-0550: "Snoop-assisted L1 Data Sampling (Snoop)" (CVSS score 5.6: Medium). See Intel's Deep Dive for more information.
CVE-2020-0543: "Special Register Buffer Data Sampling (SRBDS)" (CVSS score 6.5: Medium). See the CrossTalk project page for more information.
Not really. And some of the researchers do share your same feelings.
VUSec in particular doesn't really like vulnerability logos. But we do like beer. So here is a MDS-branded one just in case (and yes, VUSec students like to troll their supervisors, who take a hard stance against vulnerability logos...):
Kaveh Razavi will do the first public presentation of RIDL at the 1st AMSEC Workshop: Security in Diversity on May 15th at 14:15. Registration is free!
We presented our paper on RIDL at the 40th IEEE Symposium on Security and Privacy, on May 20th 2019 (Session #1: Hardware Security). Here is a video of the talk:
On Jan 27, 2020, we (VUSec) disclose two "new" RIDL/MDS variants at the end of another (third) embargo, as described in our second RIDL addendum. We do not think either of these variants is particularly novel or interesting and they are simply "more RIDL" (focusing on ways to get data into microarchitectural buffers RIDL can leak from).
The first issue, which Intel refers to as L1D Eviction Sampling (L1DES), is a RIDL variant that leaks from L1D evictions (assigned CVE-2020-0549). It may seem that sometimes history does repeat itself, because this is again something that we had already shown in our original RIDL paper, as shown in Figure 6. In the camera-ready version of the RIDL paper, we also explicitly mentioned that, at every context switch, "the entire L1 cache needs to be flushed first since the entries go through the LFBs" to properly mitigate RIDL. We removed this sentence in the original version of the RIDL paper released on May 14, 2019, since Intel had not yet mitigated the RIDL variant based on L1D evictions (which would eventually become L1DES). Since then, we spent months trying to convince Intel that leaks from L1D evictions were possible and needed to be addressed.
On Oct 25, 2019, we reported to Intel that this variant would bypass their latest VERW mitigation (and so did a PoC shared with Intel on May 10, 2019), resulting in Intel finally acknowledging the L1D eviction issue and requesting another (L1DES) embargo. We learned that Intel had not found this issue internally and that the only other independent finder was the Zombieload team, which reported a PoC to Intel in May, 2019. The CacheOut team did an independent security analysis of L1DES. Our RIDL-L1DES PoC is available on GitHub.
The second issue, which Intel refers to as Vector Register Sampling (VRS), is a RIDL variant that leaks from vector registers (assigned CVE-2020-0548). This variant shows that RIDL can also leak values that are never even stored in memory. In reality, this is possible with a small, 1-line of code variation of our 'alignment write' PoC (originally leaking values stored in memory using alignment faults), which we shared with Intel on May 11, 2019. Since then, we spent months trying to convince Intel that our 'alignment write' PoC and its variations needed to be properly addressed.
On Oct 1, 2019, we reported to Intel that a 1-line modification of our 'alignment write' PoC can leak vector register values, resulting in Intel requesting a new (VRS) embargo. We are not aware of other independent finders to acknowledge for VRS. Our RIDL-VRS PoC is available on GitHub.
Meanwhile, our students have been playing with RIDL last year. As shown below, one of our bright students, Finn de Ridder, built a new RIDL-TAA exploit that can leak the entire root hash password in only 4 seconds (!!!).
On Nov 12, 2019, we (VUSec) disclosed TSX Asynchronous
Abort (TAA), a
new speculation-based vulnerability in Intel CPUs as well as other MDS-related issues, as described in our first RIDL addendum.
In reality, this is no new vulnerability.
We disclosed TAA (and other issues) as part of our original RIDL
submission to Intel in Sep 2018. Unfortunately, the Intel PSIRT
team missed our submitted proof-of-concept exploits (PoCs), and
as a result, the original MDS mitigations released in May 2019
only partially addressed RIDL.
You can read the full story below.
In particular, at the request of Intel, we withheld the following details on the original RIDL/MDS disclosure date:
clearthe buffers by writing stale, potentially sensitive, data into these buffers, allowing an attacker to leak information despite mitigations being enabled.
TL;DR: an attacker can mount a RIDL attack despite the in-silicon mitigations/microcode patches published in May 2019 being in place.
In particular, TSX Asynchronous Abort (TAA) allowed us to mount a practical RIDL exploit (as already shown in /etc/shadow leak presented in the RIDL paper) even on systems with in-silicon/microcode MDS mitigations enabled. Moreover, one of our brilliant Master students (Jonas Theis) used TAA to optimize our initial password-disclosing exploit to run in just 30 seconds (!!), rather than the initial 24 hours (as seen in the video below).
In short, this was part of our original RIDL submission but was missed by Intel during the first embargo and a new last-minute embargo followed. Check out the updated timeline at the end of the page or keep reading for the full story.
On Sep 29, 2018, we submitted several proof-of-concept exploits (PoCs) for a number of RIDL variants to Intel. Despite our many attempts, we received no technical feedback/questions on our submission except that Intel was working on the mitigations.
In fact, due to a lack of transparency on Intel's part, we only got a complete picture on Intel's MDS disclosure plan on May 10, 2019, just 4 days before public disclosure. We were able to find the microcode updates published by Intel online and tested them on the same day. We quickly found that Intel's fixes did not fully mitigate the vulnerabilities we had reported in Sep 2018 and immediately informed Intel.
On May 13, 2019, just one day from the RIDL/MDS public disclosure date,
Intel requested TAA and any other RIDL issues that were not mentioned in the MDS
whitepaper to be placed under a new last-minute embargo until Nov 12, 2019. At the request of Intel, and to protect users,
we complied to the new embargo, withheld several details
from the RIDL paper (leaving only some
traces of our results in Table I), and
did not release our now public RIDL test suite.
On July 3, 2019, we finally learned that, to our surprise, the Intel PSIRT team had missed the PoCs from our Sep 29 submission, despite having awarded a bounty for it, explaining why Intel had failed to address - or even publicly acknowledge - many RIDL-class vulnerabilities on May 14, 2019.
On Oct 15, 2019, we learned that Intel had not found this issue internally and the only other independent finder was the Zombieload team, which disclosed TAA to Intel in April, 2019. The MEDUSA team later published an independent analysis using TAA.
On Oct 25, 2019, we tested Intel's latest microcode update, and still saw leaks with the VERW mitigation enabled, using the RIDL PoCs we shared with Intel in May 2019. We notified Intel and shared a polished PoC to make the issue clear. Intel requested a new embargo and yet suggested adding the following to our first RIDL addendum: "A new microcode update release by Intel in November is required to adequately address the issue".
On Nov 12, 2019, TAA and the other scheduled RIDL issues are disclosed. Unfortunately, we believe that, given the piecemeal (variant-by-variant) mitigation approach pursued by Intel, RIDL-class vulnerabilities won't disappear any time soon.
We are particularly worried about Intel's mitigation plan being PoC-oriented with a complete lack of security engineering and underlying root cause analysis, with minor variations in PoCs leading to new embargoes, and these "new" vulnerabilities remaining unfixed for lengthy periods. Unfortunately, until there is sufficient public / industry pressure, there seems to be little incentive for Intel to change course, leaving the public with a false sense of security. Slapping a year-long embargo after another (many news cycles apart) and keeping vulnerabilities (too) many people are aware of from the public for a long time is still a viable strategy.
Based on the information shared with us by Intel and other finders.
The finders would also like to acknowledge all the other authors on the Fallout paper.
The RIDL work at VUSec was supported by the European Union's Horizon 2020 research and innovation programme under grant agreements No. 786669 (ReAct) and No. 825377 (UNICORE), by the United States Office of Naval Research (ONR) under contracts N00014-17-1-2782 and N00014-17-S-B010 "BinRec", by Intel Corporation through the Side Channel Vulnerability ISRA, and by the Netherlands Organisation for Scientific Research through grants NWO 639.023.309 VICI "Dowsing", 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.