Leaking Data on Intel CPUs via Cache Evictions

We present CacheOut, a new speculative execution attack that is capable of leaking data from Intel CPUs across many security boundaries. We show that despite Intel's attempts to address previous generations of speculative execution attacks, CPUs are still vulnerable, allowing attackers to exploit these vulnerabilities to leak sensitive data.

Moreover, unlike previous MDS issues, we show in our work how an attacker can exploit the CPU's caching mechanisms to select what data to leak, as opposed to waiting for the data to be available. Finally, we empirically demonstrate that CacheOut can violate nearly every hardware-based security domain, leaking data from the OS kernel, co-resident virtual machines, and even SGX enclaves.

Read the Paper Cite


Questions & Answers

Probably yes, unless you happen to have a CPU released after Q4 2018.

For a select number of processors released after Q4 2018, Intel inadvertently managed to partially mitigate this issue while addressing a previous issue called TSX Asynchronous Abort (TAA). See Section 9 in our our paper.

A list of affected products can be found here.

Intel has provided CPU microcode updates, along with recommendations for mitigation strategies for operating system (and hypervisor) software. More information can be found at Intel's Software Guidance on L1D Eviction Sampling and Intel's Security Advisory (SA-00329). We recommend that you install the software updates provided by your operating system and/or hypervisor vendor.

The first indication known to us of leakage from cache evictions can be seen in the Rogue In-Flight Data Load (RIDL) paper, authored by Stephan van Schaik, Alyssa Milburn, Sebastian Ă–sterlund, Pietro Frigo, Kaveh Razavi, Herbert Bos and Cristiano Giuffrida (VUSec). In addition, Intel also informed us that Moritz Lipp, Michael Schwarz, and Daniel Gruss (TU Graz), as well as Jo Van Bulck (KU Leuven) also reported this issue.

Stephan van Schaik, Marina Minkin, Andrew Kwong, Daniel Genkin (University of Michigan), and Yuval Yarom (University of Adelaide and Data61) performed an extensive analysis of how this vulnerability works and how an attacker can exploit it. More information can be found in our paper.

AMD is not affected by CacheOut, as AMD does not offer any feature akin to Intel TSX on their current offering of CPUs.

Arm and IBM do have a feature similar to Intel TSX, but we are currently unaware of whether any of their products are affected. We are also unaware of any other attack vectors to exploit CacheOut.

No, these are bugs in the processor that an attacker can exploit. Software can mitigate these issues at the cost of features and/or performance. We hope that somewhere in the future Intel will release processors with in-silicon fixes against this issue.

While it is possible in theory, this is currently unlikely in practice. However, your anti-virus software may detect malware which uses this attack by comparing binaries once they become known.

Very unlikely. CacheOut does not leave any traces in traditional log files.

As far as we know, there are no known instances of malicious actors abusing CacheOut in the wild.

An operating system (OS) is system software responsible for managing your computer hardware by abstracting it through a common interface, which can be used by the software running on top of it. Furthermore, the operating system decides how this hardware is shared by your software, and as such has access to all the data stored in your computer's memory. Thus, it is essential to isolate the operating system from the other programs running on the machine.

CacheOut violates the operating system's privacy by extracting information from it that facilitates other attacks, such as buffer overflow attacks.

More specifically, modern operating systems employ Kernel Address Space Layout Randomization (KASLR) and stack canaries. KASLR randomizes the location of the data structures and code used by the operating system, such that the location is unknown to an attacker. Stack canaries put secret values on the stack to detect whether an attacker has tampered with the stack. CacheOut extracts this information from the operating system, essentially enabling full exploitation via other software attacks, such such as buffer overflow attacks.

CacheOut can leak information from other processes running on the same thread, or across threads on the same CPU core. As an example, we successfully leaked both the decrypted output and the AES key from another process performing AES decryptions.

Virtualization is a feature supported by modern CPUs that enables software emulation of the computer's physical hardware. This essentially allows you to instantiate multiple computers (called virtual machines), each running their own operating system and software, all while sharing the same underlying physical hardware.

Cloud providers use virtualization to partition and isolate physical hardware, such that customers can rent the hardware instead of having to purchase, set up, and maintain their own infrastructure. As many cloud instances share the same physical hardware, it is essential that cloud vendors maintain isolation between these instances.

CacheOut exploits hardware security vulnerabilities inside the processor to leak information from both the virtual machine manager (hypervisor) and co-resident virtual machines. However, cloud providers have already deployed countermeasures against CacheOut as a result from our work.

Intel Security Guard Extensions (SGX) offer an even stronger isolation guarantee that allows third parties to run their software in secure enclaves, with protection against a compromised operating system and/or hypervisor.

CacheOut exploits the hardware vulnerabilities we uncovered to dump the contents of SGX enclaves. As such, any information stored inside the enclave can be potentially leaked by CacheOut.

No, CacheOut cannot be exploited from a web browser, as web browsers currently don't expose the Intel TSX functionality to JavaScript.

CacheOut is related to, and inspired by, previous work in speculative execution, including Spectre and Meltdown. Moreover, CacheOut bypasses the hardware mitigations released by Intel in response to Meltdown, thereby necessitating additional software fixes.

Microarchitectural Data Sampling (MDS) shows that an attacker can sample in-flight data from various microarchitectural buffers. As a response to this, Intel recommends that operating system vendors overwrite the contents of these buffers. However, CacheOut demonstrates that this mitigation is incomplete, as we can force the victim's data out of the L1-D Cache into the microarchitectural buffers after the operating system clears them. We then subsequently leak the contents of the buffers and obtain the victim's data.

The main idea behind our attack is to force the victim's data out of the CPUs cache into a leaky buffer, and then subsequently leak it. Cache and cash also happen to be homophones, which means that CacheOut sounds the same as "cash out". This also explains our use of the dollar signs in the logo.

Intel assigned CVE-2020-0549: "L1D Eviction Sampling (L1Des) Leakage" with a CVSS score 6.5 Medium to this vulnerability.

Yes, with rights waived via CC0. Logos are designed by Marina Minkin. Click here for the logo in SVG format and here for the logo in PNG format.

For questions about CacheOut in general, you can reach us via


We would like to thank Intel for working with us during the responsible disclosure.

This research was supported by the Defense Advanced Research Projects Agency (DARPA) and Air Force Research Laboratory (AFRL) under contract FA8750-19-C0531, by an Australian Research Council Discovery Early Career Researcher Award (project number DE200101577), and by generous gifts from Intel and AMD.