Exploiting Interfaces of Secure Encrypted Virtual Machines

Radev, Martin; Morbitzer, Mathias

doi:10.1145/3433667.3433668

Cited by 9 publications

(8 citation statements)

References 6 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…SEV-ES effectively mitigates attacks that require access to a guest's register state, and SEV-SNP mitigates attacks that alter a guest's memory layout or content. A different direction is explored in [44]. The authors present issues inside the Linux kernel of SEV-enabled guests that allow the circumvention of SEV's security properties.…”

Section: Related Workmentioning

confidence: 99%

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

Buhren¹,

Jacob²,

Krachenfels³

et al. 2021

Preprint

View full text Add to dashboard Cite

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.

show abstract

Section: Related Workmentioning

confidence: 99%

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

Buhren¹,

Jacob²,

Krachenfels³

et al. 2021

Preprint

View full text Add to dashboard Cite

show abstract

“…Radev et al [37] described multiple attacks, exploiting insufficient value sanitization at the HV to VM boundary. For example, they showed how to trick the VM into treating arbitrary memory accesses as Memory Mapped I/O (MMIO), as well as into using malicious virtualized cryptographic accelerators provided by the HV.…”

Section: Related Workmentioning

confidence: 99%

“…A fundamental challenge for TEEs is having to guarantee their promises against attackers with system level privileges, resulting in a large variety of attacks [15,16,32,37,42,44]. In this work, we extend the arsenal of attacks against TEEs and in particular against AMD SEV, with an attack targeting and circumventing its very core of trust, the remote attestation.…”

Section: Introductionmentioning

confidence: 99%

undeSErVed trust: Exploiting Permutation-Agnostic Remote Attestation

Wilke,

Wichelmann,

Sieck

et al. 2021

Preprint

View full text Add to dashboard Cite

The ongoing trend of moving data and computation to the cloud is met with concerns regarding privacy and protection of intellectual property. Cloud Service Providers (CSP) must be fully trusted to not tamper with or disclose processed data, hampering adoption of cloud services for many sensitive or critical applications. As a result, CSPs and CPU manufacturers are rushing to find solutions for secure and trustworthy outsourced computation in the Cloud. While enclaves, like Intel SGX, are strongly limited in terms of throughput and size, AMD's Secure Encrypted Virtualization (SEV) offers hardware support for transparently protecting code and data of entire VMs, thus removing the performance, memory and software adaption barriers of enclaves. Through attestation of boot code integrity and means for securely transferring secrets into an encrypted VM, CSPs are effectively removed from the list of trusted entities. There have been several attacks on the security of SEV, by abusing I/O channels to encrypt and decrypt data, or by moving encrypted code blocks at runtime. Yet, none of these attacks have targeted the attestation protocol, the core of the secure computing environment created by SEV. We show that the current attestation mechanism of Zen 1 and Zen 2 architectures has a significant flaw, allowing us to manipulate the loaded code without affecting the attestation outcome. An attacker may abuse this weakness to inject arbitrary code at startup-and thus take control over the entire VM execution, without any indication to the VM's owner. Our attack primitives allow the attacker to do extensive modifications to the bootloader and the operating system, like injecting spy code or extracting secret data. We present a full end-to-end attack, from the initial exploit to leaking the key of the encrypted disk image during boot, giving the attacker unthrottled access to all of the VM's persistent data.

show abstract

“…The Linux kernel uses this instruction to create entropy at boot time, which is among others required to initialize KASLR. Therefore, a malicious HV manipulating the results of the RDTSC instruction at boot time will be able to pin the KASLR offset [27], allowing us to guess the KASLR offset used by the VM. However, this method requires a malicious HV to actively interfere with the VM at boot time.…”

Section: A Identifying the Trigger Pointmentioning

confidence: 99%

“…SEVerity allows a malicious HV to inject truly arbitrary code into the VM's encrypted memory and cause the VM to execute the injected payload. Contrary to previous work, SEVerity does not limit itself to software bugs [27] or any memory encryption algorithm that is specific to a CPU version [23], [25], [26]. Further, SEVerity does not require any out-of-band collected knowledge of in-VM applications [20]- [25], [31].…”

Section: Introductionmentioning

confidence: 99%