Researchers Crack Open AMD's Server VM Encryption (theregister.co.uk)

Shaun Nichols, reporting for The Register: A group of German researchers have devised a method to thwart the VM security in AMD's server chips. Dubbed SEVered (PDF), the attack would potentially allow an attacker, or malicious admin who had access to the hypervisor, the ability to bypass AMD's Secure Encrypted Virtualization (SEV) protections.

The problem, say Fraunhofer AISEC researchers Mathias Morbitzer, Manuel Huber, Julian Horsch and Sascha Wessel, is that SEV, which is designed to isolate VMs from the prying eyes of the hypervisor, doesn't fully isolate and encrypt the VM data within the physical memory itself.

Comments

"malicious admin"

[Joffy]

I feel like some of these stories are like Bob's Home Security fails to protect you if your wife is a serial killer.

Re:"malicious admin"

[Anonymous Coward]

Hey, Intel paid a lot of shekels for this very valuable research!

Re:"malicious admin"

[vux984]

"I feel like some of these stories are like Bob's Home Security fails to protect you if your wife is a serial killer."

To an extent they are, but if you are using cloud providers, the other tennants, and the monkeys at the cloud provider itself should all be considered potentially hostile.

And even within companies there is this (legitimate) concept that everyone in IT shouldn't hold the keys to payroll, finance, HR, and the R&D trade secretes... so there are lots scenarios where the people administering the systems, the servers, the cloud fabric etc, shouldn't be able to get access to the contents of the virtual machines.

Re:"malicious admin"

[Anonymous Coward]

The old adage applies regardless: "He who has physical access, owns the data."

It doesn't matter what it's running. If they have physical access, or local admin access, they own the data. All permissions derive from the admin account that set the system up in the first place. Trying to protect the system from the person who set it up / is responsible for maintaining it, is a fool's errand.

The only reason we are having this discussion, is because everyone is too busy trying to save money by outsourcing the complexities and costs of IT to others while still trying to claim that they are the sole possessors of the data / processes. Nobody cares about the actual security, all they care about is the money. Well guess what? IT is a cost center. It doesn't make you money directly, but it is required to enable you to make money in a modern marketplace. You get from it exactly what you put into it. You don't wanna pay to manage your own IT? Don't expect the admin that's not under your control to abide by your desires. Sure you can have "agreements" and "contracts" with them, but remember this: Contracts and agreements only specify redress. They don't prevent a leak or malicious intent from happening in the first place. If your sole value in something is it's information. Then giving it to others should be the last thing on your mind. Especially if you are a service economy that doesn't produce enough to maintain itself if worse comes to worst and the info is copied without your consent by a competitor.

TL;DR if you don't trust the person with permission to manage your IT with the data the IT contains, then you need to find someone you do trust to do it. Beyond that, the only assurance you have is the time it will take to copy it.

Re:"malicious admin"

[Anonymous Coward]

but if you are using cloud providers, the other tennants, and the monkeys at the cloud provider itself should all be considered potentially hostile

Um, yeah, but you considered them potentially hostile anyway. Nothing has changed. Except that maybe some snakeoil salesperson said that AMD's fancy new whatever would make it so that you could stop doing that, but you knew he was definitely lying, because it's impossible/impractical to hide software from the hardware it's running on.

there are lots scenarios where the people administering the systems, the servers, the cloud fabric etc, shouldn't be able to get access to the contents of the virtual machines.

Well, of course. When the snakeoil salesman says this bottle will cure your cancer, that seems like a good idea because there are lots of scenarios where you would prefer to not get cancer. But just because you want something, doesn't mean you can have it.

Yes, there are scenarios where admins shouldn't have access to the VMs, but there aren't any scenarios where the admins don't have access to the VMs. They will definitely have it if they want it, and anyone who sells you a fix for that is making an extraordinary claim that requires extraordinary proof. Until they supply it, you just assume they are attempting to commit criminal fraud, to part you from your money by offering you an impossible dream thing that they are definitely not going to deliver.

Re:"malicious admin"

[TheRaven64]

The entire point of SEV (and Intel's SGX) is to protect the code against a malicious hypervisor. AMD tries to make a dubious distinction between a 'malicious' hypervisor and a 'compromised' hypervisor. Apparently they believe that if an attacker is able to run arbitrary code in the hypervisor, they are less of a threat than if they installed the same malicious code early on.

That said, this is not news. There was a paper published at VEE a year ago (by the same researchers) showing how broken SEV is. Paolo Bonzini (KVM maintainer at Red Hat, among other things) was on the PC and pointed out that they had sent feedback to AMD prior to their shipping it pointing out that the design was fundamentally flawed. Apparently Microsoft sent similar feedback. AMD shipped it anyway, because they needed something to compete with SGX (which is less broken, but also a lot less general).

Re: "malicious admin"

[TheRaven64]

These researchers, Red Hat, and Microsoft all gave AMD feedback that SEV was broken and needed serious redesign before AMD shipped any products with SEV. This paper is just showing everyone that (some of) the attacks that were pointed out to AMD before they shipped the product actually work in practice.

Wait a minute...

[Narcocide]

If you have access to the hypervisor you already have full control over the guests even without this "exploit." Why is this considered a big deal exactly?

Re:Wait a minute...

[Anonymous Coward]

Hush you. Intel just got hit with a bunch of new bad bugs, you're ruining the distractive narrative! We're all supposed to look at AMD now.

Re: Wait a minute...

[Bing Tsher E]

Is Intel vs. AMD part of the Marvel Universe yet? Because I have no problem ignoring all the superhero shit, and tis seems like the same kind of fanboy shit. Marvel! No, DC! No Intel! No no no! AMD!

A bunch of comic book crap.

Re:Wait a minute...

[gweihir]

Because people are stupid.

Re:Wait a minute...

[TheRaven64]

As I said above, because the entire point of SEV is that a malicious hypervisor can't tamper with a VM running in an SEV partition. Memory is encrypted, register contents are encrypted on context switch, and the VM can encrypt the contents of the disk and all network traffic itself. There are a number of flaws in the design that were pointed out to AMD (by this group of researchers, among others) before they shipped a product. AMD went ahead and shipped it anyway and, shockingly, it turns out that the attacks work.

Re: Wait a minute...

[TheRaven64]

The bugs that has hit Intel are generally far worse with more severe implications and bigger impact.

Compare apples and oranges. AMD's SEV is intended as a competitor to SGX. There are some Spectre-related SGX attacks, but these can be fairly easily mitigated in software. In contrast, SEV is completely broken and the breakage is fundamental to the design, not a defect of implementation. Microsoft, Red Hat, and the group of researchers in TFA (and probably others) told AMD this well over a year ago before AMD shipped any SEV-enabled cores. AMD still shipped the feature and advertised it as secure.

Wait a minute...doing it right.

[Ostracus]

Consider it an incentive to not skimp on hypervisor programming.

The problem, say Fraunhofer AISEC researchers Mathias Morbitzer, Manuel Huber, Julian Horsch and Sascha Wessel, is that SEV, which is designed to isolate VMs from the prying eyes of the hypervisor, doesn't fully isolate and encrypt the VM data within the physical memory itself.

I wonder if that's because doing so would incur too much of a performance penalty?

Re:Wait a minute...doing it right.

[flux]

The article ends with

> "A low-cost efficient solution could be to securely combine the hash of the pageâ(TM)s content with the guest-assigned GPA."

Re: Nice try

[Bing Tsher E]

It's virtuous, heroic and enlightened to pick another brand!

Re:This is why you don't PAY for VM's

[duke_cheetah2003]

This is exactly the reason you don't pay someone for your VM architecture. It's all insecure garbage... and this is igoring the fact that the NSA/BSA is deeply imbedded in evehing you do.. At least support the people that do it for free.

This is really bad advice. Hosted in your basement, or on someone elses data center, it really doesn't matter, you're vulnerable to attacks. All you can ever hope to do is mitigate the effects of any successful attack, and do everything you can to isolate things from each other, so an attacker has limited access and has to start anew to break into another isolated service.

Economically, it doesn't even make dollar sense anymore to host internet servers in your basement. When one calculates the cost of owner ship, maintenance, support, etc, of having a physical server.. well, it just doesn't make sense. You can have the same thing in someone elses data center, without all the cost of ownership. You pay your bill, someone else deals with all the technicalities of keeping a computer up and running.

Even an "insecure" data center hosted server can be hardened against attack, both externally and internally. The sheer volume of virtual machines running in a data center with literally 1000's of computers, all running VMs... yeah, unless you're some state intelligence agency, data center is good enough and secure enough. The levels of effort needs to FIND your VM, tamper with it in a way you're not going to know about. Who does this? And if was being done, why do you think just because you have the physical hardware in your basement, you're magically immune to attack? Silly.

The bottom line, the one no one wants to admit to, or hear: You're not important enough for anyone to give a flying f about you or your server(s). If you were, you wouldn't be discussing it here on Slashdot. You'd have your own data center.

Insecure by design

[duke_cheetah2003]

All modern PC's were never designed with the thought in mind: There will be millions of attacks against this to try and break in.

We just didn't think about that when we designed this stuff, which was before the internet really took off. Of course it's all insecure and broken, it wasn't designed to be hardened against the countless ways security researchers are finding into these designs.

When the "forces that be" decide to scrap everything we've created upto now, and start anew, with a security focus right at the starting line, then we'd get some hardware and software platforms that're truly hardened against any attack.

Bandaids over the x86 paradigm? Waste of time. It's never going to be secure, not against everything everytime. It's just not designed to be secure, we didn't think it needed to be. We didn't think there'd be millions of malicious actors in the wild, with our computers all interconnected by the internet, so everything is exposed to everyone. We just didn't think that'd ever happen. It shows.

Re:This is why you don't PAY for VM's

[HiThere]

If you really care about the security of your system, don't connect it to the net. Even indirectly.

If you "sort of " care about the security of your system, only connect it indirectly. No direct web access. Use message passing of text messages to transfer info. It's not as fast, and it takes a bit more setup, but you can don anything that way that you can the other way.

If you really don't care about security, put your data out on the cloud.

Re: Nice try

[HiThere]

I'm not sure about "heroic", and I'd have added the adjective "selfish".

Re: This is why you don't PAY for VM's

[HiThere]

Yes. I should probably have put an ellipsis in between 'If you "sort of " care about..." and "If you really don't care about ...", because you're right, there are a very large number of intermediate positions. There are also a few intermediate positions between the first two positions. I guess I thought it was sufficiently obvious.

For example, one intermediate position it to use a self-hosted web platform using only the http subset that existed before javascript. Or to host your system on a box that has a read-only drive. (Since we're talking intermediate positions we could distinguish between a read only drive and a normal drive that's mounted read only.) Etc.

And there are degrees of security lower than a standard cloud platform, too.

Re:This is why you don't PAY for VM's

[Spamalope]

The sheer volume of virtual machines running in a data center with literally 1000's of computers, all running VMs... yeah, unless you're some state intelligence agency, data center is good enough and secure enough.

Sure... Script kiddies and ransomware must not exist in your world.

6 figure plus targets means an automated attack. Do you think a ransomeware group cares if they destroy 999 VMs to get to 1 owner who pays? Manpower per payment is all that matters, and you're describing a huge group of vulnerable targets.

The hypervisor can see anything

[gweihir]

There is not really a way around this and there are numerous ways to bypass any protection mechanism. This is hardly news, except to the clueless that believe the marketing hype.

Re:This is why you don't PAY for VM's

[flux]

However when you factor in a 1 Gbit or preferably 10 Gbit connection to said server for ie. having your / of your desktop computers there, the economics turn upside down.

Hopefully that will change in the future.