Subscribe to our Threatpost Today newsletter

Join thousands of people who receive the latest breaking cybersecurity news every day.

The administrator of your personal data will be Threatpost, Inc., 500 Unicorn Park, Woburn, MA 01801. Detailed information on the processing of personal data can be found in the privacy policy. In addition, you will find them in the message confirming the subscription to the newsletter.

*

*

I agree to my personal data being stored and used to receive the newsletter

*

I agree to accept information and occasional commercial offers from Threatpost partners

The administrator of your personal data will be Threatpost, Inc., 500 Unicorn Park, Woburn, MA 01801. Detailed information on the processing of personal data can be found in the privacy policy. In addition, you will find them in the message confirming the subscription to the newsletter.

SEVered Attack Extracts the Memory of AMD-Encrypted VMs

Virtual machines that use AMD’s hardware-based encryption scheme are vulnerable to attacks that can extract the full contents of their main memory – in plaintext.

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.

Discussion

This is NOT a remote exploit. The Administrator must FIRST disable the security from within.
There is no defense against an INSIDE attack.
There is no such thing as 100% security. The human factor will always bolix the works.
The problem is not hardware but rather the meat sack hired to Administer the network: WETWARE is the problem.

Thanks, Rav. I actually reached out to AMD to clarify the remote exploit aspect, because the researchers merely say "SEVered 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."
It turns out that this is an accurate but misleading statement, because it doesn't provide the context. It assumes that attackers already have total control over the hypervisor before they begin the attack.
Thus, you are right: The SEVered attack is not remotely exploitable. An attacker either needs to exploit the hypervisor from which the attack is launched with a separate vulnerability to gain code execution; or insider threats could exploit their own hypervisors. So, if there is no second remotely exploitable vulnerability, then SEVered is not exploitable from the network.
Thanks for bringing the point to our attention!

Authors

Threatpost

InfoSec Insider Post

InfoSec Insider content is written by a trusted community of Threatpost cybersecurity subject matter experts. Each contribution has a goal of bringing a unique voice to important cybersecurity topics. Content strives to be of the highest quality, objective and non-commercial.

Sponsored

Sponsored Post

Sponsored Content is paid for by an advertiser. Sponsored content is written and edited by members of our sponsor community. This content creates an opportunity for a sponsor to provide insight and commentary from their point-of-view directly to the Threatpost audience. The Threatpost editorial team does not participate in the writing or editing of Sponsored Content.