PaperlayerView exact revision on arXiv

Source-linked AI summary

CacheOut: Leaking Data on Intel CPUs via Cache Evictions

Stephan van Schaik, Marina Minkin, Andrew Kwong, Daniel Genkin, Yuval Yarom

arXiv:2006.13353v1cs.CR

TL;DR

MDS attacks leak data from CPU buffers, while Intel’s buffer-overwrite countermeasures leave open whether residual leakage can be prevented. CacheOut actively evicts selected L1-D data into leaky buffers, bypassing those countermeasures and leaking across processes, VMs, kernels, hypervisors, and SGX enclaves, including on Whiskey Lake.

  • Problem

    The paper asks whether buffer overwrites and Whiskey Lake’s hardware defenses are sufficient to block MDS-type attacks.

  • Method

    CacheOut forces selected data from the L1-D cache into line fill buffers and recovers it with transient-execution loads after buffer overwrites.

  • Results

    CacheOut leaks across process, kernel, VM, hypervisor, and SGX boundaries, including from fully updated MDS-resistant Whiskey Lake CPUs.

  • Takeaways & Limitations

    Buffer overwrites alone do not prevent CacheOut because evicted L1-D data can re-enter the leaky buffers after the overwrite.

Abstract

from arXiv · show

Recent transient-execution attacks, such as RIDL, Fallout, and ZombieLoad, demonstrated that attackers can leak information while it transits through microarchitectural buffers. Named Microarchitectural Data Sampling (MDS) by Intel, these attacks are likened to "drinking from the firehose", as the attacker has little control over what data is observed and from what origin. Unable to prevent the buffers from leaking, Intel issued countermeasures via microcode updates that overwrite the buffers when the CPU changes security domains. In this work we present CacheOut, a new microarchitectural attack that is capable of bypassing Intel's buffer overwrite countermeasures. We observe that as data is being evicted from the CPU's L1 cache, it is often transferred back to the leaky CPU buffers where it can be recovered by the attacker. CacheOut improves over previous MDS attacks by allowing the attacker to choose which data to leak from the CPU's L1 cache, as well as which part of a cache line to leak. We demonstrate that CacheOut can leak information across multiple security boundaries, including those between processes, virtual machines, user and kernel space, and from SGX enclaves.

I. INTRODUCTION

CacheOut bypasses Intel’s buffer-overwrite defenses by moving evicted L1-D data into leaky CPU buffers, enabling controlled leakage across major security boundaries. The attack works even against MDS-resistant Whiskey Lake CPUs and without hyper-threading.

  • A. Our Contribution: CacheOut bypasses buffer-overwrite countermeasures and selectively leaks data from the CPU’s L1-D cache.It exploits data re-entering microarchitectural buffers after security-domain transitions.
  • A. Our Contribution: CacheOut forces L1-D evictions into the line fill buffers, then recovers the evicted data with faulting or assisting loads.This undocumented path lets the attacker target cache contents rather than passively sample buffer traffic.
  • A. Our Contribution: CacheOut can dump entire 4 KiB victim pages by targeting all 64 L1-D cache sets and retaining the relative positions of leaked data.This improves on prior MDS attacks that lacked corresponding data locations and often accessed only part of each cache line.
  • A. Our Contribution: CacheOut remains effective without hyper-threading because Intel’s verw instruction flushes internal buffers but not the L1 cache.The attacker can evict victim data after the buffer flush and recover it in a time-shared environment.
  • A. Our Contribution: CacheOut leaks across process, kernel, virtual-machine, hypervisor, and SGX boundaries, including AES, RSA, enclave, and attestation-related secrets.Demonstrations include kernel ASLR derandomization, stack-canary recovery, VM isolation violations, and enclave extraction.
  • A. Our Contribution: The work reports that some recent Intel CPUs remain vulnerable despite current patches, including the MDS-resistant Whiskey Lake architecture.The authors describe CacheOut as the first transient-execution attack to break Whiskey Lake’s stated MDS resistance.

B. Current Status and Disclosure

The disclosure identifies CacheOut as L1 Data Eviction Sampling and records Intel’s acknowledgment of the issue. The authors recommend installing forthcoming microcode updates on affected platforms.

  • B. Current Status and Disclosure: Intel acknowledged the reported issue as CVE-2020-0549, naming it L1 Data Eviction Sampling with a CVSS score of 6.5.The issue was independently reported by researchers from TU Graz and KU Leuven.
  • B. Current Status and Disclosure: Most deployed Intel hardware predates Q4 2018 and remains vulnerable to all CacheOut variants when TSX is enabled by default.The authors state that microcode updates addressing the root cause were expected on June 9, 2020.
  • B. Current Status and Disclosure: The authors recommend installing Intel’s mitigating microcode updates on all affected Intel platforms.This recommendation is tied to the planned updates for the root cause of CacheOut.

II. BACKGROUND

The background introduces caches as latency-hiding storage and explains how cache attacks infer victim activity through shared cache structures. Figure 1 distinguishes load, store, and newly identified data paths.

  • A. Caches: The L1-D cache stores data used by a program, with one L1-D cache typically located in each processor core.Caches exploit locality by retaining frequently and recently used data.
  • A. Caches: Figure 1 marks load paths in blue, the store path in orange, and the newly uncovered path in red.The color coding highlights the path central to CacheOut’s mechanism.
  • A. Caches: FLUSH+RELOAD uses shared memory and cache-line reload timing to determine whether another process accessed a line.A fast reload indicates that another process brought the line back into the cache.
  • A. Caches: PRIME+PROBE works without shared memory by filling an eviction set and measuring access-time changes caused by another process.Its granularity is the cache set rather than an individual shared cache line.

B. Microarchitectural Buffers

CacheOut exploits an undocumented path from L1-D evictions to line fill buffers, turning controlled cache eviction into targeted transient-execution leakage. This addresses limitations of earlier MDS attacks in control, rate, and location.

  • B. Microarchitectural Buffers: Line fill buffers transfer data between the L1-D cache, L2 cache, and core while supporting non-blocking L1-D cache misses.They handle retrieval from lower memory levels when a cache miss occurs.
  • B. Microarchitectural Buffers: An undocumented path moves data evicted from L1-D into the line fill buffers, where CacheOut recovers it using faulting or assisting loads.The path persists on MDS-resistant Whiskey Lake machines and moves data after verw overwrites the buffers.
  • B. Microarchitectural Buffers: Earlier MDS attacks leaked data transiting internal buffers but generally lacked control over which data or offsets were sampled.RIDL and ZombieLoad relied on statistical or averaging techniques to process noisy leakage.
  • B. Microarchitectural Buffers: CacheOut improves on Medusa by recovering leakage beyond write combining and controlling offsets within the leaked data.Medusa reported 12 B/s for kernel data and required Domino-byte signal averaging.
  • B. Microarchitectural Buffers: CacheOut peaks at approximately 2.85 KiB/s, exceeding ZombieLoad’s reported 0.1 B/s leakage estimate.Cache evictions let the attacker actively select the information to leak and avoid noise averaging.

F. TSX Asynchronous Abort

TSX Asynchronous Abort (TAA) exploits transactional abort behavior to sample data from line fill buffers, while Intel and operating systems deploy hardware and software countermeasures against transient-execution leakage. The threat model assumes an unprivileged attacker targeting a fully patched Intel system with TSX RTM enabled.

  • TSX Asynchronous Abort: TAA exploits cache-line flushing and transactional aborts to allocate a line fill buffer before the transaction terminates.The attack uses clflush before a transaction that loads the flushed line; the resulting abort creates the transient execution opportunity.
  • CPU Mitigations: Intel countermeasures include in-silicon protections and software defenses such as KPTI and verw-based MDS-buffer flushing.Operating systems issue verw on security-domain changes to overwrite leaking microarchitectural buffers on older hardware.
  • Threat Model: The attacker is modeled as an unprivileged user or virtual machine confronting a fully patched Intel system without software vulnerabilities.The assumptions also require TSX RTM to be present and enabled.

IV. CACHEOUT: EXPLOITING CACHE EVICTIONS

CacheOut exploits L1-D cache evictions to move victim data into leaky line fill buffers, where TAA samples it despite buffer-flushing defenses. Eviction-set experiments show controllable cache-set targeting, with performance depending on eviction-set size and execution placement.

  • Attack Overview: CacheOut forces L1-D contention so evicted victim data transits through line fill buffers and can be recovered with TAA and FLUSH+RELOAD.It handles both victim-modified data written back to memory and unmodified data first evicted by the attacker.
  • Measuring L1-D Eviction: Eight-address eviction sets recover the victim’s cache-line contents in 4.8% of same-hyper-thread cases.The experiment varies eviction-set sizes and evaluates time-sharing on one hyper-thread, cross-hyper-thread reads, and cross-hyper-thread writes.
  • Measuring L1-D Eviction: Smaller eviction sets may fail under LRU replacement, whereas larger sets increase noise through cache pressure.The authors present this as a conjecture explaining the observed decline for both smaller and larger sets.
  • Selecting Cache Sets: CacheOut targets selected cache sets across victim reads and writes, although cross-hyper-thread results are weaker and write attacks are noisier.An eviction set of eight works best for reads, while six works best for writes; the authors attribute this to increased L1-D contention across hyper-threads.

B. Selecting Cache Line Offsets

CacheOut extends TAA by controlling which byte offset within a cache line is leaked, overcoming TAA’s restriction to the first 8 bytes. Parallel loads and overlapping two-byte samples improve signal strength and data stitching.

  • Selecting Cache Line Offsets: TAA previously reached only the first 8 bytes of each 64-byte cache line, while CacheOut controls the leaked offset using later load instructions.The added movq instructions can execute out of order and influence the line fill buffer’s read offset.
  • Reducing Noise and Data Stitching: Parallel load-port execution doubles the signal when both loads target the same offset.The attack duplicates and interleaves the leakage instructions to execute two loads in parallel.
  • Reducing Noise and Data Stitching: The attack stitches data from two consecutive leaked bytes using an overlapping byte between adjacent iterations.This replaces the prior Domino approach of sampling one byte at a time and using four bits from each byte.
  • Evaluating Offset Selection: CacheOut successfully selects the victim’s secret byte offset across possible positions within a cache line.The evaluation writes a secret at one offset, zeros the remaining bytes, and tests leakage from every attacker-selected offset.
  • Evaluating Leakage Amount: Leakage peaks at 2.85 KiB/s for reads and 2.38 KiB/s for writes.The rate measures correct-value recovery over repeated victim writes and exceeds the cited ZombieLoad rate.

C. Determining the Leakage Source

CacheOut experiments identify the L1-D eviction path into the line fill buffers as the source of leakage, while showing that Intel’s buffer-overwrite defense can be abused rather than preventing leakage.

  • Flushing the MDS Buffers: Flushing the MDS buffers after cache eviction completely removes the signal, implicating an MDS buffer in CacheOut’s leakage path.The experiment concludes that evicted data reaches a leaky buffer before the leakage primitive reads it.
  • Flushing the MDS Buffers: Moving verw before eviction preserves leakage from victim-modified cache lines but removes leakage from victim reads, supporting transfer through the LFB during write-back.
  • Exploiting verw: Issuing verw before eviction significantly improves the signal for victim writes in both cross-thread and same-thread scenarios.Because verw does not require root privileges, the countermeasure can be used as part of the attack.
  • Cross-Process Implications: CacheOut demonstrates confidential-data recovery across processes, including AES keys, RSA keys, and neural-network weights, while improving control over leak location.The attack selects locations in the victim’s address space instead of waiting for arbitrary data in the LFB.

A. Recovering AES Keys

CacheOut recovers AES plaintext and key material by evicting data from the victim’s L1-D cache and sampling it through TAA, including cross-thread recovery without scheduler synchronization.

  • Same-Thread Leakage: The attacker evicts the victim’s decrypted data from the L1-D cache into the LFB and then uses TAA to sample it.In the same-thread setup, victim and attacker coordinate through sched_yield().
  • Cross-Thread Leakage: Cross-thread leakage recovers the decrypted plaintext, AES key, and expanded round keys without requiring sched_yield() or a victim write into the key’s cache line.Address selection distinguishes consecutively laid-out initial and round keys.
  • Cross-Thread Leakage: 76.2 seconds on average, 8.90KiB/s raw throughput, and 63.39B/s actual throughput characterize the cross-thread sampling attack.The attack samples all 64 cache lines during its online phase.
  • Locating AES Keys: 98.34% of the AES key and round keys are observed, with the initial key appearing at three 128-bit locations and two 256-bit locations.The repeated locations provide additional redundancy for locating the key.
  • Related Key-Recovery Setup: CacheOut gathers 100% of RSA key data for 512-bit through 4096-bit keys, using one cache line for keys up to 2048 bits and four for 4096-bit keys.
  • Related Key-Recovery Setup: RSA private-key reconstruction takes 0.3s, 0.3s, 3.5s, and 82.8s on average for 512-bit, 1024-bit, 2048-bit, and 4096-bit keys, respectively.The worst-case reconstruction time is 186s, and recovery is confirmed using the corresponding public key.

C. Attacking Neural Networks

The supplied passages do not provide neural-network weight-recovery results; they instead describe CacheOut’s broader kernel targets and L1-D eviction measurements.

  • Attacking Neural Networks: The supplied experiment passage introduces stealing weights from an artificial neural network but does not report the recovery outcome.
  • Kernel Targets: CacheOut leaks kernel data without hyper-threading, including kernel function pointers for KASLR and secret kernel stack canaries.
  • Eviction Measurements: Figure 8 measures the loads or stores needed to evict L1-D cache sets for hypervisor and cross-VM targets.

VII. BREAKING VIRTUALIZATION

CacheOut breaks virtualization isolation by selecting and evicting L1-D cache sets to leak data from hypervisors and co-resident virtual machines on the same physical core.

  • Virtual-Machine Isolation: CacheOut selects and evicts any L1-D cache set to leak secrets from either the hypervisor or a co-resident victim VM.The experiment writes secrets to every possible cache set and probes every possible cache set from the attacker VM.
  • Cross-VM AES Leakage: The cross-VM AES experiment evicts a targeted cache set, then uses TAA to sample the victim’s AES key from the line fill buffer.
  • Cross-VM AES Leakage: 20 of 10,000 attempts observed each victim AES-key byte, and baseline subtraction recovered 75% of the key.The result was obtained across three experimental runs.
  • Cross-VM RSA Leakage: Across VMs, CacheOut observes 100% of the RSA p and q chunks from sampled data.
  • Cross-VM Neural-Network Leakage: The cross-VM neural-network experiment observes 99.90% of the weights, with an average runtime of 376.69s.The attack uses 5,000 iterations for each targeted location.
  • Hypervisor ASLR: CacheOut identifies static hypervisor-pointer locations after an offline phase, enabling a subsequent online hypervisor-ASLR attack.

VIII. BREACHING SGX ENCLAVES

CacheOut breaches SGX confidentiality by forcing enclave data into the L1-D cache and recovering selected data despite Whiskey Lake’s MDS mitigations. The attacks recover both images and enclave keys, while the authors note an experimental limitation for production enclaves.

  • Attack construction: CacheOut forces victim enclave data into the L1-D cache using SGX paging operations, then repeatedly extracts selected plaintext from cached pages.The attack uses ewb and eldu to load enclave data into the cache and improves recovery by forcing multiple plaintext copies into it.
  • Image recovery: CacheOut reconstructs an unstructured Mona Lisa image from an SGX enclave, with offline reconstruction taking 8.39 seconds.Candidate pixel values are ranked using neighboring pixels before selecting the output image.
  • Key recovery: The attack extracts a 16-byte EPID sealing key despite noise, then brute-forces 747K candidates in 5 seconds using AES-GCM authentication tags.Key extraction takes about 1.5 minutes and yields an average of 4.5 candidates per key byte.
  • Software defenses: CacheOut requires hardware mitigation because enclave software cannot protect secrets once they are loaded into memory, bypassing existing software side-channel defenses.The authors state that the victim need not execute a specific access pattern or continue running after loading the key.
  • Experimental boundary: The demonstrated production-enclave attack used a self-compiled, self-signed quoting enclave and therefore could not access the machine’s actual attestation keys.The authors attribute this boundary to an internal-GPU issue that prevented the Whiskey Lake machine from receiving trusted SGX status and production attestation keys.

IX. MITIGATIONS

The paper discusses disabling hyper-threading, flushing the L1-D cache, disabling TSX, and applying Intel microcode updates as CacheOut mitigations. It emphasizes that hyper-threading alone is insufficient because CacheOut also works when attacker and victim execute sequentially.

  • Disabling hyper-threading: Disabling hyper-threading does not fully prevent CacheOut because the attack also works when attacker and victim run sequentially on the same CPU.The attack works best with parallel threads on one physical core, but remains effective without hyper-threading.
  • Hardware and software controls: The proposed mitigation options include flushing the L1-D cache, disabling TSX, and deploying Intel microcode updates.For SGX, the authors recommend treating TSX as unsafe on current machines and flushing L1-D whenever TSX is enabled.
  • Microcode updates: Intel identifies CacheOut as L1DES and indicates that additional microcode updates mitigate it, with preview versions showing successful mitigation.The advisory expected the updates to be available on June 9th, 2020.
  • Conclusion: CacheOut re-enters victim data into microarchitectural buffers after buffer overwriting and can breach user-space, kernel-space, hypervisor, and SGX confidentiality boundaries.The conclusion also reports leakage from Whiskey Lake CPUs that resist prior MDS attacks.
  • Limitation: The demonstrated CacheOut implementation uses TSX and was not evaluated with other transient-execution primitives such as mispredicted branches.The authors identify this as a limitation while noting that TSX remained enabled on Intel systems at the time.

APPENDIX A TSX ASYNCHRONOUS ABORT

The appendix describes a TSX Asynchronous Abort leak primitive in which a transaction reads from a leak source and transmits a byte through FLUSH+RELOAD. It also includes recovery procedures that use known RSA structure and format-dependent filtering to improve reconstruction accuracy.

  • Leak primitive: TSX Asynchronous Abort reads from a flushed leak page inside a transaction and transmits the least significant byte through FLUSH+RELOAD.The transaction is asynchronously aborted after attempting the read.
  • Leak primitive: The leak primitive uses a 4 KiB page as the source and flushes the cache lines used by the TSX transaction before the read.The code example labels the leak source and shows the transaction’s memory access.
  • RSA reconstruction: RSA prime recovery proceeds 8 bytes at a time by testing candidate chunk pairs whose products match the corresponding low-order bytes of the public modulus.The procedure starts from the least significant chunks and appends recovered chunks iteratively.
  • Weight filtering: Penalizing recovered values containing 0x00 or 0xff improves the reported accuracy to 96.1%.The improvement uses the observed nonuniform frequency of noise bytes produced by CacheOut.
Loading 2006.13353v1…