This article is more than 1 year old

Epyc fail? We can defeat AMD's virtual machine encryption, say boffins

Evil hypervisors can lift plaintext info out of ciphered memory, it is claimed

Updated German researchers reckon they have devised a method to thwart the security mechanisms AMD's Epyc server chips use to automatically encrypt virtual machines in memory.

So much so, they said they can exfiltrate plaintext data from an encrypted guest via a hijacked hypervisor and simple HTTP or HTTPS requests.

AMD's data-center processors, as well as its Ryzen Pro line, support what's called Secure Encrypted Virtualization. This decrypts and encrypts virtual machines on the fly while stored in RAM so that the host operating system, hypervisor, and any malware on the host computer, cannot snoop on protected VMs. Each virtual machine is assigned an address space ID which is linked to a cryptographic key to cipher and decipher data as it moves between memory and the CPU cores. The key never leaves the system-on-chip, and each VM gets its own key.

That means, in theory, not even a malicious or hijacked hypervisor, kernel, driver, or other privileged code, should be able to inspect the contents of a protected virtual machine, which is a good safety feature for multi-tenant cloud platforms. Now you can be sure that a BOFH isn't peeking into your guest instance. AMD marketed SEV as a feature to stop cloud and off-premises hosts from spying on sensitive virtual machines.

However, a technique dubbed SEVered can, it is claimed, be used by a rogue host-level administrator, or malware within a hypervisor, or similar, to bypass SEV protections and copy information out of a customer or user's virtual machine.

The problem, said Fraunhofer AISEC researchers Mathias Morbitzer, Manuel Huber, Julian Horsch and Sascha Wessel, is that miscreants at the host level can alter a guest's physical memory mappings, using standard page tables, bypassing the SEV's protection mechanism. Here's the team's outline of the attack:

With SEVered, we demonstrate that it is nevertheless possible for a malicious HV [hypervisor] to extract all memory of an SEV-encrypted VM [virtual machine] in plaintext. We base SEVered on the observation that the page-wise encryption of main memory lacks integrity protection.

While the VM’s Guest Virtual Address (GVA) to Guest Physical Address (GPA) translation is controlled by the VM itself and opaque to the HV, the HV remains responsible for the Second Level Address Translation (SLAT), meaning that it maintains the VM’s GPA to Host Physical Address (HPA) mapping in main memory. This enables us to change the memory layout of the VM in the HV. We use this capability to trick a service in the VM, such as a web server, into returning arbitrary pages of the VM in plaintext upon the request of a resource from outside.

In the Epyc center: More Zen server CPU specs, prices sneak out of AMD


This is not the first time eggheads have uncovered shortcomings in SEV's ability to lock down VMs: previous studies have examined how the memory management system can be exploited by hackers to poke inside encrypted guests. Fraunhofer AISEC's study, emitted on Thursday this week, takes this a step further, demonstrating that, indeed, the entire memory contents of a virtual machine could be pulled by a hypervisor even when SEV is active.

To show this, the researchers set up a test system powered by an AMD Epyc 7251 processor with SEV enabled and Debian GNU/Linux installed, running the Apache web server in a virtual machine. They then modified the system's KVM hypervisor to observe when software within the guest accessed physical RAM.

By firing lots of HTML page requests at the Apache service, the hypervisor can see which pages of physical memory are being used to hold the file. It then switches the page mappings so that an encrypted memory page used by Apache to send the requested webpage sends a memory page from another part of the guest – a page that is automatically decrypted.

That means Apache leaks data from within the protected guest. Over time, the team was able to lift a full 2GB of memory from the targeted VM.

"Our evaluation shows that SEVered is feasible in practice and that it can be used to extract the entire memory from a SEV-protected VM within reasonable time," the researchers wrote. "The results specifically show that critical aspects, such as noise during the identification and the resource stickiness are managed well by SEVered."

A spokesperson for AMD was not available for comment. The team noted there are a few steps the chipmaker could take, though, to isolate the transition between the host and guest physical address process to mitigate the described attack.

"The best solution seems to be to provide a full-featured integrity and freshness protection of guest-pages additional to the encryption, as realized in Intel SGX. However, this likely comes with a high silicon cost to protect full VMs compared to SGX enclaves," they explained.

"A low-cost efficient solution could be to securely combine the hash of the page’s content with the guest-assigned GPA." ®

Updated to add

AMD has been in touch to say it is working with developers to shore up system-level software from the above described attack. A spokesperson told us:

AMD’s Secure Encrypted Virtualization (SEV) is designed to help protect virtual machines from inadvertent vulnerabilities in typical operating environments. SEV provides what was previously unavailable protection of memory in a virtual environment and is a first step to improving security for virtualization.

AMD is currently working with the ecosystem to protect against vulnerabilities that are more difficult to exploit, such as malicious hypervisor attacks like those recently detailed by German researchers.

We are also happy to clarify that the Apache server used to exfiltrate information was running within the encrypted guest – that is, an HTTP web service within an SEV-encrypted virtual machine was used to lift plaintext data out of said protected guest.

"The memory can be extracted from any system that can access the service," one of the researchers, Mathias Morbitzer, told The Register.

"Our attack requires access to the HV to perform the remapping. Therefore, as we are already working on the HV anyway, we also use the HV for data extraction. However, one might as well use another VM, or any other system, as long as it can access the service.

"The content of the response will be a memory dump, which can be viewed with any program, such as a hex editor. Alternatively, one could for example feed the dump to a script that looks for secrets such as TLS keys."

More about


Send us news

Other stories you might like