Malware Guard Extension: Using SGX to Conceal Cache Attacks (Extended Version) Michael Schwarz Samuel Weiser Daniel Gruss Graz University of Technology Graz University of Technology Graz University of Technology Email: [email protected] Email: [email protected] Email: [email protected] Clementine´ Maurice Stefan Mangard Graz University of Technology Graz University of Technology Email: [email protected] Email: [email protected] Abstract—In modern computer systems, user processes are attacks can recover cryptographic secrets, such as AES [2], isolated from each other by the operating system and the [3] and RSA [4] keys, across virtual machine boundaries. hardware. Additionally, in a cloud scenario it is crucial that the Intel introduced a new hardware extension SGX (Software hypervisor isolates tenants from other tenants that are co-located on the same physical machine. However, the hypervisor does not Guard Extensions) [5] in their CPUs, starting with the Skylake protect tenants against the cloud provider and thus the supplied microarchitecture. SGX is an isolation mechanism, aiming at operating system and hardware. Intel SGX provides a mechanism protecting code and data from modification or disclosure even that addresses this scenario. It aims at protecting user-level if all privileged software is malicious [6]. This protection software from attacks from other processes, the operating system, uses special execution environments, so-called enclaves, which and even physical attackers. In this paper, we demonstrate fine-grained software-based work on memory areas that are isolated from the operating sys- side-channel attacks from a malicious SGX enclave targeting tem by the hardware. The memory area used by the enclaves co-located enclaves. Our attack is the first malware running is encrypted to protect the application’s secrets from hardware on real SGX hardware, abusing SGX protection features to attackers. Typical use cases include password input, password conceal itself. Furthermore, we demonstrate our attack both managers, and cryptographic operations. Intel recommends in a native environment and across multiple Docker containers. We perform a Prime+Probe cache side-channel attack on a co- storing cryptographic keys inside enclaves and claims that located SGX enclave running an up-to-date RSA implementation side-channel attacks “are thwarted since the memory is pro- that uses a constant-time multiplication primitive. The attack tected by hardware encryption” [7]. works although in SGX enclaves there are no timers, no large Apart from protecting software, the hardware-supported pages, no physical addresses, and no shared memory. In a semi- isolation led to fear of super malware inside enclaves. synchronous attack, we extract 96 % of an RSA private key from a single trace. We extract the full RSA private key in an Rutkowska [8] outlined a scenario where a benign-looking automated attack from 11 traces within 5 minutes. enclave fetches encrypted malware from an external server and decrypts and executes it within the enlave. In this scenario, I. INTRODUCTION it is impossible to debug, reverse engineer, or in any other way analyze the executed malware. Aumasson et al. [9] and arXiv:1702.08719v3 [cs.CR] 22 May 2019 Modern operating systems isolate user processes from each Costan et al. [6] eliminated this fear by arguing that enclaves other to protect secrets in different processes. Such secrets always run with user space privileges and can neither issue include passwords stored in password managers or private syscalls nor perform any I/O operations. Moreover, SGX keys to access company networks. Leakage of these secrets is a highly restrictive environment for implementing cache can compromise both private and corporate systems. Similar side-channel attacks. Both state-of-the-art malware and side- problems arise in the cloud. Therefore, cloud providers use channel attacks rely on several primitives that are not available virtualization as an additional protection using a hypervisor. in SGX enclaves. Consequently, no enclave malware has been The hypervisor isolates different tenants that are co-located on demonstrated on real hardware so far. the same physical machine. However, the hypervisor does not In this paper, we show that it is very well possible for protect tenants against a possibly malicious cloud provider. enclave malware to attack its hosting system. We demonstrate Although hypervisors provide functional isolation, side- a cache attack from within a malicious enclave that is ex- channel attacks are often not considered. Consequently, re- tracting secret keys from co-located enclaves. Our proof-of- searchers have demonstrated various side-channel attacks, es- concept malware is able to recover RSA keys by monitoring pecially those exploiting the cache [1]. Cache side-channel cache access patterns of an RSA signature process in a semi- synchronous attack. The malware code is completely invisible module. This protects enclaves against hardware attacks trying to the operating system and cannot be analyzed due to the to read or manipulate enclave content in DRAM. isolation provided by SGX. In an even stronger attack scenario, Creation and loading of enclaves are done by the oper- we show that an additional isolation using Docker containers ating system. To protect the integrity of enclave code, the does not protect against this kind of attack. loading procedure is measured by the CPU. If the resulting We make the following contributions: measurement does not match the value specified by the enclave 1) We demonstrate that, despite the restrictions of SGX, developer, the CPU will refuse to run the enclave. During cache attacks can be performed from within an enclave enclave loading, the operating system has full access to the to attack a co-located enclave. enclave binary. At this point anti-virus scanners can hook in 2) By combining DRAM and cache side channels, we to analyze the enclave binary before it is executed. Enclave present a novel approach to recover physical address bits malware will attempt to hide from anti-virus scanners by even if 2 MB pages are unavailable. encrypting malicious payload. 3) We show that it is possible to have highly accurate Since enclave code is known to the (untrusted) operating timings within an enclave without access to the native system, it cannot carry hard-coded secrets. Any secret informa- timestamp counter, which is even more accurate than the tion might only be provisioned to the enclave during runtime. native one. Before giving secrets to an enclave, a provisioning party has 4) We demonstrate a fully automated end-to-end attack on to ensure that the enclave has not been tampered with. SGX the RSA implementation of the wide-spread mbedTLS therefore provides remote attestation, which proves correct library. We extract 96 % of an RSA private key from enclave loading via the aforementioned enclave measurement. a single trace and the full key from 11 traces within 5 SGX comes in two versions. SGX1 specifies basic enclave minutes. operation. Moreover, all enclave memory pages have to be Section II presents the background required for our work. allocated at enclave creation. To account for limited memory Section III outlines the threat model and our attack scenario. resources, enclave pages can be swapped out and in at runtime. Section IV describes the measurement methods and the online SGX2 extends SGX with dynamic memory management, phase of the malware. Section V explains the key recovery allowing to allocate new enclave pages at runtime. However, techniques used in the offline phase. Section VI evaluates the we do not use SGX2 features and thus presume that our attack attack against an up-to-date RSA implementation. Section VII is applicable to SGX2 as well. discusses several countermeasures. Section VIII concludes our At the time of writing, no hypervisor with SGX support work. was available to us. However, Docker [10] has support for Intel’s SGX. Docker is an operating-system-level virtualization II. BACKGROUND software that allows applications with all their dependencies to be packed into one container. It has emerged as a standard A. Intel SGX in Native and Virtualized Environments runtime for containers on Linux and can be used on multiple Intel Software Guard Extensions (SGX) are a new set of x86 cloud providers. Unlike virtual machines, Docker containers instructions introduced with the Skylake microarchitecture. share the kernel and other resources with the host system, SGX allows protecting the execution of user programs in so- requiring fewer resources than a virtual machine. Docker called enclaves. Only the enclave can access its own memory isolates processes from each other but does not give a full region, any other access to it is blocked by the CPU. As SGX isolation guarantee such as virtual machines. Arnautov et al. enforces this policy in hardware, enclaves do not need to rely [11] proposed to combine Docker containers with SGX to on the security of the operating system. In fact, with SGX the create secure containers. operating system is generally not trusted. By doing sensitive computation inside an enclave, one can effectively protect B. Microarchitectural Attacks against traditional malware, even if such malware has obtained Microarchitectural attacks exploit hardware properties that kernel privileges. Furthermore, it allows running secret code allow inferring information on other processes running on