Epyc Fail? Researchers Say They Can Defeat AMD’s Virtual Machine Encryption

Megalith

Megalith

24-bit/48kHz
Staff member
Joined
Aug 20, 2006
Messages
13,000
AMD's Epyc server chips utilize Secure Encrypted Virtualization (SEV) to automatically encrypt virtual machines on the fly while stored in memory, but researchers 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.”

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.
 
Looks pretty hard to protect vm's from the host. I mean........ The vm's are running on the just so..........
 
While the effort to make VMs secure in this regard is worth applause, it's generally expected that if any system has been compromised at the root, such as at the hypervisor level, that all data is, or will be, effectively fully breached.

Typically the best way to address this is to make it as impossible as you can for outside parties to even come close to this state. As in, not be able to reach the underlying host.
 
Seems this is more of an external security issue in that if one locks the doors and require security clearance one does not get Hypervisor level access to pull off this attack.

Assuming one got Hypervisor access they could 100s of things before having to resort to using SEVer.
 
This exploit only works on guest VM's on the physical host machine that the sysadmin has access to. You can not 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.
 
It's a good demonstration of how unreliable such a feature really is. "Baked in" security never works.
 
Ranma said:
If you don't trust your sysadmin, you've got other problems than this.
Click to expand...
Trusting your sysadmins is always a mistake. In any well-designed crypto-security system, people are always the easiest attack vector to exploit.

Like the launch buttons on nuclear missiles, good cryptosecurity systems require two or more authorized people giving independent near-simultaneous two-factor authorization for any operations that might create a vulnerability-- compromising two people is a lot harder than compromising just one. But I don't know whether any of the common hypervisors support this.
 
velusip said:
It's a good demonstration of how unreliable such a feature really is. "Baked in" security never works.
Click to expand...

This whole IT landscape is insecure by design.

You just have to punch hard and long enough to get through, I dare to say that works with any security measure, with tangible things as with logical constructions.

Someone will always be smarter than you, face it !


Why am I not surprised at all ?
 
DukenukemX said:
Is this another one of those exploits that require root? Has Intel been giving someone research money?
Click to expand...


at this point i think every half baked security "researcher" and their mom wants their 15 minutes of fame, so if they can find any type of security hole whether it's the most useless crap ever that requires a crap load of other exploits just to do it they're going to publish it..
 
velusip said:
It's a good demonstration of how unreliable such a feature really is. "Baked in" security never works.
Click to expand...

No, it's just more proof of something that mankind has known since the very earliest attacks of any kind. Offense is inherently more successful then defense. Nothing will ever be completely secure or invulnerable to attack.
 
SEV was really meant to counter attacks from other VMs running on the system, which is common in cloud computing environments; you don't know who else you are sharing the hardware with. It would be too much to expect it to have good protection from a compromised hypervisor. So this article is mostly a "no shit sherlock" situation.
 
Ranma said:
This exploit only works on guest VM's on the physical host machine that the sysadmin has access to. You can not 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.
Click to expand...

The whole point of SEV is to protect the VM from a malicious admin, so it is a perfectly valid issue.
 
Oh hey, another locked door yet someone with a key can get in" exploit, who would of thought that would be possible!
 
Oh my god the horror if you can acess the root you could set up your OWN vm and attach it to the same storage that others were mapped to and access it and NOBODY could stop you!! THE HORROR...

Who the hell approved this as a vulnerability. This article is full of stupid.
 
Grimlaking said:
Oh my god the horror if you can acess the root you could set up your OWN vm and attach it to the same storage that others were mapped to and access it and NOBODY could stop you!! THE HORROR...

Who the hell approved this as a vulnerability. This article is full of stupid.
Click to expand...

Um, considering the WHOLE ENTIRE POINT OF SEV is to prevent that....

Stop being ignorant people, the whole entire point of SEV is to prevent the hypervisor from reading the VMs memory to provide isolation and privacy in a hosted environment.
 
aaronspink said:
Um, considering the WHOLE ENTIRE POINT OF SEV is to prevent that....

Stop being ignorant people, the whole entire point of SEV is to prevent the hypervisor from reading the VMs memory to provide isolation and privacy in a hosted environment.
Click to expand...

From the mouths of babes... think about this. IT only protects the RUNNING VM's. You stop a VM, change some access perimeters, or even DISABLE that functionality at the OS level then force start the VM suddenly those protections are gone. If you are at the hypervisor level already it is only a matter of time before everything else is compromised in that environment.

If you have less security on your Hypervisor than you do on your running VM's you have a bigger problem. The Hypervisor should be NEIGH impossible for someone to access that isn't the manager/administrator of that environment. If it is, you need a security review yesterday.
 
If the VM's get compromised which would've been under the watch of the assigned network admin then they need to be fired
 
There is no level of security that will prevent a compromised admin from giving access. Period. I would guess that 30% of corporate entities have one such individual in their employ that is actively leaking data to competitors for a payday on the side. Just a guess mind you. I really hope I am wrong.
 
Grimlaking said:
From the mouths of babes... think about this. IT only protects the RUNNING VM's. You stop a VM, change some access perimeters, or even DISABLE that functionality at the OS level then force start the VM suddenly those protections are gone. If you are at the hypervisor level already it is only a matter of time before everything else is compromised in that environment.

If you have less security on your Hypervisor than you do on your running VM's you have a bigger problem. The Hypervisor should be NEIGH impossible for someone to access that isn't the manager/administrator of that environment. If it is, you need a security review yesterday.
Click to expand...

In a hosted environment, there can be hundreds to thousands of people that have credentials for hypervisor admin. Things like changing access parameters, stopping, moving, etc a VM are easy to detect and log. A memory poke however is virtually impossible to detect. The whole point of SEV is to isolate and protect the VM from the hypervisor.
 
If you have hundreds to thousands of people accessing your hypervisor you deserve to be hacked.

Yes I just said that. If you are irresponsible enough to give hundreds to thousands of users unfettered access to your Hypervisor.

Now on to this vulnerability. For it to work you need a linux guest running apache. Through this you can access the memory on that host by requesting web pages based on patterns of memory access as noticed from the hypervisor. (Due to this I presume this is the command line hypervisor.) Then you can use that information to formulate web requests to send you the memory areas from the VM in question.

So this isn't the Epyc Encryption being defeated because you are actually pulling unencrypted data from the VM itself via program calls within the VM.

For this 'vulnerability' to work, you have to have a specific OS running a Specific Software that is a web host. A compromised Host that you can pull data from as well (meaning memory access requests and such.) THEN using that you can target specific we requests to pull specific memory areas as plane unencrypted text. (Because it is being pulled from within the OS of course it isn't encrypted.).

For this to NOT work you would need a DLP solution ALSO built into all of this... but that might be a big failure on the part of the OS to not be able to fulfill it's job and the Apache software not to deliver web pages.

Again this is a shitty version of a vulnerability. I fail to see how this makes the news.
 
"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 server within an SEV-encrypted virtual machine was used to lift plaintext data out of said protected guest."

Wait, what? The guest VM was hijacking its own data?
 
You must log in or register to reply here.
Back
Top