Skip to content
The methodOpen data
Back to the collection

One Glitch to Rule Them All: Fault Injection Attacks Against AMD's Secure Encrypted Virtualization

Robert Buhren, Hans Niklas Jacob, Thilo Krachenfels, Jean-Pierre Seifert

2021 · arXiv

Security & cryptographyComputer systemsEconomics
Read the paper
HN score
0
Mentions
4
Readers
4
Months
4
What’s in a score?

From the abstract

AMD Secure Encrypted Virtualization (SEV) offers protection mechanisms for virtual machines in untrusted environments through memory and register encryption. To separate security-sensitive operations from software executing on the main x86 cores, SEV leverages the AMD Secure Processor (AMD-SP). This paper introduces a new approach to attack SEV-protected virtual machines (VMs) by targeting the AMD-SP. We present a voltage glitching attack that allows an attacker to execute custom payloads on the AMD-SPs of all microarchitectures that support SEV currently on the market (Zen 1, Zen 2, and Zen 3). The presented methods allow us to deploy a custom SEV firmware on the AMD-SP, which enables an adversary to decrypt a VM's memory. Furthermore, using our approach, we can extract endorsement keys of SEV-enabled CPUs, which allows us to fake attestation reports or to pose as a valid target for VM migration without requiring physical access to the target host. Moreover, we reverse-engineered the Versioned Chip Endorsement Key (VCEK) mechanism introduced with SEV Secure Nested Paging (SEV-SNP). The VCEK binds the endorsement keys to the firmware version of TCB components relevant for SEV. Building on the ability to extract the endorsement keys, we show how to derive valid VCEKs for arbitrary firmware versions. With our findings, we prove that SEV cannot adequately protect confidential data in cloud environments from insider attackers, such as rogue administrators, on currently available CPUs.

Metadata: arXiv. Abstracts retain their original authors’ rights.

In the conversation

Original HN comments, with labels from simple text rules. A label describes the whole comment and may miss context or irony. Read the discussion to make up your own mind. About the labels

4 selected excerpts · 4 total mentions

dongcarl
Neutral mention · rule
I actually spent a few months prototyping SGX/SEV VPNs before settling on a Multi-Party Relay scheme for obscura.net Things may have changed since mid-2023 but here were my takeaways: ----- Re: Vendor lock-in Vendor lock-in is (was?) a huge problem (at least for process-based TEEs) Process-based TEEs (mainly SGX) operated by providing essentially a whole new system abstraction. At the base level, there was no `libc`-like or `POSIX`-like interfaces, only Intel specific ones. This is why there are projects like [Gramine](https://github.com/gramineproject/gramine) and [Fortanix](https://github.com/fortanix/rust-sgx) that aimed to provide a more `libc`/`POSIX`-like interface…
Read the full comment
to developers, even though this was the leakiest of abstractions (you can’t even create a UDP socket). This is not only a problem in terms of Developer Experience though, this is also a huge problem for vendor lock-in. Porting things were nigh impossible, and you’re stuck with the Intel platform. I think Intel is making a genuine attempt at making a good TEE right now, but what if Intel decides to axe their budget for TEEs or drop support altogether? *Possible solution*: Use VM-based TEE abstractions like SEV or TDX, which can run a full VM, which is at least a more portable solution and has a full Linux environment (with some caveats). ----- Re: Trust model A convincing trust model for TEE VPNs was possible, but a big engineering challenge. 1. TEEs without remote attestation and reproducible builds of the backend are near-meaningless: If a VPN operator hands you a proof co-signed by Intel that they’re running in SGX… so what? They could simply be running a data-harvesting pipeline in SGX. *Possible solution**: A **remote attestation** of *what they’re running*, which requires that they have a reproducible build of *what they’re running*, and for the remote attestation to verifiably attest to that reproducible build 2. For VPNs: it is always possible to hand the user a *remote attestation* to one server, then just swap out that server for another when the user is connecting. *Possible solution**: A way to link the **remote attestation** to what you’re connecting to. ----- Re: Vulnerabilities Back in mid-2023, it seemed like vulnerabilities in different TEEs were still popping up. However, I don’t want to overstate them here or engage in FUD: over time, it seems like the newly revealed vulnerabilities were becoming more and more theoretical attacks hard to carry out in the real world. I think this is something that improves over time as the different TEE platforms matures, but *relying solely on TEEs* to make claims about privacy and security seemed a bit shaky to me. This was the final straw for me for why not to start with TEEs back in 2023: Given that we wanted to avoid vendor lock-in as much as possible, we only had AMD SEV as a choice at the time. I came across this vulnerability ([GitHub](https://github.com/PSPReverse/amd-sp-glitch), [arXiv](https://arxiv.org/abs/2108.04575)) and (from my reading) it was very practical and almost unforgive-able, see [this image](https://forum-uploads.privacyguidesusercontent.com/original/...). Funnily enough, you can even see my post in 2023 to understand if the AMD VLEK addition mitigated the vulnerability ([GitHub comment](https://github.com/PSPReverse/amd-sp-glitch/issues/3)). *Possible solution*: MPR but each hop is a different TEE implementation. That way an attacker would have to have an exploit for all the TEE implementations to break the security model. ----- Anyway, these were my thoughts back in 2023, things like hardware vulnerabilities may have changed since then, and certainly the availability of Intel TDX (another VM-based TEE) makes vendor lock-in much better, but the “Trust Model” challenges still remain. That is a big engineering challenge though, and not a fundamental problem with TEEs, so I’m very cautiously optimistic!
Original comment A privacy VPN you can verify
natesales
Neutral mention · rule
An attacker would need to compromise our build pipeline to publish a backdoored VM image [1] and extract key material to forge an attestation from the hardware [2]. The build process publishes a hash of the code to Sigstore’s transparency log [3], which would make the attack auditable. That said, a sufficiently resourced attacker wouldn’t need to inject a backdoor at all. If the attacker already possesses the keys (e.g. the attacker IS the hardware manufacturer, or they’ve coerced the manufacturer to hand the keys over), then they would just need to gain access to the host server (which we control) to get access to the hypervisor, then use their keys to read memory or…
Read the full comment
launch a new enclave with a forged attestation. We're planning on writing a much more detailed blog post about "how to hack ourselves" in the future. We actually plan to do an experiment at DEFCON, likely next year where we gives ssh access to a test machine running the enclave and have people try to exfiltrate data from inside the enclave while keeping the machine running. [1] https://github.com/tinfoilsh/cvmimage [2] https://arxiv.org/abs/2108.04575 [3] https://github.com/tinfoilsh/cvmimage/attestations
Original comment Launch HN: Tinfoil (YC X25): Verifiable Privacy for Cloud AI
nazgulsenpai
Neutral mention · rule
AMD was impacted by a Meltdown-style attack[0], and the AMD Secure Encrypted Virtualization voltage attack[1] that, recently, was used to jailbreak Teslas. This culture of corporate fandom "console wars" mentality that has permeated almost every facet of technical discussion makes me nauseated. (not directed at parent -- just ranting.) [0] https://www.amd.com/en/resources/product-security/bulletin/a... [1] https://arxiv.org/pdf/2108.04575.pdf
Original comment AMD Inception Mitigations Can Lower Performance of CPUs by Up to 54%
exfalso
Neutral mention · rule
In terms of security these technologies are (mostly) strictly worse than SGX, and there hasn't been nearly enough security research done on them. Also, the physical attack vectors remain (e.g. https://arxiv.org/abs/2108.04575). A small but interesting counterexample is x86 TSC: with SGX the MSR is modifiable by ring 0, with AMD SEV-SNP it is protected from the hypervisor. The real value of these newer technologies is not increased security, but rather increased usability. (Also, small sidenote: TDX relies on SGX.) I think the biggest contribution that cloud providers can bring to the table in the mid-term is mitigation of the physical attack vector. This would involve inserting themselves as a second root of trust in attestations (SEV has explicit support for this), which would mean that a real world attack would require collusion of multiple parties (pick 2 of Hardware vendor, Cloud provider, Software vendor).
Original comment Intel deprecates SGX on Core series processors

Keep following the thread.

More in Security & cryptography

More from the same topics.

2014arXiv

Explaining and Harnessing Adversarial Examples

Ian J. Goodfellow, Jonathon Shlens, Christian Szegedy

Several machine learning models, including neural networks, consistently misclassify adversarial examples---inputs formed by applying small but intentionally worst-case perturbations to examples from the dataset, such that the perturbed input results in the model outputting an incorrect answer with high confidence.

Machine learningSecurity & cryptography
16 mentions11 months
1.5HN score