This is a brief look at EarlyAttestationBleed, a paper from Muhammad Usama Sardar and Songbo Bu which presents three vulnerabilities in confidential computing deployments from Cocos AI and Edgeless Systems’ Contrast. All of these have now been addressed and none affect Flashbots services. However there are still some useful lessons to be learned from them.
At first glance this looks similar to another paper from Sardar and other co-authors from a few months earlier: Intrahandshake.fail. But this one is much more specific, focusing on implementation details of the attestation verifier logic of two projects, whereas intrahandshake.fail is more of a general critique of a particular design paradigm of remote attested TLS protocols. That said, the discussion section also raises some general concerns with ‘early attestation’.
There are 3 vulnerabilities described in the paper, which are supported by ProVerif formal analysis:
- Cocos AI TDX - Attestation verifier fails to check
REPORT_DATAvalue (section 4.2). This is a bug in the verifier function - it receives the correctly computed expected input value but does not correctly compare it to the actual quote input value. This means the intended TLS session binding is not actually enforced. - Cocos AI SEV SNP - Verification succeed if expected input value is omitted from the validator function (section 4.3). Here the comparison of input value is correct, but the check is only made if an expected input value is passed to the function. If a value of length zero is passed, the check is omitted. The safer behavior would be that it fails if there is no provided value to compare against. This is probably the most contentious of the three, since it means a potentially dangerous library API is exposed, but not that it is actually used in a dangerous way. In the attested-TLS implementation which calls this function, the expected input value is passed correctly.
- Edgeless Systems’ Contrast (section 5). This is a bug in the workload policy logic, and not directly related to attested TLS. It relates to being able to load container images from storage controlled by the untrusted host. These could be manipulated, allowing a policy check to succeed when it should not. The maintainers attribute it to a mistake when rebasing.
Unlike the findings of Intrahandshake.fail, these are essentially implementation bugs rather than design flaws. But i think finding #3 is particularly relevant to us. Even with a strong protocol for attested channels, complex logic in policies for allowed workloads can make it very easy for bugs to go undetected. Make sure all edge cases are covered by tests!
The discussion (section 7) raises some more general concerns with early attestation (where attestation is presented before or during the TLS handshake):
- Attestation evidence exposes sensitive details about the hardware of the CVM host. These should only be exposed after client authentication.
- For long lived connections, providing evidence only at the beginning of the session may be insufficient. Post handshake attestation would allow subsequent attestation during the session.
- Adding attestation and verification to the TLS handshake makes it take significantly longer, potentially meaning timeouts need be increased. Increasing these timeouts has a negative impact on security.
These are all things which should be considered when designing attested TLS protocols.