Top Picks Breaking Virtual Memory Protection and the SGX Ecosystem with Foreshadow Jo Van Bulck Frank Piessens Katholieke Universiteit Leuven Katholieke Universiteit Leuven Marina Minkin Mark Silberstein University of Michigan Technion–Israel Institute of Technology Ofir Weisse Thomas F. Wenisch University of Michigan University of Michigan Daniel Genkin Yuval Yarom University of Michigan University of Adelaide and Data61, CSIRO Baris Kasikci Raoul Strackx University of Michigan Katholieke Universiteit Leuven Abstract—Foreshadow is a speculative execution attack that allows adversaries to subvert the security guarantees of Intel’s Software Guard eXtensions (SGX). Foreshadow allows access to data across process boundaries, and allows virtual machines (VMs) to read the physical memory belonging to other VMs or the hypervisor. & OVER THE PAST year and a half, speculative have gone from a hypothetical possibility to a execution attacks-–attacks that subvert memory very real threat.1,2 These attacks allow software to protection by exploiting the speculative execution exploit microarchitectural flaws, wherein specula- features of modern out-of-order processors— tive wrong-path instructions are allowed to access memory in violation of architectural protection guarantees. For example, the Meltdown flaw2 Digital Object Identifier 10.1109/MM.2019.2910104 allows the user-level code to access kernel Date of publication 15 April 2019; date of current version 8 memory locations that are mapped into the pro- May 2019. cess address space but are restricted to privileged 66 0272-1732 ß 2019 IEEE Published by the IEEE Computer Society IEEE Micro accesses only. Speculative execution attacks that data accessed during execution cannot be exploit the transient data access of wrong-path observed by the privileged cloud vendor. instructions by leaking secret data into a side chan- To support such private and secure code exe- nel. Side-channel attacks exploit subtle timing var- cution, SGX provides isolated execution environ- iations in program execution resulting from state ments, called enclaves, which offer confidentiality changes in microarchitectural (i.e., unspecified in and integrity guarantees to programs running the instruction set architecture) structures or con- inside them. Enclaves are secure even in the pres- tention on microarchitectural CPU resources to ence of a malicious operating system, hypervisor, extract otherwise-unavailable secret information. or firmware. Enclaves are also resilient to physical Processor vendors have invested signific- attacks from outside the CPU package, such as ant effort3 to roll out mitigations for the earliest probes on the memory bus. discovered speculative execution attacks, Melt- At a high level, SGX achieves these strong secu- down2 and Spectre.1 rity guarantees by encrypting the enclave memory Unfortunately these and protecting it with a secure authentication code, measures are inef- Foreshadow allows the making the associated cryptographic keys inaccessi- fective against Fore- attacker code direct ble to software. Finally, SGX provides a remote attes- shadow (also known access to arbitrary tation mechanism. Attestation allows enclaves to as “L1 Terminal physical addresses prove to remote parties that the code and data Fault (L1TF)” in through speculative upon which they operate are unmodified and, impor- Intel’s product liter- wrong-path execution. tantly, the processor upon which they execute is a ature4). Foreshadow genuine (hence, presumed secure) Intel processor. allows the attacker code direct access to arbitrary Notwithstanding its strong security guaran- physical addresses through speculative wrong- tees, SGX does not protect against microarc- path execution. Unlike previously disclosed specu- hitectural side-channel attacks. Since their lative execution attacks, this vulnerability fully sub- introduction over a decade ago, microarchitec- verts the isolation provided by the traditional tural attacks have been used to break numerous virtual memory abstraction, upon which the classic cryptographic implementations, track program security mechanisms of operating systems and vir- behavior, and create covert communication chan- tual machines are built, by allowing attackers to nels. Since SGX’s release, there have been many access data that has no virtual address mapping. works that demonstrated side-channel attacks on The key restriction of Foreshadow/L1TF is that as SGX enclaves (e.g., work presented by Xu et al.5)— far as we know, only physical addresses cached in exploiting vulnerabilities that already exist in the L1 data cache can be exfiltrated. However, as enclaves’ code to leak sensitive data. we show, there are often mechanisms available to Instead, our investigation was motivated by cause the processor to load desired data into the following question: Can an adversary extract cache; in some circumstances, entire address secret data from an enclave’s address space spaces can be exfiltrated. when the code running in that enclave does not itself have any security vulnerabilities? FORESHADOW-SGX Next, given the importance of SGX remote Our international collaboration discovered attestation we asked: What are the implications Foreshadow/L1TF in the context of efforts to inves- of such security breaches on the SGX integrity tigate the security of Intel’s Software Guard guarantees? Can an adversary using a side chan- eXtensions (SGX). SGX is a set of architectural nel erode trust in SGX remote attestation? extensions, which collectively provide strong secu- We answer both questions in the affirmative. rity guarantees to software running in the presence of powerful adversaries. SGX promises secure execution on adversary-controlled machines. OUR CONTRIBUTIONS For example, in the context of cloud computing, Breaking SGX’s Confidentiality SGX guarantees that the processor executes the Foreshadow-SGX exploits the speculative unmodified code provided by the customer and execution features present in all SGX-enabled May/June 2019 67 Top Picks Intel CPUs to read the entire address space of Exploiting SGX’s Privacy Guarantees victim enclaves. Crucially, unlike previous Spec- We note that SGX’s attestation protocol is tre-style speculative execution attacks on SGX, designed with privacy in mind and does not our attack does not require any form of coopera- reveal the identity of the attesting machine to tion or particular flaw in the victim enclave. the remote verifying party. As such, the remote In fact, our attack reads all the secrets of the party has no way of telling which keys were used victim enclave without requiring that enclave to for attestation. Consequently, until revoked by execute any instruction. Intel, even a single leaked attestation key can be used for all malicious simulators, without the remote parties being able to distinguish them Breaking the Integrity of Sealed Data from genuine SGX machines. Thus, the leak of Going beyond the attacks on the SGX confi- even a single key jeopardizes the trustworthi- dentiality properties, we show that Foreshadow ness of the entire SGX ecosystem. also compromises SGX’s long-term storage integ- rity guarantees. Specifically, beyond secure Demonstrating the Brittleness of the SGX computation, SGX also provides private and Ecosystem authenticated long-term storage, which is imple- To the best of our knowledge, our attack is mented via a special sealing application program- the first direct attack on the confidentiality of ming interface (API). This storage mechanism SGX enclaves that makes no assumptions about allows enclaves to encrypt and verify data stored code running in a victim enclave. By leveraging by the (untrusted) operating system. this attack, the adversary may break the integ- As we show, we can use our attack on SGX’s rity of the SGX long-term storage and the trust- confidentiality to extract the sealing key from a worthiness of the remote attestation protocol. victim enclave that uses the SGX sealing mecha- As such, our work highlights the brittleness of 11 nism. After recovering the sealing key, we use the current SGX design because a flaw in confi- it to unseal and read the sealed information, dentiality leads to a cascading set of compro- then modify and reseal it. As SGX provides no mises that undermine the root of trust in the means to detect such a change, the victim con- ecosystem. sequently operates on data corrupted by the attacker. First real demonstration of the L1TF vulnerability Our international collaboration reported Breaking Remote Attestation our proof-of-concept exploit of SGX to Intel. Finally, we turn our attention to SGX’s remote Prompted by our reports, Intel subsequently dis- attestation mechanism, which allows an enclave covered and revealed the underlying L1TF micro- to prove to a remote party that it has been ini- architectural flaw, with consequences much tialized correctly and is executing on a genuine broader than SGX, including subverting memory (presumably secure) Intel processor. protections essential for cloud computing. As we show, we can mount our attacks on enclaves written by Intel and extract their sealing BACKGROUND—SIDE-CHANNEL key. Using the extracted sealing key, we then AND SPECULATIVE EXECUTION unseal the persistent storage of the SGX Quoting ATTACKS Enclave, which contains the machine’s private We briefly explain past side-channel and spe- attestation key. With this key, we can construct culative execution attack mechanisms. malicious SGX simulators that can forge the attes- tation process, masquerading as