TEE.fail Attack Breaks Through Intel and AMD Confidential Computing Protections
Researchers have successfully demonstrated a new attack method called TEE.fail. This technique extracts cryptographic keys and sensitive data from secure enclaves built into Intel processors (SGX, TDX) and AMD processors (SEV-SNP). These secure zones, known as Trusted Execution Environments (TEE), separate themselves from the operating system. Manufacturers built them specifically to run code securely and store cryptographic keys away from potential threats.
The Research Team and Their Findings
Teams from the Georgia Institute of Technology and Purdue University conducted this research. Their work shows that current TEE implementations fail to deliver the security their manufacturers advertise. The issue traces back to a specific hardware change: the shift to server systems using DDR5 memory.
Here's what happened. Manufacturers prioritized performance over security in DDR5 implementations. They removed integrity protection mechanisms and replay protection systems, keeping only AES-XTS encryption. This decision created a vulnerability that attackers can exploit.
What Attackers Need to Execute TEE.fail
Launching this attack requires two things:
- Physical access to the target server or system
- Root-level privileges to modify kernel drivers
I should note that these requirements make TEE.fail similar to other recent attacks. WireTap and Battering RAM also used hardware interposers to capture memory data. However, those attacks only worked with DDR4 memory. TEE.fail specifically targets DDR5, making it relevant to newer server infrastructure.
How the Attack Works in Practice
The attack method involves intercepting data as it travels across the DDR5 memory bus. The research team built a custom interposer device for their proof-of-concept, spending less than a thousand US dollars on components. They placed this device between the memory module and the motherboard, then connected their own logic analyzer to monitor traffic.
The researchers reduced the memory frequency to 3200 MT/s, which allowed them to capture encrypted data blocks moving to and from the TEE. They also modified the SGX driver in the Linux kernel. This modification let them map virtual addresses to physical addresses and force the enclave to access the same memory location repeatedly.
Through this process, they discovered something critical: AES-XTS encryption behaves deterministically in this implementation. The same memory address always produces identical ciphertext. This predictable behavior let them build a correspondence table matching addresses to encrypted values.
What the Researchers Accomplished
Using the recovered nonce and public signature data, the team reconstructed private signature keys. This breakthrough gave them several capabilities:
- Creating forged SGX and TDX attestations
- Impersonating legitimate TEEs
- Extracting signing keys from OpenSSL running in AMD SEV-SNP protected virtual machines
The same techniques worked against AMD SEV-SNP, even when Ciphertext Hiding was enabled—a feature designed to prevent exactly this type of attack.
Real-World Impact Demonstrations
During their testing phase, the researchers proved they could:
- Forge TDX attestation in Ethereum BuilderNet, gaining access to confidential data and transaction keys
- Falsify Intel and Nvidia attestations, allowing code to run outside the TEE while appearing legitimate to verification systems
- Extract ECDH private keys directly from enclaves, recover network master keys, and break confidentiality completely
In one test, they targeted a Xeon-based server and successfully obtained the Provisioning Certificate Key (PCK). This key verifies device authenticity, and compromising it undermines the entire trust chain.
Vendor Responses and Mitigation Plans
The research team followed responsible disclosure practices. They contacted Intel in April, Nvidia in June, and AMD in August. All three companies acknowledged the vulnerabilities and confirmed they're developing mitigation measures.
AMD later published a separate advisory with an important caveat: they don't plan to release patches. Their reasoning? Attacks requiring physical access fall outside their standard threat model. This position deserves scrutiny, particularly for organizations running sensitive workloads on AMD processors in shared facilities or data centers.
My Take on This Vulnerability
In my opinion, this research exposes a troubling trend in processor design. Manufacturers pushed DDR5 to market emphasizing performance benchmarks, but they removed security features that protected DDR4 systems. The decision to eliminate integrity and replay protection mechanisms created this attack surface.
Per the researchers' findings, the deterministic behavior of AES-XTS encryption in these implementations represents a fundamental design flaw. Security teams should treat this as a wake-up call, particularly those managing infrastructure in co-location facilities or cloud environments where physical security boundaries blur.
Practical Steps for Security Teams
Organizations using Intel SGX, TDX, or AMD SEV-SNP should take several actions:
- Review your physical security controls for servers running confidential computing workloads
- Monitor vendor security advisories for patches and mitigation guidance
- Assess whether your threat model includes physical access scenarios
- Consider the risk level for systems in shared hosting environments or data centers with multiple tenants
- Document which systems use these technologies and prioritize them for security reviews
The requirement for physical access doesn't eliminate the risk. Data centers, co-location facilities, and even on-premises environments can face insider threats or supply chain compromises. Dismissing physical access attacks as outside your threat model may leave critical systems vulnerable.
Looking Forward
This research raises questions about the balance between performance and security in processor design. DDR5 brought speed improvements, but removing security mechanisms created exploitable weaknesses. Future memory standards and TEE implementations must address these issues without sacrificing the protections that made earlier generations more secure.
Furthermore, the industry needs better transparency around security trade-offs in hardware design. Organizations making purchasing decisions deserve clear information about which security features exist in different memory generations and processor models.
The TEE.fail research demonstrates that trusted execution environments aren't as isolated as their marketing suggests. Security professionals should plan accordingly.
