UPDATE
Virtual machines that use AMD’s Secure Encrypted Virtualization (SEV), a hardware-based encryption scheme, have been found to be vulnerable to the same malicious hypervisor attacks that can affect all processors. A successful attack can extract the full contents of their main memory in plaintext.
SEV is a feature specifically designed for securely encrypting VM memory to protect it from remote and physical attackers. It is meant to give users a modicum of control over their virtual environments, so they don’t have to place all of their trust in the vendors providing the virtualized environment.
Hypervisors act as controllers for VMs and as such, can easily access sensitive data stored in VM memory, such as keys, passwords or classified information. SEV was built to encrypt individual VMs using a secure processor (SP). It’s a hardware-based approach that removes the memory from being open to prying hypervisor eyes – in theory.
Ironically, SEV can be “SEVered,” so to speak, and doesn’t protect VMs from attacks from malicious hypervisors that re-map the memory.
“SEVered [the coined term for the attack method] neither requires physical access nor colluding virtual machines, but only relies on a remote communication service, such as a web server, running in the targeted virtual machine,” explained Fraunhofer AISEC researchers Mathias Morbitzer, Manuel Huber, Julian Horsch and Sascha Wessel, in an research paper (PDF) released last week. “SEVered reliably and efficiently extracts all memory contents, even in scenarios where the targeted virtual machine is under high load.”
AMD confirmed the issue to Threatpost, stressing that the attack is a known quantity that can be used to affect any VM processor, not just those encrypted with SEV — and that it doesn’t result in breaking SEV’s encryption. A spokesperson said that while SEV never claimed to protect memory against this type of attack, the company is working on improvements that can help address malicious hypervisors.
“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,” the company said in a provided statement.
The chipmaker also characterized SEV as continuing to protect VM from inadvertent vulnerabilities in typical operating environments, and said that it remains a unique element of security that offers an extra layer of protection that wouldn’t otherwise be there.
“SEV provides what was previously unavailable protection of memory in a virtual environment and is a first step to improving security for virtualization,” the company said in its statement.
Malicious Mapping
According to the German researchers, the problem is that SEV’s encryption of main VM memory lacks integrity protection. To wit, even with SEV enabled, hypervisors are responsible for second-level address translation (SLAT), meaning that they maintain the VM’s General Physical Access (GPA) to Host Physical Address (HPA) mapping in main memory. That allows an attacker with access to the hypervisor to change that mapping and identify linked information when the RAM is queried.
“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,” the paper outlined. “We first identify the encrypted pages in memory corresponding to the resource, which the service returns as a response to a specific request. By repeatedly sending requests for the same resource to the service while re-mapping the identified memory pages, we extract all the VM’s memory in plaintext.”
After completion, attackers can cover their tracks by restoring the mapping of the resource pages to their original HPAs.
The paper’s authors said that SEVered neither requires detailed knowledge of the target VM or service, nor a malicious process running inside the VM; however, several techniques have to be combined to reliably identify the encrypted pages that are being queried – and this supports AMD’s characterization of the attack vector as being difficult to use.
Real-World Feasibility
Exploitation may be difficult, but it is certainly possible, as the researchers demonstrated.
Using a Debian GNU/Linux test server running on an AMD Epyc 7251 processor with SEV enabled, they spun up an Apache web server and an OpenSSH in separate VMs. They then modified the system’s KVM hypervisor, so that it could see when software accessed physical RAM. Within seconds, after multiple requests for the same information, they were able to narrow down what resource corresponded with which query, in order to extract it.
In this way, the hypervisor eventually was able to extract 2GB of memory from the victim machine.
“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 [activity] during the identification and the resource stickiness are managed well by SEVered.”
Mitigations
Unfortunately, there is no immediate fix for the issue. And, researchers said, finding one will be tricky.
For one, shoring things up in software isn’t an answer. “Integrity protection can hardly be achieved in software as the VM would require efficient and reliable software mechanisms to protect itself from modification of memory mappings and contents, e.g., by maintaining hashes in a safe location,” the researchers noted. “Both mechanisms seem hard to realize to reliably protect an entire VM at all times, and would probably incur an intolerable performance overhead. We thus consider software-based countermeasures insufficient solutions against our attack.”
Hardware-based solutions come in two flavors. First, a modification of AMD SEV to include the integrity protection. That’s likely a costly endeavor and would require labor and overhead to install.
The second approach is more low-cost and efficient. “Securely combine the hash of the page’s content with the guest-assigned GPA,” researchers noted. “This ensures that pages cannot easily be swapped by changing the GPA to HPA mapping. Adding a nonce additionally ensures that an old page for the GPA cannot be replayed into the guest by a malicious [hypervisor].”
This story was updated at 11:50 a.m. on May 30, 2018, to reflect clarifying statements from AMD.
