TEEREX: Discovery and Exploitation of Memory Corruption Vulnerabilities in SGX Enclaves Tobias Cloosters, Michael Rodler, and Lucas Davi, University of Duisburg-Essen https://www.usenix.org/conference/usenixsecurity20/presentation/cloosters This paper is included in the Proceedings of the 29th USENIX Security Symposium. August 12–14, 2020 978-1-939133-17-5 Open access to the Proceedings of the 29th USENIX Security Symposium is sponsored by USENIX. TEEREX: Discovery and Exploitation of Memory Corruption Vulnerabilities in SGX Enclaves Tobias Cloosters, Michael Rodler, Lucas Davi University of Duisburg-Essen, Germany {tobias.cloosters, michael.rodler, lucas.davi}@uni-due.de Abstract allows a user to establish a secure channel directly to the SGX enclave (which potentially runs in an untrusted cloud environ- Intel’s Software Guard Extensions (SGX) introduced new ment) and perform remote attestation to ensure the integrity instructions to switch the processor to enclave mode which of the remote SGX hardware and enclave. That said, SGX is protects it from introspection. While the enclave mode a strong isolation mechanism for sensitive data (e.g., personal strongly protects the memory and the state of the proces- information or cryptographic keys) as well as security-critical sor, it cannot withstand memory corruption errors inside the code (e.g., for the sake of intellectual property protection). enclave code. In this paper, we show that the attack surface It also found its way into commercial applications, e.g., fin- of SGX enclaves provides new challenges for enclave devel- gerprint sensor software (Section5), DRM protection [20], opers as exploitable memory corruption vulnerabilities are and privacy-preserving applications like Signal [48]. As such easily introduced into enclave code. We develop TEEREX to a promising technology, SGX has been used and targeted automatically analyze enclave binary code for vulnerabilities extensively in previous research. Many projects propose to introduced at the host-to-enclave boundary by means of sym- utilize SGX for enhanced security guarantees, e.g., processing bolic execution. Our evaluation on public enclave binaries re- private data in public clouds [6, 55]. veal that many of them suffer from memory corruption errors allowing an attacker to corrupt function pointers or perform From its infancy, it was clear that SGX cannot withstand all flavors of attacks [40]. In particular, SGX cannot protect arbitrary memory writes. As we will show, TEEREX features a specifically tailored framework for SGX enclaves that al- against two classes of attacks: (1) side-channel attacks and lows simple proof-of-concept exploit construction to assess (2) memory corruption attacks inside the enclave. The former the discovered vulnerabilities. Our findings reveal vulnerabil- attack technique exploits shared resources (e.g., cache) to ities in multiple enclaves, including enclaves developed by steal secret information from within an enclave. This line Intel, Baidu, and WolfSSL, as well as biometric fingerprint of research has become a very active research field [65, 70]. software deployed on popular laptop brands. Especially micro-architectural side-channels have been shown to be effective for attacking SGX enclaves due to the shared micro-architectural state of enclaves and untrusted code [62]. 1 Introduction To our surprise, memory corruption attacks have been rarely investigated in the context of SGX. These attacks ex- Intel recently introduced a sophisticated trusted execu- ploit programming errors (e.g., a buffer overflow) allowing tion environment (TEE) called Software Guard Extensions an attacker to take over the enclave, hijacking the enclave’s (SGX) [30, 37, 50]. SGX allows application developers to control-flow, and perform code-reuse attacks such as return- create so-called enclaves to encapsulate sensitive application oriented programming (ROP) [57]. Further, the attacker can code and data inside a TEE that is completely isolated from also exploit these errors to corrupt enclave data variables and other applications, operating systems, and hypervisors. The pointers to launch data-oriented attacks such as information only trusted component in the SGX setting is the Intel CPU leaks or data-oriented programming (DOP) [33]. Prior re- itself. Most prominently, SGX features confidentiality and search studied the applicability of offensive and defensive integrity protection for any data that is written to its main techniques against memory corruption exploits. For instance, memory. In addition, SGX implements well-known Trusted Lee et al. [44] presented DARKROP, a code-reuse attack tech- Computing concepts such as data binding and sealing as well nique, which shows that the enclave code must not be known as remote attestation, i.e., ensuring the remote SGX enclave is to an attacker to successfully launch ROP attacks against the in a trustworthy state. Putting all these features together, this enclave. Biondo et al. [7] showed that it is easily possible to USENIX Association 29th USENIX Security Symposium 841 launch powerful code-reuse attacks due to particularities of Using TEEREX, we identified several vulnerabilities in the Intel SGX SDK bypassing existing ASLR defenses such publicly available enclave binaries developed at major compa- as SGX-Shield [56]. nies such as Intel, Baidu, and Synaptics (see Section5). Our However, prior research on memory corruption attacks al- framework features detailed vulnerability reports significantly ways assumed the existence of memory errors, but did not simplifying the construction of proof-of-concept exploits to investigate whether or to which extent such errors exist in assess the reported vulnerability. Even if no information on real-world enclaves. Due to the rather slow adoption of the the enclave is available, we are able to construct exploits (see SGX technology, this is not an easy question to answer. Ide- the fingerprint enclaves analyzed in Section 5.5 and 5.6). Our ally, SGX enclaves contain only a minimal amount of code, exploits hijack the enclave’s control-flow, effectively bypass- which can be manually audited or even formally verified to ing all security guarantees of the SGX technology. By per- not contain any programming mistakes. However, in our ex- forming root-cause analysis we identified five vulnerability perience, legacy code bases are often ported to SGX enclaves. classes that repeatedly occur in our dataset: Passing Data- These ports are often not revised to handle the specialties of Structures with Pointers (P1), Returning pointers to enclave SGX enclaves and inherit security vulnerabilities from the memory (P2), Pointers to Overlapping Memory (P3), NULL- legacy code base or introduce new security vulnerabilities Pointer Dereferences (P4), and Time-of-Check Time-of-Use particular to SGX enclaves. This is similar for newly written (P5). SGX code by developers not familiar with the peculiarities of Interestingly, among the enclaves we found vulnerable is SGX. one enclave written by Intel engineers and published as an One common aspect of all SGX enclaves is that they always open-source example enclave on Intel’s GitHub page [34]. link to an untrusted host application. The host application Another interesting finding is a vulnerability in a sample SGX loads an SGX enclave into its address space as it would do in enclave originally developed at Baidu with the Rust SGX SDK case of a shared library. Indeed, the Intel SGX SDK offers a (now an Apache Incubator project). Rust features memory C-function like interface allowing bidirectional communica- safety and as such has the potential to eradicate memory tion from the host application to the enclave. This interface is corruption attacks. However, the host-to-enclave boundary is highly critical as invalid input may lead to a privilege escala- inherently memory unsafe and as such, using memory-safe tion attack. As shown by prior research in the context of other programming languages in SGX does not automatically result privilege separation technologies, this is especially true when in secure enclave code. software is partitioned into privilege levels [13, 32]. That said, whenever an enclave is called, it must take special care to 2 Memory Corruption in SGX validate any input, particularly when the input contains code or data pointers. The lack of built-in memory safety in the common system- Contributions. In this paper, we demonstrate that the attack level programming languages C/C++ has led to a multi- surface of SGX enclaves provides new challenges for enclave tude of memory corruption vulnerabilities in the last three developers as exploitable memory corruption vulnerabilities decades [60]. These vulnerabilities allow an attacker to per- are easily introduced into enclave code due to a combina- form a limited or (often) arbitrary write to memory. Such tion of the unique threat model of SGX enclaves and the malicious writes manipulate (1) control-flow information on current prevalent programming model for SGX (i.e., the Intel stack and heap (e.g., return addresses and function pointers) SGX SDK). We introduce the first SGX vulnerability analysis or (2) so-called non-control data (e.g., decision-making vari- framework, called TEEREX, to automatically analyze enclave ables). In both cases, the attacker influences the program’s binary code based on symbolic execution (see Section4). We execution flow and eventually executes a malicious sequence implement vulnerability detectors in TEEREX that take all the of instructions.