SoylentNews is people
SoylentNews
from the always-someone-more-sneaky-than-yourself dept.
Submitted via IRC for SoyCow3941
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 requests to a web server running in a second guest on the same machine.
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 [PDF] 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, so that the SEV mechanism fails to properly isolate and scramble parts of the VM in RAM. 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.
Source: http://www.theregister.co.uk/2018/05/25/amd_epyc_sev_vm_encryption_bypass/
(Score: 2) by takyon on Monday May 28 2018, @07:29AM (3 children)
Doesn't sound good for AMD's ambitions of displacing Intel chips in the cloud.
[SIG] 10/28/2017: Soylent Upgrade v14 [soylentnews.org]
(Score: 4, Insightful) by maxwell demon on Monday May 28 2018, @08:09AM (1 child)
It's still no worse than not having the protection to begin with. Does Intel have that protection? If not, then AMD at worst loses an advantage, but it doesn't give it a disadvantage.
Also note that, if I understand the summary correctly, this needs to exploit some service running inside the VM. Therefore there may be a way to harden software running inside the VM against this attack (e.g. by maintaining checksums that will fail if the page is remapped under the hood).
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2, Interesting) by Anonymous Coward on Monday May 28 2018, @12:20PM
Also note that those mitigation tools would not only prevent the data leak, but actively signal that something fishy is going on. And it requires just one VM running such a hardened service.
Indeed, just adding an otherwise silent low priority process running in the background and constantly checking for under-the-hood remapping should be enough to detect such an attack with high probability — and the danger of smoking-gun type detection should be enough of a deterrent even for shady providers.
(Score: 2, Interesting) by Anonymous Coward on Monday May 28 2018, @11:30AM
I would be surprised if people at AMD thought this is a 100% protection.
It does still prevent a "let's just dump all memory and scan for juicy keys" attack, an active attack where the hypervisor not only needs to be compromised but even swap out pages, cause page faults on purpose and interact with the VM has a MUCH higher risk level.
You can pretty much assume that a cloud provider doing this systematically would be found out.
Whereas without SEV, your cloud provider you just scan all your VMs and the only way anyone would have a chance to find out is by some whistleblower reporting on it.
Also note that this critically depends on a channel to extract that data, so if your VM does not communicate with everyone and their dog but instead CAREFULLY validates any connection it makes/accepts this will be far more difficult to do and may well be possible to mitigate completely (though as said, I don't think that's where SEV is aimed at, it's a "make real-world security better even if it doesn't fully fix things", not a "ooh, nice shiny theoretical fairy dust" like SGX).