[Paper Review] Understanding TEE Containers, Easy to Use? Hard to Trust
This paper presents a systematic security analysis of 15 TEE containers for Intel SGX, using a hybrid methodology combining a custom fuzzer (TECUZZER) and manual code review. It reveals critical isolation flaws—such as unprotected Ocall parameters, unverified return values, and incomplete SFI enforcement—demonstrating that none of the studied containers fully achieve their claimed security guarantees, despite their widespread use in confidential computing.
As an emerging technique for confidential computing, trusted execution environment (TEE) receives a lot of attention. To better develop, deploy, and run secure applications on a TEE platform such as Intel's SGX, both academic and industrial teams have devoted much effort to developing reliable and convenient TEE containers. In this paper, we studied the isolation strategies of 15 existing TEE containers to protect secure applications from potentially malicious operating systems (OS) or untrusted applications, using a semi-automatic approach combining a feedback-guided analyzer with manual code review. Our analysis reveals the isolation protection each of these TEE containers enforces, and their security weaknesses. We observe that none of the existing TEE containers can fulfill the goal they set, due to various pitfalls in their design and implementation. We report the lessons learnt from our study for guiding the development of more secure containers, and further discuss the trend of TEE container designs. We also release our analyzer that helps evaluate the container middleware both from the enclave and from the kernel.
Motivation & Objective
- To evaluate the security guarantees of TEE containers (Tcon) for Intel SGX, which are widely used to simplify confidential computing.
- To identify whether existing Tcon designs and implementations actually enforce strong isolation against untrusted OS and malicious in-enclave code.
- To uncover the gap between claimed security properties and actual implementation, particularly in critical attack surfaces like Ocall, Ecall, and in-enclave isolation.
- To develop and release a novel fuzzer (TECUZZER) for automated, kernel-integrated testing of Tcon middleware from both enclave and OS perspectives.
- To provide actionable insights and lessons for designing more secure TEE containers in future.
Proposed method
- Designed TECUZZER, a two-part fuzzer with one component inside the enclave and another in the OS kernel, to test Tcon middleware across attack surfaces.
- Used feedback-guided fuzzing to explore Ocall, exception, and side-channel surfaces, focusing on parameter and return value handling.
- Conducted manual code reviews to analyze Ecall surfaces, remote attestation, and semantic-level protections such as SFI (Software-based Fault Isolation).
- Evaluated 15 Tcon implementations using a taxonomy of security properties: threat model, TCB size, isolation techniques, side-channel protection, and remote attestation.
- Measured protection mechanisms like in-enclave memory separation, direct jump checking, and RSP spill control via static and dynamic analysis.
- Validated findings through both automated fuzzing and manual inspection of source code, focusing on real-world exploit surfaces like Iago attacks and syscall snooping.
Experimental results
Research questions
- RQ1To what extent do existing TEE containers for SGX enforce isolation between the untrusted OS and the enclave?
- RQ2Are the security claims made by Tcon developers—particularly regarding Ocall parameter and return value protection—actually enforced in practice?
- RQ3How effective are in-enclave isolation mechanisms such as SFI in preventing code injection and bypass attacks?
- RQ4What are the critical implementation flaws that undermine the security guarantees of TEE containers despite their design claims?
- RQ5Can a systematic, automated methodology like TECUZZER be used to detect subtle security weaknesses in TEE middleware?
Key findings
- None of the 15 analyzed TEE containers fully enforce their claimed security guarantees, with critical flaws present in all.
- Many Tcons fail to sanitize Ocall parameters, leaving them vulnerable to information leaks and attacks such as syscall snooping.
- A significant number of Tcons, including Deflection and Ratel, do not check syscall return values, making them susceptible to Iago-style attacks.
- Occlum and Deflection, despite claiming SFI support, fail to verify direct jump targets, enabling bypass of instrumentation and leading to unchecked memory writes.
- Chancel’s claimed protection against FS-based Iago attacks is not implemented in its released version, despite documentation suggesting otherwise.
- TECUZZER successfully uncovered previously unknown vulnerabilities by combining kernel-level instrumentation with enclave-side fuzzer control, demonstrating the feasibility of automated Tcon testing.
Better researchstarts right now
From reading papers to final review, dramatically reduce your research time.
No credit card · Free plan available
This review was created by AI and reviewed by human editors.