DOCSLIB.ORG

LVI Hijacking Transient Execution with Load Value Injection

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
LVI Hijacking Transient Execution with Load Value Injection LVI Hijacking Transient Execution with Load Value Injection Daniel Gruss, Daniel Moghimi, Jo Van Bulck Hardwear.io Virtual Con, April 30, 2020 1 Daniel Gruss, Daniel Moghimi, Jo Van Bulck National Geographic Processor security: Hardware isolation mechanisms App App App Enclave VM OS VM OS Hypervisor (VMM) 3 Daniel Gruss, Daniel Moghimi, Jo Van Bulck CPU Cache printf("%d", i); printf("%d", i); 4 Daniel Gruss, Daniel Moghimi, Jo Van Bulck CPU Cache Cache miss printf("%d", i); printf("%d", i); 4 Daniel Gruss, Daniel Moghimi, Jo Van Bulck CPU Cache Request Cache miss printf("%d", i); printf("%d", i); 4 Daniel Gruss, Daniel Moghimi, Jo Van Bulck CPU Cache Request Cache miss printf("%d", i); i printf("%d", i); Response 4 Daniel Gruss, Daniel Moghimi, Jo Van Bulck CPU Cache Request Cache miss printf("%d", i); i printf("%d", i); Response Cache hit 4 Daniel Gruss, Daniel Moghimi, Jo Van Bulck CPU Cache DRAM access, slow Request Cache miss printf("%d", i); i printf("%d", i); Response Cache hit No DRAM access, much faster 4 Daniel Gruss, Daniel Moghimi, Jo Van Bulck Flush+Reload Shared Memory ATTACKER VICTIM flush access access 5 Daniel Gruss, Daniel Moghimi, Jo Van Bulck Flush+Reload Shared Memory ATTACKER VICTIM flush cached Shared Memory access access cached 5 Daniel Gruss, Daniel Moghimi, Jo Van Bulck Flush+Reload Shared Memory ATTACKER VICTIM flush Shared Memory access access 5 Daniel Gruss, Daniel Moghimi, Jo Van Bulck Flush+Reload Shared Memory ATTACKER VICTIM flush access access 5 Daniel Gruss, Daniel Moghimi, Jo Van Bulck Flush+Reload Shared Memory ATTACKER VICTIM flush access access 5 Daniel Gruss, Daniel Moghimi, Jo Van Bulck Flush+Reload Shared Memory ATTACKER VICTIM flush Shared Memory access access 5 Daniel Gruss, Daniel Moghimi, Jo Van Bulck Flush+Reload Shared Memory ATTACKER VICTIM flush Shared Memory access access 5 Daniel Gruss, Daniel Moghimi, Jo Van Bulck Flush+Reload Shared Memory ATTACKER VICTIM flush Shared Memory access access fast if victim accessed data, slow otherwise 5 Daniel Gruss, Daniel Moghimi, Jo Van Bulck Memory Access Latency Cache Hits 107 104 101 Number of Accesses 50 100 150 200 250 300 350 400 Latency [Cycles] 6 Daniel Gruss, Daniel Moghimi, Jo Van Bulck Memory Access Latency Cache Hits Cache Misses 107 104 101 Number of Accesses 50 100 150 200 250 300 350 400 Latency [Cycles] 6 Daniel Gruss, Daniel Moghimi, Jo Van Bulck We can communicate across protection walls using microarchitectural side-channels! Leaky processors: Jumping over protection walls with side-channels App App App Enclave VM OS VM OS Hypervisor (VMM) 9 Daniel Gruss, Daniel Moghimi, Jo Van Bulck Side-channel attacks are known for decades already – what’s new? 4000 3000 2000 DO WE JUST SUCK AT... COMPUTERS? YUP. ESPECIALLY SHARED ONES. 1000 1990 1994 1998 2002 2006 2010 2014 2018 10 Daniel Gruss, Daniel Moghimi, Jo Van Bulck Side-channel attacks are known for decades already – what’s new? 4000 3000 2000 DO WE JUST SUCK AT... COMPUTERS? YUP. ESPECIALLY SHARED ONES. 1000 1990 1994 1998 2002 2006 2010 2014 2018 10 Daniel Gruss, Daniel Moghimi, Jo Van Bulck 4/30/2020 Pipeline Bubble Fetch Decode Execute Commit movb $20, %al F D add %rax, %rcx F sub %rdx, %rsi jne target: add %rax, %rax target: 11 Daniel Gruss, Daniel Moghimi, Jo Van Bulck 1 1 4/30/2020 Pipeline Bubble Fetch Decode Execute Commit movb $20, %al F D X add %rax, %rcx F D sub %rdx, %rsi F jne target: add %rax, %rax target: 11 Daniel Gruss, Daniel Moghimi, Jo Van Bulck 2 2 4/30/2020 Pipeline Bubble Fetch Decode Execute Commit movb $20, %al F D X C add %rax, %rcx F D X sub %rdx, %rsi F D jne target: F add %rax, %rax target: 11 Daniel Gruss, Daniel Moghimi, Jo Van Bulck 3 3 4/30/2020 Pipeline Bubble Fetch Decode Execute Commit movb $20, %al F D X C add %rax, %rcx F D X C sub %rdx, %rsi F D X jne target: F D add %rax, %rax target: 11 Daniel Gruss, Daniel Moghimi, Jo Van Bulck 4 4 4/30/2020 Pipeline Bubble Fetch Decode Execute Commit movb $20, %al F D X C add %rax, %rcx F D X C sub %rdx, %rsi F D X C jne target: F D X add %rax, %rax target: 11 Daniel Gruss, Daniel Moghimi, Jo Van Bulck 5 5 4/30/2020 Pipeline Bubble Fetch Decode Execute Commit movb $20, %al F D X C add %rax, %rcx F D X C sub %rdx, %rsi F D X C jne target: F D X add %rax, %rax F target: 11 Daniel Gruss, Daniel Moghimi, Jo Van Bulck 6 6 Branch Prediction and Side Channel cmp %rax, %rbx 0x100123: jne <target> 12 Daniel Gruss, Daniel Moghimi, Jo Van Bulck Branch Prediction and Side Channel cmp %rax, %rbx 0x100123: jne <target> PHT 12 Daniel Gruss, Daniel Moghimi, Jo Van Bulck Branch Prediction and Side Channel cmp %rax, %rbx 0x100123: jne <target> PHT BTB 12 Daniel Gruss, Daniel Moghimi, Jo Van Bulck Branch Prediction and Side Channel cmp %rax, %rbx 0x100123: jne <target> PHT BTB 0xff00123: jne <target2> 12 Daniel Gruss, Daniel Moghimi, Jo Van Bulck Branch Prediction and Side Channel cmp %rax, %rbx 0x100123: jne <target> PHT BTB 0xff00123: jne <target2> 12 Daniel Gruss, Daniel Moghimi, Jo Van Bulck Branch Prediction and Side Channel cmp %rax, %rbx 0x100123: jne <target> PHT BTB 0xff00123: jne <target2> 12 Daniel Gruss, Daniel Moghimi, Jo Van Bulck Branch Prediction and Side Channel cmp %rax, %rbx 0x100123: jne <target> PHT BTB 0xff00123: jne <target2> 12 Daniel Gruss, Daniel Moghimi, Jo Van Bulck RSA M=C d modn 13 Daniel Gruss, Daniel Moghimi, Jo Van Bulck RSA M=C d modn 1 1 0 0 1 1 0 ::: Result = C 13 Daniel Gruss, Daniel Moghimi, Jo Van Bulck RSA M=C d modn 1 1 0 0 1 1 0 ::: Result = Result × Result × C square multiply 13 Daniel Gruss, Daniel Moghimi, Jo Van Bulck RSA M=C d modn 1 1 0 0 1 1 0 ::: Result = Result × Result square 13 Daniel Gruss, Daniel Moghimi, Jo Van Bulck RSA M=C d modn 1 1 0 0 1 1 0 ::: Result = Result × Result square 13 Daniel Gruss, Daniel Moghimi, Jo Van Bulck RSA M=C d modn 1 1 0 0 1 1 0 ::: Result = Result × Result × C square multiply 13 Daniel Gruss, Daniel Moghimi, Jo Van Bulck RSA M=C d modn 1 1 0 0 1 1 0 ::: Result = Result × Result × C square multiply 13 Daniel Gruss, Daniel Moghimi, Jo Van Bulck RSA M=C d modn 1 1 0 0 1 1 0 ::: Result = Result × Result square 13 Daniel Gruss, Daniel Moghimi, Jo Van Bulck ? ?? Spectre-PHT (v1) LUT index =0; char* data = ”textKEY”; if (index < 4) else then Prediction LUT[data[index] * 4096] 0 15 Daniel Gruss, Daniel Moghimi, Jo Van Bulck Spectre-PHT (v1) LUT index =0; char* data =”textKEY”; if (index < 4) else then Prediction LUT[data[index] * 4096] 0 15 Daniel Gruss, Daniel Moghimi, Jo Van Bulck Spectre-PHT (v1) LUT index =0; char* data =”textKEY”; if (index < 4) Speculate else then Prediction LUT[data[index] * 4096] 0 15 Daniel Gruss, Daniel Moghimi, Jo Van Bulck Spectre-PHT (v1) LUT index =0; char* data =”textKEY”; if (index < 4) Execute else then Index ’t’ Prediction LUT[data[index] * 4096] 0 15 Daniel Gruss, Daniel Moghimi, Jo Van Bulck Spectre-PHT (v1) LUT index =1; char* data = ”textKEY”; if (index < 4) else then Prediction LUT[data[index] * 4096] 0 15 Daniel Gruss, Daniel Moghimi, Jo Van Bulck Spectre-PHT (v1) LUT index =1; char* data = ”textKEY”; if (index < 4) else then Prediction LUT[data[index] * 4096] 0 15 Daniel Gruss, Daniel Moghimi, Jo Van Bulck Spectre-PHT (v1) LUT index =1; char* data = ”textKEY”; if (index < 4) Speculate Index ’e’ else then Prediction LUT[data[index] * 4096] 0 15 Daniel Gruss, Daniel Moghimi, Jo Van Bulck Spectre-PHT (v1) LUT index =1; char* data = ”textKEY”; if (index < 4) Index ’e’ else then Prediction LUT[data[index] * 4096] 0 15 Daniel Gruss, Daniel Moghimi, Jo Van Bulck Spectre-PHT (v1) LUT index =2; char* data = ”textKEY”; if (index < 4) else then Prediction LUT[data[index] * 4096] 0 15 Daniel Gruss, Daniel Moghimi, Jo Van Bulck Spectre-PHT (v1) LUT index =2; char* data = ”textKEY”; if (index < 4) else then Prediction LUT[data[index] * 4096] 0 15 Daniel Gruss, Daniel Moghimi, Jo Van Bulck Spectre-PHT (v1) LUT index =2; char* data = ”textKEY”; if (index < 4) Speculate else then Prediction Index ’x’ LUT[data[index] * 4096] 0 15 Daniel Gruss, Daniel Moghimi, Jo Van Bulck Spectre-PHT (v1) LUT index =2; char* data = ”textKEY”; if (index < 4) else then Prediction Index ’x’ LUT[data[index] * 4096] 0 15 Daniel Gruss, Daniel Moghimi, Jo Van Bulck Spectre-PHT (v1) LUT index =3; char* data = ”textKEY”; if (index < 4) else then Prediction LUT[data[index] * 4096] 0 15 Daniel Gruss, Daniel Moghimi, Jo Van Bulck Spectre-PHT (v1) LUT index =3; char* data = ”textKEY”; if (index < 4) else then Prediction LUT[data[index] * 4096] 0 15 Daniel Gruss, Daniel Moghimi, Jo Van Bulck Spectre-PHT (v1) LUT index =3; char* data = ”textKEY”; if (index < 4) Speculate else then Index ’t’ Prediction LUT[data[index] * 4096] 0 15 Daniel Gruss, Daniel Moghimi, Jo Van Bulck Spectre-PHT (v1) LUT index =3; char* data = ”textKEY”; if (index < 4) else then Index ’t’ Prediction LUT[data[index] * 4096] 0 15 Daniel Gruss, Daniel Moghimi, Jo Van Bulck Spectre-PHT (v1) LUT index =4; char* data = ”textKEY”; if (index < 4) else then Prediction LUT[data[index] * 4096] 0 15 Daniel Gruss, Daniel Moghimi, Jo Van Bulck Spectre-PHT (v1) LUT index =4; char* data = ”textKEY”; if (index < 4) else then Prediction LUT[data[index] * 4096] 0 15 Daniel Gruss, Daniel Moghimi, Jo Van Bulck Spectre-PHT (v1) LUT index =4; Index ’K’ char* data = ”textKEY”; if (index < 4) Speculate else then Prediction LUT[data[index] * 4096] 0 15 Daniel Gruss, Daniel Moghimi, Jo Van Bulck Spectre-PHT (v1) LUT index =4; Index ’K’ char* data = ”textKEY”; if (index < 4) Execute else then Prediction LUT[data[index] * 4096] 0 15 Daniel Gruss, Daniel Moghimi, Jo Van Bulck Spectre-PHT (v1) LUT index
Load more

Recommended publications
  • Efficiently Mitigating Transient Execution Attacks Using the Unmapped Speculation Contract Jonathan Behrens, Anton Cao, Cel Skeggs, Adam Belay, M
    Efficiently Mitigating Transient Execution Attacks using the Unmapped Speculation Contract Jonathan Behrens, Anton Cao, Cel Skeggs, Adam Belay, M. Frans Kaashoek, and Nickolai Zeldovich, MIT CSAIL https://www.usenix.org/conference/osdi20/presentation/behrens This paper is included in the Proceedings of the 14th USENIX Symposium on Operating Systems Design and Implementation November 4–6, 2020 978-1-939133-19-9 Open access to the Proceedings of the 14th USENIX Symposium on Operating Systems Design and Implementation is sponsored by USENIX Efficiently Mitigating Transient Execution Attacks using the Unmapped Speculation Contract Jonathan Behrens, Anton Cao, Cel Skeggs, Adam Belay, M. Frans Kaashoek, and Nickolai Zeldovich MIT CSAIL Abstract designers have implemented a range of mitigations to defeat transient execution attacks, including state flushing, selectively Today’s kernels pay a performance penalty for mitigations— preventing speculative execution, and removing observation such as KPTI, retpoline, return stack stuffing, speculation channels [5]. These mitigations impose performance over- barriers—to protect against transient execution side-channel heads (see §2): some of the mitigations must be applied at attacks such as Meltdown [21] and Spectre [16]. each privilege mode transition (e.g., system call entry and exit), To address this performance penalty, this paper articulates and some must be applied to all running code (e.g., retpolines the unmapped speculation contract, an observation that mem- for all indirect jumps). In some cases, they are so expensive ory that isn’t mapped in a page table cannot be leaked through that OS vendors have decided to leave them disabled by de- transient execution. To demonstrate the value of this contract, fault [2, 22].
    [Show full text]
  • Class-Action Lawsuit
    Case 3:20-cv-00863-SI Document 1 Filed 05/29/20 Page 1 of 279 Steve D. Larson, OSB No. 863540 Email: [email protected] Jennifer S. Wagner, OSB No. 024470 Email: [email protected] STOLL STOLL BERNE LOKTING & SHLACHTER P.C. 209 SW Oak Street, Suite 500 Portland, Oregon 97204 Telephone: (503) 227-1600 Attorneys for Plaintiffs [Additional Counsel Listed on Signature Page.] UNITED STATES DISTRICT COURT DISTRICT OF OREGON PORTLAND DIVISION BLUE PEAK HOSTING, LLC, PAMELA Case No. GREEN, TITI RICAFORT, MARGARITE SIMPSON, and MICHAEL NELSON, on behalf of CLASS ACTION ALLEGATION themselves and all others similarly situated, COMPLAINT Plaintiffs, DEMAND FOR JURY TRIAL v. INTEL CORPORATION, a Delaware corporation, Defendant. CLASS ACTION ALLEGATION COMPLAINT Case 3:20-cv-00863-SI Document 1 Filed 05/29/20 Page 2 of 279 Plaintiffs Blue Peak Hosting, LLC, Pamela Green, Titi Ricafort, Margarite Sampson, and Michael Nelson, individually and on behalf of the members of the Class defined below, allege the following against Defendant Intel Corporation (“Intel” or “the Company”), based upon personal knowledge with respect to themselves and on information and belief derived from, among other things, the investigation of counsel and review of public documents as to all other matters. INTRODUCTION 1. Despite Intel’s intentional concealment of specific design choices that it long knew rendered its central processing units (“CPUs” or “processors”) unsecure, it was only in January 2018 that it was first revealed to the public that Intel’s CPUs have significant security vulnerabilities that gave unauthorized program instructions access to protected data. 2. A CPU is the “brain” in every computer and mobile device and processes all of the essential applications, including the handling of confidential information such as passwords and encryption keys.
    [Show full text]
  • LVI-LFB: Scenarios 3 & 4
    WHITEPAPER Security Load Value Injection in the Line Fill Buffers: How to Hijack Control Flow without Spectre www.bitdefender.com Contents Abstract .............................................................................................................................3 Introduction .......................................................................................................................3 Recap – Meltdown, Spectre & MDS .................................................................................4 Meltdown .................................................................................................................................4 Spectre ..................................................................................................................................... 4 Microarchitectural Data Sampling .......................................................................................... 5 Load Value Injection in the Line Fill Buffers ....................................................................5 Exploiting LVI-LFB: scenarios 3 & 4..................................................................................7 Real-life exploit ..................................................................................................................7 Mitigations .........................................................................................................................8 Conclusions .......................................................................................................................9
    [Show full text]
  • Software-Based Power Side-Channel Attacks on X86
    PLATYPUS: Software-based Power Side-Channel Attacks on x86 Moritz Lipp∗, Andreas Kogler∗, David Oswald†, Michael Schwarz‡, Catherine Easdon∗, Claudio Canella∗, and Daniel Gruss∗ ∗ Graz University of Technology †University of Birmingham, UK ‡CISPA Helmholtz Center for Information Security Abstract—Power side-channel attacks exploit variations in on an ARM TrustZone-M platform using an onboard ADC, power consumption to extract secrets from a device, e.g., crypto- and Mantel et al. [56] distinguished different RSA keys by graphic keys. Prior attacks typically required physical access to measuring the power consumption on Intel desktop machines. the target device and specialized equipment such as probes and a high-resolution oscilloscope. The experimental results of Mantel et al. on RSA demonstrated In this paper, we present PLATYPUS attacks, which are that certain multiply operations of the square-and-multiply novel software-based power side-channel attacks on Intel server, implementation can be detected, but no full key recovery was desktop, and laptop CPUs. We exploit unprivileged access to achieved. Similarly, Fusi [20] tried to recover RSA-16384 keys the Intel Running Average Power Limit (RAPL) interface that but concluded that the sampling rate of the interface is too low exposes values directly correlated with power consumption, forming a low-resolution side channel. to mount an attack. We show that with sufficient statistical evaluation, we can In this work, we present PLATYPUS1 attacks which are observe variations in power consumption, which distinguish novel software-based power side-channel attacks on Intel different instructions and different Hamming weights of operands servers, desktops, and laptops by abusing unprivileged access and memory loads.
    [Show full text]
  • Speculative Dereferencing: Reviving Foreshadow (Extended Version)
    Speculative Dereferencing: Reviving Foreshadow (Extended Version) Martin Schwarzl1, Thomas Schuster1, Michael Schwarz2, and Daniel Gruss1 1Graz University of Technology, Austria 2CISPA Helmholtz Center for Information Security, Germany Abstract. In this paper, we provide a systematic analysis of the root cause of the prefetching effect observed in previous works and show that its attribution to a prefetching mechanism is incorrect in all previous works, leading to incorrect conclusions and incomplete defenses. We show that the root cause is speculative dereferencing of user-space registers in the kernel. This new insight enables the first end-to-end Foreshadow (L1TF) exploit targeting non-L1 data, despite Foreshadow mitigations enabled, a novel technique to directly leak register values, and several side-channel attacks. While the L1TF effect is mitigated on the most re- cent Intel CPUs, all other attacks we present still work on all Intel CPUs and on CPUs by other vendors previously believed to be unaffected. 1 Introduction For security reasons, operating systems hide physical addresses from user pro- grams [34]. Hence, an attacker requiring this information has to leak it first, e.g., with the address-translation attack by Gruss et al. [17, §3.3 and §5]. It allows user programs to fetch arbitrary kernel addresses into the cache and thereby to resolve virtual to physical addresses. As a mitigation against e.g., the address- translation attack, Gruss et al. [17, 16] proposed the KAISER technique. Other attacks observed and exploited similar prefetching effects. Meltdown [41] practically leaks memory that is not in the L1 cache. Xiao et al. [72] show that this relies on a prefetching effect that fetches data from the L3 cache into the L1 cache.
    [Show full text]
  • SPECBOX: a Label-Based Transparent Speculation Scheme Against Transient Execution Attacks
    SPECBOX: A Label-Based Transparent Speculation Scheme Against Transient Execution Attacks Bowen Tang1;2 , Chenggang Wu1;2, Zhe Wang1;2, Lichen Jia1;2, Pen-Chung Yew3, Yueqiang Cheng4, Yinqian Zhang5, Chenxi Wang6, Guoqing Harry Xu6 1State Key Laboratory of Computer Architecture, Institute of Computing Technology, Chinese Academy of Sciences, 2University of the Chinese Academy of Sciences, 3University of Minnesota at Twin Cities, 4NIO Security Research, 5Southern University of Science and Technology, 6University of California, Los Angeles 1{tangbowen, wucg, wangzhe12, jialichen}@ict.ac.cn, [email protected], [email protected], [email protected], 6{wangchenxi, harryxu}@cs.ucla.edu Abstract—Speculative execution techniques have been a cor- when the processor determines that it is a mis-prediction in nerstone of modern processors to improve instruction-level Line 5, it will squash the instructions of Lines 6-7 and follow parallelism. However, recent studies showed that this kind of the correct path. In the current design, the processor will not techniques could be exploited by attackers to leak secret data via transient execution attacks, such as Spectre. Many defenses clean up the side effects in the cache (i.e. the data brought in are proposed to address this problem, but they all face various during the mis-speculative execution). The attacker can scan challenges: (1) Tracking data flow in the instruction pipeline the dummy array in the cache, and measure the access time could comprehensively address this problem, but it could cause of each array element. According to the access latency, the pipeline stalls and incur high performance overhead; (2) Making attacker can decide which item has been loaded into the cache, side effect of speculative execution imperceptible to attackers, but it often needs additional storage components and complicated and thereby infer the secret value.
    [Show full text]
  • Efficiently Mitigating Transient Execution Attacks Using the Unmapped Speculation Contract Jonathan Behrens, Anton Cao, Cel Skeggs, Adam Belay, M
    Efficiently Mitigating Transient Execution Attacks using the Unmapped Speculation Contract Jonathan Behrens, Anton Cao, Cel Skeggs, Adam Belay, M. Frans Kaashoek, and Nickolai Zeldovich MIT CSAIL Abstract designers have implemented a range of mitigations to defeat transient execution attacks, including state flushing, selectively Today’s kernels pay a performance penalty for mitigations— preventing speculative execution, and removing observation such as KPTI, retpoline, return stack stuffing, speculation channels [5]. These mitigations impose performance over- barriers—to protect against transient execution side-channel heads (see §2): some of the mitigations must be applied at attacks such as Meltdown [21] and Spectre [16]. each privilege mode transition (e.g., system call entry and exit), To address this performance penalty, this paper articulates and some must be applied to all running code (e.g., retpolines the unmapped speculation contract, an observation that mem- for all indirect jumps). In some cases, they are so expensive ory that isn’t mapped in a page table cannot be leaked through that OS vendors have decided to leave them disabled by de- transient execution. To demonstrate the value of this contract, fault [2, 22]. Recent processor designs have also incorporated the paper presents WARD, a new kernel design that maintains mitigations into hardware, which also reduces performance a separate kernel page table for every process. This page table compared to earlier processor designs that do not perform such contains mappings for kernel memory that is safe to expose hardware mitigations. to that process. Because a process doesn’t map data of other To address the above challenge, this paper proposes a new processes, this design allows for many system calls to execute hardware/software contract, called the unmapped speculation without any mitigation overhead.
    [Show full text]
  • A Systematic Analysis of Machine Clears and Their Implications For
    Rage Against the Machine Clear: A Systematic Analysis of Machine Clears and Their Implications for Transient Execution Attacks Hany Ragab, Enrico Barberis, Herbert Bos, and Cristiano Giuffrida, Vrije Universiteit Amsterdam https://www.usenix.org/conference/usenixsecurity21/presentation/ragab This paper is included in the Proceedings of the 30th USENIX Security Symposium. August 11–13, 2021 978-1-939133-24-3 Open access to the Proceedings of the 30th USENIX Security Symposium is sponsored by USENIX. Rage Against the Machine Clear: A Systematic Analysis of Machine Clears and Their Implications for Transient Execution Attacks Hany Ragab∗ Enrico Barberis∗ Herbert Bos Cristiano Giuffrida [email protected] [email protected] [email protected] [email protected] Vrije Universiteit Amsterdam Amsterdam, The Netherlands ∗Equal contribution joint first authors Abstract 79, 82]. Building mostly on well-known causes of transient execution, such as branch mispredictions or aborting Intel Since the discovery of the Spectre and Meltdown vulnera- TSX transactions, such variants violate many security bound- bilities, transient execution attacks have increasingly gained aries, allowing attackers to obtain access to unauthorized data, momentum. However, while the community has investigated divert control flow, or inject values in transiently executed several variants to trigger attacks during transient execution, code. Nonetheless, little effort has been made to systemat- much less attention has been devoted to the analysis of the ically investigate the root causes of what Intel refers to as root causes of transient execution itself. Most attack vari- bad speculation [36]—the conditions that cause the CPU to ants simply build on well-known root causes, such as branch discard already issued micro-operations (µOps) and render misprediction and aborts of Intel TSX—which are no longer them transient.
    [Show full text]
  • The Evolution of Transient-Execution Attacks Claudio Canella Khaled N
    The Evolution of Transient-Execution Attacks Claudio Canella Khaled N. Khasawneh Daniel Gruss Graz University of Technology George Mason University Graz University of Technology [email protected] [email protected] [email protected] ABSTRACT From a security perspective, non-architectural state was long Historically, non-architectural state was considered non-observable. considered non-observable as there is no attacker-accessible inter- Side-channel attacks, in particular on caches, already showed that face to check what is in the cache. Kocher [23] brought up the idea this is not entirely correct and meta-information, such as the cache that caches could be used in side-channel attacks. Such attacks mea- state, can be extracted. Transient-execution attacks emerged when sure the latency of memory accesses to infer what is in the cache, multiple groups discovered the exploitability of speculative execu- yielding an interface that makes non-architectural state visible to tion and, simultaneously, the exploitability of deferred permission an attacker. However, the information extracted here is only meta- checks in modern out-of-order processors. These attacks are called information, i.e., whether the data was retrieved from the cache or transient as they exploit that the processor first executes operations main memory. While this enables powerful cryptographic [28] and that are then reverted as if they were never executed. However, on non-cryptographic [12] attacks, both the security community and the microarchitectural level, these operations and their effects can the architecture community deemed it most reasonable to design be observed. While side-channel attacks enable and exploit direct ac- code in a way such that secrets do not influence meta-information, cess to meta-data from other security domains, transient-execution e.g., no secret-dependent memory accesses [3].
    [Show full text]
  • Transient-Execution Attacks and Defenses
    Transient-Execution Attacks and Defenses Habilitation by Daniel Gruss June 2020 Daniel Gruss Transient-Execution Attacks and Defenses (Part I only) Habilitation June 2020 Institute for Applied Information Processing and Communications Graz University of Technology SCIENCE PASSION TECHNOLOGY Abstract The complexity of modern computer systems has dramatically increased over the past decades and continues to increase. The common solution to construct such complex systems is the divide-and-conquer strategy, dividing a complex system into smaller and less complex systems or system components. For a small system component, the complexity of the full system is hidden behind abstraction layers, allowing to develop, improve, and reason about it. As computers have become ubiquitous, so has computer security, which is now present in all aspects of our lives. One fundamental problem of security stems from the strategy that allowed building and maintaining complex systems: the isolated view of system components. Security problems often arise when abstractions are imperfect or incomplete, which they inherently need to be to hide complexity. In this habilitation, we focus on a very specific type of computer security problem, where an imperfect abstraction of the hardware can be observed from the software layer. The abstraction of the hardware, i.e., the defined hardware interface, is often called the \architecture". In contrast, the concrete implementation of the hardware interface, is called the \microar- chitecture". Architecture and microarchitecture often deviate enough to introduce software-exploitable behavior. This entirely new field of research, called \Transient-Execution Attacks", has not existed before our seminal works in 2018. Transient-execution attacks exploit that the hardware transiently performs operations it should not perform, in one of two cases: In one case deliberately (non-speculatively), as the operations will be architecturally discarded anyway.
    [Show full text]
  • Rage Against the Machine Clear: a Systematic Analysis of Machine Clears and Their Implications for Transient Execution Attacks
    Rage Against the Machine Clear: A Systematic Analysis of Machine Clears and Their Implications for Transient Execution Attacks Hany Ragab∗ Enrico Barberis∗ Herbert Bos Cristiano Giuffrida [email protected] [email protected] [email protected] [email protected] Vrije Universiteit Amsterdam Amsterdam, The Netherlands ∗Equal contribution joint first authors Abstract 80, 83]. Building mostly on well-known causes of transient execution, such as branch mispredictions or aborting Intel Since the discovery of the Spectre and Meltdown vulnera- TSX transactions, such variants violate many security bound- bilities, transient execution attacks have increasingly gained aries, allowing attackers to obtain access to unauthorized data, momentum. However, while the community has investigated divert control flow, or inject values in transiently executed several variants to trigger attacks during transient execution, code. Nonetheless, little effort has been made to systemat- much less attention has been devoted to the analysis of the ically investigate the root causes of what Intel refers to as root causes of transient execution itself. Most attack vari- bad speculation [36]—the conditions that cause the CPU to ants simply build on well-known root causes, such as branch discard already issued micro-operations (µOps) and render misprediction and aborts of Intel TSX—which are no longer them transient. As a result, our understanding of these root supported on many recent processors. causes, as well as their security implications, is still limited. In this paper, we tackle the problem from a new perspective, In this paper, we systematically examine such causes with a closely examining the different root causes of transient exe- focus on a major, largely unexplored class of bad speculation.
    [Show full text]
  • New Models for Understanding and Reasoning About Speculative Execution Attacks
    New Models for Understanding and Reasoning about Speculative Execution Attacks Zecheng He Guangyuan Hu Ruby Lee Princeton University Princeton University Princeton University [email protected] [email protected] [email protected] Abstract—Spectre and Meltdown attacks and their variants Lazy-FP [36] attacks and their variants are proposed to breach exploit hardware performance optimization features to cause the memory isolation by using a covert channel to exfiltrate security breaches. Secret information is accessed and leaked a secret obtained illegally under speculative execution. For through covert or side channels. New attack variants keep appearing and we do not have a systematic way to capture the example, Spectre breaches the memory isolation provided critical characteristics of these attacks and evaluate why they within a user application, while Meltdown breaches the succeed or fail. memory isolation between the kernel and a user application. In this paper, we provide a new attack-graph model for rea- Foreshadow breaches the isolation of Intel SGX secure enclaves. soning about speculative execution attacks. We model attacks as Foreshadow-OS and Foreshadow-VMM breach the isolation ordered dependency graphs, and prove that a race condition be- tween two nodes can occur if there is a missing dependency edge provided by the Operating System and the Virtual Machine between them. We define a new concept, “security dependency”, Monitor, respectively. All of these attacks leverage the specu- between a resource access and its prior authorization operation. lative execution feature of modern processors, transferring We show that a missing security dependency is equivalent to a the security-critical information to micro-architecture state race condition between authorization and access, which is a root observable by an unprivileged attacker through a covert channel.
    [Show full text]