AMD’s virtual machine encryption bypassed – NOPE!

AMD’s Epyc server chips utilize Secure Encrypted Virtualization (SEV) to automatically encrypt virtual machines on the fly while stored in memory, but researchers now say that they can get around it with a technique dubbed SEVer: “miscreants at the host level can alter a guest’s physical memory mappings, using standard page tables, so that the SEV mechanism fails to properly isolate and scramble parts of the VM in RAM“.

AMD Epyc
AMD Epyc CPU: Picture Source: AMD Press Conference

SEVered attack can recover data from encrypted VMs

The new attack could allow attackers to exfiltrate data in plaintext from an encrypted guest via a hijacked hypervisor and simple HTTP requests to a web server running in a second guest on the same machine.

SEVered-scheme
The Secure Encrypted Virtualization feature allows to encrypt and decrypt virtual machines on the fly while stored in RAM to protect them from snooping on VMs. Picture Source: Fraunhofer AISEC researchers

The team of Fraunhofer AISEC researchers, composed of  Mathias Morbitzer, Manuel Huber, Julian Horsch and Sascha Wessel, demonstrated that the SEVered technique could to bypass Secure Encrypted Virtualization protections and copy information from a virtual machine.

An attacker at the host level can alter a guest’s physical memory mappings through standard page tables, causing the failure of the Secure Encrypted Virtualization mechanism in isolating and scrambling parts of the VM in RAM.

The researchers set up a test environment running an AMD Epyc 7251 processor with SEV enabled and Debian GNU/Linux installed, running an Apache web server and an OpenSSH in two separate virtual machines. By modifying the system’s Kernel-based Virtual Machine KVM hypervisor, the experts demonstrated that it is possible to observe when software within a guest accessed physical RAM. Then the researchers sent a large number of requests at one of the services, for example fetching an HTML webpage from Apache. In this scenario, the hypervisor was able to see which pages of physical memory are being used to hold the file, then by switching the page mappings an encrypted page in another virtual machine is used by Apache to send the requested webpage, and therefore sends the automatically decrypted memory page of the other VM instead.

With this trick, the attacker could force the Apache service in leaking data from another guest.

Conclusion

This exploit only works on guest VM’s on the physical host machine that the sysadmin has access to. You can’t do it across the network, you can not do it from outside the network. It already requires the sysadmin to be dirty. This is another one of those exploits that requires several other massive security breaches before it can even be done. If you don’t trust your sysadmin, you’ve got other problems than this.

This attack does not defeat the purpose of the feature. The customer has to trust the cloud operator when it says it’s enabled the feature in the first place and in second place that it’s hypervisor (like any other part of the system) is not infected with any malware. Just like it has to trust the cloud operator with the persistent disk and VM images. Nobody is expecting that the cloud operator can deploy encrypted VM images or disks and have no access to the unencrypted data. In my opinion, it’s saying that if an Admin disables User Account Control (UAC) on Windows it defeats the purpose of the UAC feature – pointless to say that this ‘bypasses’ something then.

Did anyone monitor the AMD stock? Would be interesting to know if someone made money with such announcement. naughty

Resource

Comments are closed.

Blog at WordPress.com.

Up ↑

%d bloggers like this: