RIDL: Rogue In-Flight Data Load

RIDL: Rogue In-Flight Data Load Stephan van Schaik∗, Alyssa Milburn∗, Sebastian Österlund∗, Pietro Frigo∗, Giorgi Maisuradze†‡, Kaveh Razavi∗, Herbert Bos∗, and Cristiano Giuffrida∗ ∗Department of Computer Science †CISPA 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 practical “spot” mitigations against existing attacks [6], (RIDL), a new class of speculative unprivileged and [7], [8], [9]. This shaped the common perception that— constrained attacks to leak arbitrary data across ad- until in-silicon mitigations are available on the next gener- dress spaces and privilege boundaries (e.g., process, ation of hardware—per-variant, software-only mitigations kernel, SGX, and even CPU-internal operations). Our are a relatively pain-free strategy to contain ever-emerging reverse engineering efforts show such vulnerabilities memory disclosure attacks based on speculative execution. originate from a variety of micro-optimizations pervasive in commodity (Intel) processors, which cause In this paper, we challenge the common perception the CPU to speculatively serve loads using extrane- by introducing Rogue In-flight Data Load (RIDL), a new ous CPU-internal in-flight data (e.g., in the line fill class of speculative execution attacks that lifts all such ad- buffers). Contrary to other state-of-the-art speculative dressing restrictions entirely. While existing attacks target execution attacks, such as Spectre, Meltdown and Fore- shadow, RIDL can leak this arbitrary in-flight data with information at specific addresses, RIDL operates akin to no assumptions on the state of the caches or translation a passive sniffer that eavesdrops on in-flight data (e.g., data structures controlled by privileged software. in the line fill buffers or LFBs) flowing through CPU components. RIDL is powerful: it can leak information The implications are worrisome. First, RIDL attacks across address space and privilege boundaries by solely can be implemented even from linear execution with no invalid page faults, eliminating the need for excep- abusing micro-optimizations implemented in commodity tion suppression mechanisms and enabling system-wide Intel processors. Unlike existing attacks, RIDL is non- attacks from arbitrary unprivileged code (including trivial to stop with practical mitigations in software. JavaScript in the browser). To exemplify such attacks, we build a number of practical exploits that leak The vulnerability of existing vulnerabilities. To il- sensitive information from victim processes, virtual lustrate how existing speculative execution vulnerabilities machines, kernel, SGX and CPU-internal components. are subject to addressing restrictions and how this provides Second, and perhaps more importantly, RIDL bypasses defenders convenient anchor points for “spot” software all existing “spot” mitigations in software (e.g., KPTI, mitigations, we consider their most prominent examples. PTE inversion) and hardware (e.g., speculative store bypass disable) and cannot easily be mitigated even Spectre [2] allows attackers to manipulate the state by more heavyweight defenses (e.g., L1D flushing or of the branch prediction unit and abuse the mispredicted disabling SMT). RIDL questions the sustainability of a branch to leak arbitrary data within the accessible address per-variant, spot mitigation strategy and suggests more space via a side channel (e.g., cache). This primitive by fundamental mitigations are needed to contain ever- itself is useful in sandbox (e.g., JavaScript) escape scenar- emerging speculative execution attacks. ios, but needs to resort to confused-deputy attacks [10] to implement cross-address space (e.g., kernel) memory I. Introduction disclosure. In such attacks, the attacker needs to lure Since the original Meltdown and Spectre disclosure, the the victim component into speculatively executing specific family of memory disclosure attacks abusing speculative “gadgets”, disclosing data from the victim address space execution 1 has grown steadily [1], [2], [3], [4], [5]. While back to the attacker. This requirement opened the door these attacks can leak sensitive information across secu- to a number of practical software mitigations, ranging rity boundaries, they are all subject to strict addressing from halting speculation when accessing untrusted point- restrictions. In particular, Spectre variants [2], [4], [5] allow ers or indices [7] to not speculating across vulnerable attacker-controlled code to only leak within the loaded branches [6]. virtual address space. Meltdown [1] and Foreshadow [3] Meltdown [1] somewhat loosens the restrictions of the require the target physical address to at least appear in addresses reachable from attacker-controlled code. Rather the loaded address translation data structures. Such re- than restricting the code to valid addresses, an unpriv- strictions have exposed convenient anchor points to deploy ileged attacker can also access privileged address space ‡ Work started during internship at Microsoft Research. mappings that are normally made inaccessible by the 1Unless otherwise noted, we loosely refer to both speculative and supervisor bit in the translation data structures. The out-of-order execution as speculative execution in this paper. reason is that, while any access to a privileged address will eventually trigger an error condition (i.e., invalid in both cross-thread and same-thread (no SMT) scenarios. page fault), before properly handling it, the CPU already This applies to all the existing Intel systems with the exposes the privileged data to out-of-order execution, al- latest (microcode) updates and all the defenses up. In lowing disclosure. This enables cross-address space (user- particular, RIDL bypasses all the practical mitigations to-kernel) attacks, but only in a traditional user/kernel against existing attacks and even the more heavyweight, unified address space design. This requirement opened the default-off mitigations such as periodic L1 flushing. The door to practical software mitigations such as KPTI [9], lesson learned is that mitigating RIDL-like attacks with where the operating system (OS) isolates the kernel in its practical software mitigations is non-trivial and we need own address space rather than relying on the supervisor more fundamental mitigations to end the speculative exe- bit for isolation. cution attacks era. Foreshadow [3] further loosens the addressing restric- Contributions. We make the following contributions: tions. Rather than restricting attacker-controlled code to • valid and privileged addresses, the attacker can also access We present RIDL, a new class of speculative exe- physical addresses mapped by invalid (e.g., non-present) cution vulnerabilities pervasive in commodity Intel translation data structure entries. Similar to Meltdown, CPUs. RIDL enables unprivileged attackers to craft the target physical address is accessed via the cache, address-agnostic memory disclosure primitives across data is then passed to out-of-order execution, and subse- arbitrary security boundaries for the first time and has been rewarded by the Intel Bug Bounty Program. quently leaked before the corresponding invalid page fault • is detected. Unlike Meltdown, given the milder addressing We investigate the root cause of practical RIDL in- restrictions, Foreshadow enables arbitrary cross-address stances abusing Line Fill Buffers (LFBs), presenting space attacks. But this is only possible when the attacker the first reverse engineering effort to analyze LFB behavior and related micro-optimizations. can surgically control the physical address of some invalid • translation structure entry. This requirement opened the We present a number of real-world exploits that door to practical software mitigations such as PTE inver- demonstrate an unprivileged RIDL-enabled attacker sion [8], where the OS simply masks the physical address can leak data across arbitrary security boundaries, of any invalidated translation structure entry. including process, kernel, VM and SGX, even with 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. Demos of these future speculative execution attacks was misplaced. As RIDL exploits can be found at https://ridl.eu. we shall see, RIDL can leak in-flight data of a victim • We place RIDL in the context of state-of-the-art at- process even if that process is not speculating (e.g., due to tacks and mitigation efforts. Our analysis shows that, Spectre mitigations) and it does not require control over unlike existing attacks, RIDL is ill-suited to practical address translation data structures at all. These properties mitigations in software and more fundamental miti- remove all the assumptions that spot mitigations rely on. gations are necessary moving forward. Translation data structures, specifically, enforce basic security mechanisms such as isolation, access permissions and II. Background privileges. Relaxing the requirement on translation data structures allows RIDL to mount powerful cross-address 3 Memory Pipeline L1i TLB L2 TLB space speculative execution attacks directly from error-free L1i L2 Cache and branchless unprivileged execution

Load more