Recently, wiretap.fail, battering RAM and tee.fail attacks were made public. These are not applicable to BuilderNet or any Flashbots products and do not enable frontrunning or unbundling. These attacks do not deviate from the current threat model so no updates or changes are required. We wanted to inform our users and broader community of the nature of this attack, how to reason about it in the context of BuilderNet security model today, highlight the importance of our ongoing TEE hardware and software security research in light of these publications.
The TEE.fail paper specifically demonstrated the attack on a non-production BuilderNet instance run in a lab. This is not representative of the security model that the BuilderNet production system operates under. The publications all employ similar methodology to target Intel SGX, Intel TDX, and AMD SEV, and require physical access to TEE hardware. Precisely to avoid these kinds of attacks, our current systems do not allow operators to run outside vetted cloud environments.
We appreciate and welcome the research community’s ongoing attention to TEE security. We see the potential of the technology and, as an R&D organization, recognize that its potential cannot be fully harnessed without rigorous attention of security experts.
What is the attack?
In each of the listed attacks, a bus interposer is physically inserted between the CPU and off-chip RAM in order to intercept or redirect memory traffic. The attack exploits mechanisms which were not intended to withstand physical attack. Bus interposer attacks are a well understood class of attacks and, in this case, were made possible when Intel decided to drop stronger memory protections and move to the cloud-only setting.
Why BuilderNet is not impacted
BuilderNet is currently under active R&D and is operating in a permissioned model during this phase. As a requirement for joining the permissioned set, all operators must deploy nodes in approved cloud environments. Thus these attacks, which require physical access, are not feasible under the current trust model.
The paper also mentions forging Azure TPM attestation quotes. However, this is insufficient to bypass BuilderNet’s verification and access controls which rely on both attestations and IP allowlists.
R&D Towards Permissionlessness
While the listed attacks fall within the scope of the attack model we planned for and don’t compromise any production systems, they do serve to highlight the importance of our decentralisation roadmap. BuilderNet is in early R&D phase going from replicated (today) towards distributed, fault tolerant and geo-decentralized future. Each step in our progression requires stronger guarantees of execution integrity and infrastructure independence.
As we move toward permissionless participation, we are co-designing a Proof-of-Cloud system that allows participation from any machines provably hosted in approved datacenters. In order to accomplish this, we are working with researchers and industry players to extend attestations to datacentres and push forward existing initiatives. Work on Flashtestations and DStack KMS is making TEE attestation and governance legible and enforced on-chain. At the same time, through our contributions to DStack, an open source TEE software stack for app developers, we are helping to shape and explore security practices and tradeoffs.
Our long-term goal is to evolve BuilderNet beyond reliance on trusted infrastructure and toward cryptographically verifiable compute. Our cryptography research team is working on applying cryptographic schemes to strengthen the security model and reduce dependence on external trust.
At the same time, we do not believe that TEEs can be obviated. Attacks like these are exactly why we launched the Trustless TEE Initiative, a public effort to build hardware that remains secure even against supply chain and physical adversaries.We are also closely following other groups tackling similar challenges in related domains such as AI, robotics, and autonomous systems. Notable examples include FlexHEG, which focuses on physically secure hardware for cloud AI; spaceTEE, which isolates compute by verifying it runs in satellites; and open-source secure silicon projects like Tropic Square, OpenTitan and Vitalik’s new Vensa effort.
Overall, we are optimistic about the future of TEE security and the growing R&D ecosystem working to make it trustless by design.
Where can I learn more
BuilderNet
- Our docs at https://buildernet.org/
- The BuilderNet section of the forum
- The BuilderNet telegram.
Flashbots TEE R&D
- DCEA (Proof-of-Cloud)
- Flashtestations
- Supply Chain Attack and Defense
- Trustless TEE
- Network Attacks
- TEE Governance
- Reproducible Builds
- TEE Sandboxes
- Adding sealing to TDX
- See more collective.flashbots.net and our GitHub