The Enclave Is Lying to You - Breaking TEE Trust Boundaries Through Boot Time State

The talk argues that confidential computing platforms such as Nitro Enclaves, SEV-SNP and TDX attest the code an enclave runs, but not the runtime inputs it reads at boot. These include objects in cloud storage, configuration passed in by the host, and KMS key policies that do not require attestation. The speaker presents this as a deployment gap rather than a hardware flaw, and says the attestation measurements stay valid even when those inputs are abused.

The demonstration starts from one s3:PutObject permission on the enclave's state bucket. The uploaded key contains a directory traversal sequence. Object storage treats it as a literal string, but the enclave's file system resolves it and writes the file into the code directory, replacing a helper module that handles KMS decrypt calls. On the next boot, the replaced code runs as root, collects the parent instance's IAM session credentials, and captures plaintext data keys from KMS. The speaker then uses those keys to decrypt a database and extract signing key shares. The PCR values do not change throughout.

Several defenses held in the same assessment, including filtering of environment variable injection, certificate pinning against DNS redirection, and fuzzing of the host RPC channel. The shipped fix validates file names on the download path with an allow list and traversal checks, because signing the boot files would need a verification key baked into the image. The speaker released an open-source scanner, untrust, with about 28 checks for Nitro deployments, and urged teams to treat bootstrap scripts and boot-time inputs as part of their security boundary.