This paper analyzes the vulnerability space arising in Trusted Execution Environments (TEEs) when interfacing a trusted enclave application with untrusted, potentially malicious code. Considerable research and industry effort has gone into developing TEE runtime libraries with the purpose of transparently shielding enclave application code from an adversarial environment. However, our analysis reveals that shielding requirements are generally not well-understood in real-world TEE runtime implementations. We expose several sanitization vulnerabilities at the level of the Application Binary Interface (ABI) and the Application Programming Interface (API) that can lead to exploitable memory safety and side-channel vulnerabilities in the compiled enclave. Mitigation of these vulnerabilities is not as simple as ensuring that pointers are outside enclave memory. In fact, we demonstrate that state-of-the-art mitigation techniques such as Intel's edger8r, Microsoft's "deep copy marshalling", or even memory-safe languages like Rust fail to fully eliminate this attack surface. Our analysis reveals 35 enclave interface sanitization vulnerabilities in 8 major open-source shielding frameworks for Intel SGX, RISC-V, and Sancus TEEs. We practically exploit these vulnerabilities in several attack scenarios to leak secret keys from the enclave or enable remote code reuse. We have responsibly disclosed our findings, leading to 5 designated CVE records and numerous security patches in the vulnerable open-source projects, including the Intel SGX-SDK, Microsoft Open Enclave, Google Asylo, and the Rust compiler.
ABI vulnerabilities
- Entry status flags sanitization
- Entry stack pointer restore
- Exit register leakage
API vulnerabilities
- Missing pointer range check
- Null-terminated string handling
- Integer overflow in range check
- Incorrect pointer range check
- Double fetch untrusted pointer
- Ocall return value not checked
- Uninitialized padding leakage
Targets
- SGX-SDK
- OpenEnclave
- Graphene
- SGX-LKL
- Rust-EDP
- Asylo
- Keystone
- Sancus
that legacy applications may also make implicit assumptions on the validity of argv and envp pointers, which are not the result of system calls.