SEVurity: No Security Without Integrity : Breaking Integrity-Free Memory Encryption with Minimal Assumptions

Abstract

One reason for not adopting cloud services is the required trust in the cloud provider: As they control the hypervisor, any data processed in the system is accessible to them. Full memory encryption for Virtual Machines (VM) protects against curious cloud providers as well as otherwise compromised hypervisors. AMD Secure Encrypted Virtualization (SEV) is the most prevalent hardware-based full memory encryption for VMs. Its newest extension, SEV-ES, also protects the entire VM state during context switches, aiming to ensure that the host neither learns anything about the data that is processed inside the VM, nor is able to modify its execution state. Several previous works have analyzed the security of SEV and have shown that, by controlling I/O, it is possible to exfiltrate data or even gain control over the VM's execution. In this work, we introduce two new methods that allow us to inject arbitrary code into SEV-ES secured virtual machines. Due to the lack of proper integrity protection, it is sufficient to reuse existing ciphertext to build a high-speed encryption oracle. As a result, our attack no longer depends on control over the I/O, which is needed by prior attacks. As I/O manipulation is highly detectable, our attacks are stealthier. In addition, we reverse-engineer the previously unknown, improved Xor-Encrypt-Xor (XEX) based encryption mode, that AMD is using on updated processors, and show, for the first time, how it can be overcome by our new attacks.

VIA: Analyzing Device Interfaces of Protected Virtual Machines

“…Researchers have already presented security issues in AMD SEV and SEV-ES under the threat model of a malicious HV. The discovered vulnerabilities rely on the missing protection of Second Level Address Translation [30,47] and missing memory integrity protection from software attacks [25,43,61]. Both issues are addressed in the designs of AMD SEV-SNP and Intel TDX.…”

“…These solutions enhance the security of VMs, as the VM no longer depends on the HV's security or on the integrity of the cloud provider. While recent research has uncovered security issues specific to the design of the SEV technologies [21,22,25,30,42,43,46,47,60,61], little research has been done in analyzing the VM's software under this new threat model [52]. Specifically, only limited effort has been spent on analyzing security risks due to drivers which communicate with devices controlled by the now untrusted HV.…”

undeSErVed trust: Exploiting Permutation-Agnostic Remote Attestation

“…The whitepaper [27] does not explain the mode of operation in detail, but only states that AES with an 128-bit key and a physical address-based tweak is used. In [18,44] it is shown that early versions use the Xor-Encrypt (XE) or Xor-Encrypt-Xor (XEX) encryption mode with static, low entropy tweak values, while later versions use stronger, randomized tweak values. In addition, none of the encryption modes offer integrity protection.…”

“…The general idea is very similar to the approach presented in [44], where the authors leverage control over the first and last bytes of 16-byte blocks to stitch together a sequence of "payload" instructions and direct jumps, which they subsequently use to build an encryption oracle within the VM. However, we cannot change a block's content here, as this would be detected during attestation.…”

“…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.…”