Identifying a Critical Attestation Bypass Vulnerability in Apache Teaclave

At Mithril Security, our main focus is on building secure privacy-enhancing solutions. One of our core products, BlindAI, uses Intel SGX to provide a secure, privacy-respecting solution for AI deployment. Given our use of confidential computing technologies, we actively research and evaluate other open-source projects that employ similar technologies.

During an investigation last year, we identified a critical vulnerability in Apache Teaclave, an open-source solution designed to enable secure computations on privacy-sensitive data in a safe and user-friendly manner. Like us, Teaclave uses Intel SGX enclaves to secure data processing. Our discovery resulted from a security review of how Teaclave implements attestation, a crucial component in any Confidential Computing solution. ‘Attestation’ refers to the process of verifying the integrity and authenticity of a remote enclave to ensure that it hasn't been tampered with.

In a Nutshell:

This article will present an analysis of the vulnerability, which we dubbed the Poison Tea vulnerability, provide a proof of concept, and offer a fix for the vulnerability.

The Poison Tea vulnerability

Before we dive in, let’s talk about remote attestation. The enclave performing the secure processing is running on a remote server. Teaclave relies on remote attestation to verify that the enclave is trustworthy. It enables its users to verify the integrity of the remote service. How remote attestation is implemented can vary, but the goal is always for the client to get assurance that the software running on the server is genuine and has not been tampered with.

Since Teaclave clients communicate with the service via a TLS connection that terminates inside the enclave, the attestation is integrated at the TLS level. Their attestation workflow is documented in their repo. It works as follows: the enclave generates a self-signed certificate and adds a custom X.509 extension to it. The extension conveys the attestation evidence so that the client can verify the integrity of the enclave in addition to verifying the validity of the certificate itself (the usual certificate verification).

To ensure the protocol composition is sound, the certificate must be cryptographically bound to the attestation evidence. To achieve this goal, a cryptographic hash of the certificate's public key is embedded in the attestation report. Since only the enclave can embed such a hash in the attestation proof, the hash binds the enclave's TLS identity to the attestation.

This approach of combining TLS with remote attestation is known as ‘attested TLS’. In the context of Intel SGX, Thomas Knauth et al. described how this can be done in their paper Integrating Intel SGX Remote Attestation with Transport Layer Security. In theory, it should be relatively straightforward… but, as often in cryptography, the vulnerability usually comes from an implementation mistake. A missing check and the security of a system can be destroyed. This is exactly what happened here.

The Python SDK is missing a crucial verification step: it does not verify that the public key of the certificate presented by the server and the public key embedded in the attestation evidence is the same.

This is somewhat surprising since the server embeds the hash of its public key correctly. But since the client forgets to verify the link between the attestation evidence and the certificate public key, an attacker can spoof the identity of any Teaclave service.

The Proof of Concept: a Man in the Middle Attack against Teaclave

The vulnerability can be used to mount a Man in the Middle (MitM) attack (among others). We’ve developed a proof of concept that implements such a MitM attack. It works as follows :

1. The attacker establishes a TLS connection to the Teaclave service he wants to impersonate. He collects the TLS certificate and extracts the attestation evidence (the X.509 extension).
2. The attacker generates a new key pair, creates a certificate with the collected X.509 extension, and self-signs it.
3. The attacker creates a TLS server that relays messages from clients to a Teaclave service.
4. The attacker can eavesdrop and alter all messages between a client and the Teaclave service.

The attack enables the attacker to spy and tamper with any data exchange between the client and the server.

We tested the attack against the built-in echo example in Python with success. As part of writing this post, we are publishing the Proof of Concept on GitHub so that you can verify our findings.

This attack only works because the SDK is missing the check mentioned earlier. In practice, the attack could be mounted by any (network) attacker that can tamper with the network traffic between the client and the server or by an attacker that can tamper with DNS records or the right routing tables.

FAQ

Why the name Poison Tea?

Tea refers to the Teaclave platform. The poison part aims to reflect the severity of the vulnerability. This is also a metaphor. Since the client does not distinguish a legitimate server from an attacker, he might inadvertently share his data with an attacker. Essentially, the user might be ‘drinking the poison’ without realizing it.

How severe is the vulnerability?

The vulnerability is critical because the attestation is used in replacement for any other methods for authenticating the server. Because of the broken attestation scheme, the client loses the security guarantee provided by Intel SGX. This is already pretty bad, but on top of that, he loses the regular security that would be brought about by using a regular TLS connection with a server certificate issued by a CA (like any website/web app). So it is almost as if the client and the server communicated using plain HTTP while the user thinks they are using a very secure system… Oops!

Fortunately, the impact is somewhat limited because the bug affects only the Python SDK. It does not seem to affect the client SDK provided for other languages (C, Rust, Swift). These SDKs rely on another implementation that is not affected by the bug.

Is there a fix?

We published a patch that should fix the vulnerability. The patch adds the missing check in the _verify_report function in sdk/python/teaclave.py.

Is Teaclave still affected by the vulnerability?

Edit: After the release of this article and of the public repo with the fix, Teaclave has patched the vulnerability!

Unfortunately, it appears that Teaclave is still vulnerable. Even though we reported the vulnerability to the project maintainer 8 months ago, it seems that our fix has not yet been applied. We hope that the vulnerability will be fixed soon.

Won’t bad actors use this public disclosure to exploit the vulnerability?

Edit: After the release of this article and of the public repo with the fix, Teaclave has patched the vulnerability!

Although we would have preferred that the vulnerability be patched before publishing this post, after waiting for 8 months, we decided to make it public to raise awareness of the issue and allow users to take necessary actions. We also hope that sharing this vulnerability will enable people to learn from this mistake so that similar vulnerabilities in the attestation process are avoided in the future.

Disclosure Timeline

• On June 20, 2022, we reported a vulnerability to the Teaclave project security mailing list.
• On the same day, Mingshen Sun acknowledged receiving the report and started investigating. Less than an hour later, he confirmed the vulnerability and announced a plan to remediate it. He also mentioned that he did not have much time to devote to the project and welcomed our help to fix the issue.
• On June 21, 2022, we sent a response patch that fixes the vulnerability, and he acknowledged the reception of the fix.
• On November 7, 2022, we attempted to follow up on the progress of the vulnerability patching but received no response.
• As of March 14, 2023, to the best of our knowledge, the vulnerability remains unpatched.
• On March 21, 2023, we sent an email to inform them that we would be publishing this post.
• On March 23, 2023, He Sun adapted our fix and applied it to the Teaclave repository, closing the vulnerability.

Want to turn your SaaS into a zero-trust solution?