AMD SEV OMG: Trusted execution in VMs undone by bad hypervisors' cache meddling

Boffins in Germany and Austria have found a flaw in AMD's SEV trusted execution environment that makes it less than trustworthy.

The researchers – Ruiyi Zhang, Lukas Gerlach, Daniel Weber, Lorenz Hetterich, and Michael Schwarz (all with CISPA Helmholtz Center for Information Security), Youheng Lü (independent), Andreas Kogler (Graz University of Technology) – call the vulnerability CacheWarp for its ability to create inconsistencies between cache lines and memory.

Modern CPUs support virtual memory to keep processes isolated and allow multi-tenant operations. This involves mapping virtual memory to physical memory via page tables so tenant and system processes occupying the same space can be separately managed.

Caches, temporary storage space, help reduce latency when data is moved in and out of memory. CacheWarp works by interfering with this process, using the Advanced Programmable Interrupt Controller or APIC timer to precisely interrupt context switches between guest and host processes.

A successful attack – which assumes an attacker is running a malicious hypervisor protected by AMD SEV – could allow arbitrary code execution within a guest VM, the exposure of sensitive data, or privilege escalation.

CacheWarp (CVE-2023- 20592) is a software-fault attack that targets AMD Secure Encrypted Virtualization (SEV), a CPU extension for securely separating virtual machines (VMs) from their hypervisor. It affects all versions of SEV, including SEV-ES and SEV-SNP, though exploitation is more difficult with this latter variant.

SEV is intended to guard against the possibility of a malicious hypervisor, a level of security not provided by VMs.

In a paper titled, "CacheWarp: Software-based Fault Injection using Selective State Reset," the team explains that CacheWarp is not a transient execution attack or a side-channel attack like Spectre and Meltdown. Rather, it is a software-based fault attack along the lines of Rowhammer or Plundervolt, and relies on introducing errors, specifically memory (page table) errors to achieve its ends.

"CacheWarp is based on our analysis of the invd instruction, which shows that invalidating dirty cache lines without triggering a write-back is feasible on AMD CPUs, even if AMD SEV is enabled," the team explains in the paper.

"Specifically, a malicious hypervisor can selectively drop any writes of an AMD SEV-ES and SEV-SNP guest that occurred at an attacker-chosen point. The consequence of such a drop is that the VM architecturally uses stale data."

• Ubuntu for Arm64 laptops (plus RISC kit)
• Epyc 3 ain't done yet – AMD extends availability to 2026, unleashes six more SKUs
• Hardware hacker: Walling off China from RISC-V ain't such a great idea, Mr President
• Intel CEO Gelsinger dismisses 'pretty insignificant' Arm PC challenge

When the VM uses stale data, its behavior can be altered. For example, an attacker could use the technique to revert a variable to a previous state that indicated the user was authenticated. Thus the attacker would become authenticated.

The researchers describe three case studies in which they extract the private key from an IPP RSA implementation, access an OpenSSH server without credentials, and gain root privileges via the sudo tool.

The boffins say that AMD was notified of their findings on April 25, 2023, and plans to issue a microcode patch for SEV-SNP and an SEV firmware update for Zen 3 EPYC Milan CPUs.

"Ultimately, CacheWarp has to be fixed on the hardware level," they state in their paper. "One solution is to prevent the invd instruction from being used if AMD SEV is enabled."

They allow a microcode update to alter the invd instruction so it behaves like the non-exploitable wbinvd instruction would suffice. And they plan to publish relevant code on GitHub.

Asked to comment, an AMD spokesperson said the biz plans to publish details on Tuesday. You can find those bulletins here and here. ®