A team of British and Belgium academics looked at eight open-source enclave SDKs and found 35 vulnerabilities that can be exploited to run malicious code inside a computer's most secure area.
A trusted execution environment (TEE), also known as an enclave, is a secure area of a CPU that can be isolated at the hardware or software level from the rest of the computer.
Modern-day computing systems, and especially cloud computing servers, often rely on enclaves. Laptops or desktops use enclaves to safely store an app's passwords or encryption keys, while servers use enclaves to isolate the data of different cloud server tenants. While desktop apps may not use enclaves to safeguard their data all the day, modern-day cloud computing wouldn't be possible without them. The CPU enclave is at the heart of every major cloud hosting service, and is what makes hypervisor technologies possible.
Currently, enclaves are supported by various underlying hardware-based technologies such as Intel's Software Guard Extensions (SGX), ARM's TrustZone, RISC-V's Keystone, Qualcomm's Secure Execution Environment (QSEE), or KU Leuven's Sancus.
Developers who want to build software that takes advantage of an enclave and use its isolated environment to store sensitive information must use a software development kit (SDK).
These SDKs provide an interface so an app can interact with the underlying enclave technology. But besides interfacing, the role of these SDKs is to also shield the enclave at a software level from malicious code that may be running at the OS level. For example, an SDK must be able to detect malicious instructions that may be used in attempts to exfiltrate data from the enclave.
It's these enclave SDK shielding features that the research team looked at in their recent work. More specifically, academics looked at the eight SDKs:
The research team's work involved auditing all eight projects by performing manual code reviews of possibly vulnerable SDK functions that could be exploited for attacks.
"This was, indeed, quite a long-running project," Jo Van Bulck, an academic from KU Leuven, involved in the research told ZDNet in an email.
"Some of the findings even date back to 2015, when I studied the security of the Sancus research platform. After that, somewhere in 2016, I found a very similar issue in Graphene and reported it, and it got fixed," Van Bulck added.
"We had an intuition there might be more there but were busy with other things and somewhat forgot about this attack surface. Then in 2018, I found CVE-2018-3626 when reviewing Intel software for Spectre vulnerabilities. Then in November 2018, I met David Oswald and the other people from Birmingham University at a research conference in London, and we started talking about how all of these findings fit in a bigger picture, and we set off to investigate this attack surface more systematically together.
"As part of our research, we developed a sort of intuitive methodology to make these code reviews more feasible. Basically, we focus on following the code path in and out of the victim enclave software with an 'attacker hat' on thinking about what could go wrong each step of the way," Van Bulck told ZDNet.
"Crucially, since we only focus on the entry/exit code, the amount of lines of code to digest is way more manageable than having to review all of the code (which would be completely infeasible). It also greatly helped to develop a scientific classification scheme for these vulns such that we saw the same mistakes being repeated across independent projects, and we often found one vulnerbility and then reviewed the other projects and found the same oversights there."
Vulnerabilities are fully exploitable, not just theoretical
In total, researchers said their manual code audit found 35 vulnerabilities across all the eight SDKs, of which, five received a CVE identifier.
"We practically exploit these vulnerabilities in several attack scenarios to leak secret keys from the enclave or enable remote code reuse," the research team said, describing the severity of the vulnerabilities they found.
"The five CVEs are assigned by Intel and Microsoft for the vulnerabilities we found in their production-quality real-world deployed software. And we also show how these are indeed exploitable with quite worrisome consequences (e.g. leading to memory corruption and full AES key recovery)," Van Bulck told ZDNet.
"For the other vulnerabilities, these were found in open-source projects where it's less clear how widely deployed they are. For some like Sancus and Keystone, it's clear these are only research prototypes and no real-world impact. However, for others like Graphene and LKL it's less clear," Van Bulck told us, when we asked why the other vulnerabilities didn't receive a CVE.
"There's also one vulnerability in an SGX backend for the official Rust compiler, which is a more subtle to exploit but still considered quite dangerous."
All issues were reported to their respective SDK vendors earlier this year, and the research team said they worked with the project maintainers to fix all vulnerabilities.
"In each case, the issues have been verified and acknowledged by the developers. In the case of Intel, this can be tracked via CVE-2018-3626 and CVE-2019-14565, and for Microsoft via CVE-2019-0876, CVE-2019-1369, and CVE-2019-1370," researchers said.
"The weakness found in Fortanix-EDP led to a security patch in the Rust compiler. For other open-source projects, our reports have been acknowledged in the respective commits or issues on GitHub," they also added.
Following their presentation, proof-of-concept code to reproduce the vulnerabilities will be released on GitHub, along with a whitepaper, entitled "A Tale of Two Worlds: Assessing the Vulnerability of Enclave Shielding Runtimes."
Academics from the University of Birmingham, in the UK, and the Catholic University in Leuven (KU Leuven), Belgium, contributed to this research project.
Earlier this year, in August, some of the world's biggest tech companies, such as Alibaba, Arm, Baidu, Google Cloud, IBM, Intel, Microsoft, Red Hat, Swisscom, and Tencent, founded the Confidential Computing Consortium, an industry group dedicated to improving and accelerate the adoption and broad use of secure enclaves.