Researchers Point Out 'Theoretical' Security Flaws In AMD's Upcoming Zen CPU (bleepingcomputer.com)

An anonymous reader writes from a report via BleepingComputer: The security protocol that governs how virtual machines share data on a host system powered by AMD Zen processors has been found to be insecure, at least in theory, according to two German researchers. The technology, called Secure Encrypted Virtualization (SEV), is designed to encrypt parts of the memory shared by different virtual machines on cloud servers. AMD, who plans to ship SEV with its upcoming line of Zen processors, has published the technical documentation for the SEV technology this past April. The German researchers have analyzed the design of SEV, using this public documentation, and said they managed to identify three attack channels, which work, at least in theory.

[In a technical paper released over the past weekend, the researchers described their attacks:] "We show how a malicious hypervisor can force the guest to perform arbitrary read and write operations on protected memory. We describe how to completely disable any SEV memory protection configured by the tenant. We implement a replay attack that uses captured login data to gain access to the target system by solely exploiting resource management features of a hypervisor." AMD is scheduled to ship SEV with the Zen processor line in the first quarter of 2017.

Comments

I can show, in theory, that...

[Anonymous Coward]

These fears are groundless.

How?

Simply by theorizing that Zen will never be released.

Question

[Anonymous Coward]

One argument for open source software is that anyone can search for vulnerabilities and help fix them. Is there a similar argument for open source hardware, that more people studying the design can find and help eliminate bugs before vulnerable hardware ships?

Re:Question

[110010001000]

This is software (microcode) vulnerabilities, not hardware. I don't know why this attack would matter, it needs a malicious hypervisor. I only read the summary, because it really doesn't matter. The cloud isn't secure anyway.

Re:Question

[Anonymous Coward]

Wouldn't one of the attacks simply be: $5 wrench attack against a microcode engineer?

(If you thought hacking an entire datacenter or hacking an entire operating system was bad.... Try hacking ALL INTEL or ALL AMD cpus..... pretty crazy.)

The only defense against this is open cores. (Most people don't even understand WTF this is. Basically think: Open source hardware at the silicon level.)

Re:Question

[KiloByte]

Wouldn't one of the attacks simply be: $5 wrench attack against a microcode engineer?

(If you thought hacking an entire datacenter or hacking an entire operating system was bad.... Try hacking ALL INTEL or ALL AMD cpus..... pretty crazy.)

You mean, something like Intel IME? Already there, in your CPU. I'm for one using an old AMD (Phenom 2) but I see no upgrade path at the moment. AMD's version of the backdoor is less vicious (no path from the network card) but not nice either.

There's no outright proof of Intel CPUs being backdoored, but they made a number of very weird design choices that make absolutely no sense when the purpose is anything but hiding a backdoor. So let's think who gets the keys.

Re:Question

[ooloorie]

it needs a [1] malicious hypervisor. [2] I only read the summary, because it really doesn't matter. [3] The cloud isn't secure anyway.

Secure encrypted memory is supposed to address [3] by preventing [1] from being effective.

And your problem is [2]: you don't read and you don't think.

Re:Question

[Anonymous Coward]

The purpose of encrypted memory is to defend against malicious guests exploiting the hypervisor. Defending against a malicious hypervisor is impossible and was never a goal.

Re:Question

[Anonymous Coward]

Everyone was clamoring for opensource GPU drivers saying how the community could then develop the drivers and fix issues. Turns out GPU drivers are so complicated that only a select few people in the world can even read them yet alone write useful code. I can't see looking at actual transistor logic being any better.

Re:Question

[EndlessNameless]

You think you can defend against a malicious hypervisor?

Wow, I have a bridge to sell you...

Re:Question

[ooloorie]

You think you can defend against a malicious hypervisor?

With current hardware, no. With future hardware, yes. The problem is not much different from SIM cards or credit card chips: secure hardware running in a hostile environment.

Malicious Hypervisor

[mhkohne]

I only read the abstract, but once you use the words 'malicious hypervisor', I figure it's game over. I know that AMD is touting this SEV as a solution, but there's no way you are going to convince me that the thing that controls the nature of my VM's reality isn't capable of getting and controlling everything that VM has.

Re:Malicious Hypervisor

[Anonymous Coward]

The headline is accurate, though a bit misleading. This is a new security feature that still has some flaws. If done properly, maybe a malicious hypervisor really would hold less of a threat. But the wording makes it sound like it is less secure than processors that don't even have the feature in any manner at all.

Re:Malicious Hypervisor

[Anonymous Coward]

Isn't a signed hypervisor suppose to address that?

Re:Malicious Hypervisor

[Anonymous Coward]

I accept that I'm not going to convince you, but it's true. One of the points of intel SGX is that all pages of memory are encrypted, on the die, by the using keys that only a single enclave (e.g. VM) has access to. These keys are setup by an external channel using negotiation keys that private to the manufacturer of the hardware. You can sign a package and ship it off to a CPU, knowing that nobody but the cpu itself can see what's in it -- even probe on the memory bus. You dont' have to trust your hypervisor or your system admin. You just have to trust your cpu fab facility, which you do already. While it is theoretically possible to pull these keys off the CPU, you can't do so without being noticed.

Re:Malicious Hypervisor

[haruchai]

"We would like to emphasize that we did not break AMD
SEV itself but rather evaluated the design issues present
in the documentation in respect to their usefulness for a
malicious or compromised hypervisor"

I'd say there's a very slim chance of this happening.
Intel's SGX certainly *sounds* more secure but require changes to source code which could get very, very expensive so unlikely to be implemented in most cases for existing setups.

Re:Malicious Hypervisor

[Anonymous Coward]

The problem is that you cannot trust your admin to employ a machine that dances to the tune. The same thing we always say about DRM applies, albeit in modified form: if you can run it, you can decrypt it and run it in a regular VM. At some point the encrypted VM implementation must decrypt the code in order to run it. This means that it must contain the decryption key. It's security through obscurity. You can never trust that your image won't be decrypted using nicked keys and run on a regular VM. If your data is secret, don't run it in the cloud.
Which means that any encrypted VM implementation security vulnerability that requires that the hypervisor is evil is bogus. It only gets interesting when the VMs themselves can break out of their little sandboxes.

Re:Malicious Hypervisor

[donour]

No. The VM does not have the key. The hardware has the key and only that core can run it. Practically, someone can take the die apart, xray it, and get the key. At that point they have access to the code that was was on that cpu -- maybe -- but you can avoid total loss by distributing across a large number of cores. The intel implementation was broken, but the idea is pretty sound. Seriously, read the papers.

Re:Malicious Hypervisor

[Anonymous Coward]

Intel SGX (current version) is deeply flawed in that it does not protect *by design* (and this *is* written in the spec sheet) against some extremely nasty side-channels: cache, branch-prediction unit, etc.

Some of it you can attempt to work around (you can partition the cache in latest/next upcoming? Intel server chips, for example). Some you cannot.

And the hypervisor can do extremely nasty shit to whatever the SGX container is talking to, including forcing all sort of timing and inputs/outputs to profile the SGX container.

AMD SEV is not worse than Intel SGX in that regard *at their current versions*. And really, the two are *not* equivalent, they have slightly different use cases.

Besides, Intel SGX is mostly useless right now, given that, somehow, even if that crap is almost entirely implemented in microcode, they will not release the required trusted modules + attestation keys and process to allow applications to set up local SGX containers to securely partition crypto operations, etc *FOR THE CURRENT BATCH OF PROCESSORS*, but it will be available in a future model (?!?!).

Re:Malicious Hypervisor

[Carewolf]

One of the points of intel SGX is that all pages of memory are encrypted

As far I understand the SGX scheme, only special memory accessed by special SGX instructions are encrypted. SEV is very different, it encrypts everything and doesn't need special new instructions, but can protect legacy code, which SGX can not.

Re: Malicious Hypervisor

[Anonymous Coward]

If the hypervisor is malicious, it can lie about the public key you need to use to encrypt. It can then decrypt your software outside the CPU. However, I suppose there might be a certificate authority, which would mitigate the problem as long as the certificate chain remains secure.

Re:Malicious Hypervisor

[ooloorie]

I know that AMD is touting this SEV as a solution, but there's no way you are going to convince me that the thing that controls the nature of my VM's reality isn't capable of getting and controlling everything that VM has.

There are plenty of processors that run in adversarial environments; a common example is the chip card on your credit card. There is no conceptual problem with scaling that up to high performance servers.

Neither AMD nor Intel are going to get this right on the first or second try, but eventually, they will. It won't be entirely secure because there are still hardware attacks possible, but for 99.9% of applications, where you simply don't want personal info to leak, it's a good solution.

Re:Malicious Hypervisor

[Anonymous Coward]

No. The VM does not have the key. The hardware has the key and only that core can run it.

Yes. But "that core" may be my debugging setup, not an actual core. Because I am the evil cloud provider. So I stop execution and extract the key. Or I let the thing decrypt and extract the decrypted data/software/memory.

Re:Malicious Hypervisor

[Anonymous Coward]

My credit card is not in an adversarial environment. I don't wan't to break it, and neither do the common merchant. Any mess with cards that pass through a certain shop, puts that shop is in a sea of trouble. Messing with the credit card people give to internet shops is easy (for the shop owner) - but the shop taking part in such actions is dead.

So no, credit cards run in a protected environment. Stuff in a true adversarial environments tends to get broken, like CSS was.

And in other news...

[Anonymous Coward]

Researchers say research is useful.

All current Intel chips have vulnerabilities etc

[Anonymous Coward]

This is simply paid Intel FUD against their only competitor in the x86 space. All Intel chips have ring 0 and higher vulnerabilities- which is why Windows and Linux machines can be 'pwned' so easily in competitions that offer rewards to hackers who can breach fully patched x86 machines. All of Intel's so-called unhackable private memory space hardware functions have been shown to be utterly useless against informed attacks.

And worse, Intel (and AMD) have NSA and GCHQ back-doors in their CPUs that operate above ring 0 using chip internal resources that no external security program can lock-down. And what the NSA knows, Israel government agents know. And what Israel knows, criminal tribe members in the Ukraine and other East European crime cesspits know.

No 'magic' hardware in any of your CPUs is going to make your computer safe from hacking. Saying otherwise is simple markeding puffery from Intel and AMD. But saying that AMD is 'broken' without reporting the fact that so is Intel- thanks to the NSA- is simple pro-Intel advertising.

So how long did they know?

[future assassin]

and are now just releasing this just before the release of the chips?

Intentional Insecurity

[Anonymous Coward]

The insecurity is intentional. Kick AMD to the curb.

Non story

[wbr1]

1. Needs a malicious hypervisor. If you trust your critical data/systems on a VM that us under a hypervisor you do not control, well you deserve what is coming to you. This is no different than someone having physical access to your hardware, all bets are off.

2. Regular consumers are not going to care about this or have to worry about it.

If the price/performance of this family pans out as promised, it will get foothold in the server market and HPC market. Both will find ways to secure against this -or own their own metal-. Plus there are plenty of uses that run bare metal.

Are we sure this wasn't an Intel funded FUD study?

Re:Non story

[BlueCoder]

Thanks. Wanted to make sure I understood... "malicious hypervisor"....

I had no idea anyone was trying to create a hypervisor that didn't have transparent access to it's guests. It's impressive that they tried. But there are lots of new experimental features in each generation of CPU's that won't necessarily follow in the next design. I doubt they though it would be secure on the first try. We don't have that security now so there is no loss. And even if it does happen in the future it will be 20 years before I even consider trusting it. And even then I would need expert testimony of someone that had reverse engineered the chip under a microscope to ensure there are no back doors.

Re:Non story

[gravewax]

Everyone has been trying to create secured guests where you can limit what a malicious admin can do. Microsoft has Shielded VM's, VMWare has its various vShield technologies etc etc.

Re:Non story

[Carewolf]

Thanks. Wanted to make sure I understood... "malicious hypervisor"....

I had no idea anyone was trying to create a hypervisor that didn't have transparent access to it's guests. It's impressive that they tried. But there are lots of new experimental features in each generation of CPU's that won't necessarily follow in the next design. I doubt they though it would be secure on the first try. We don't have that security now so there is no loss. And even if it does happen in the future it will be 20 years before I even consider trusting it. And even then I would need expert testimony of someone that had reverse engineered the chip under a microscope to ensure there are no back doors.

Well, they have been trying for a while. And it is not just the hypervisor the protecting against, it is "malicious users". One of the key application of these technologies is DRM, so users can't access protected content.

Re:Non story

[segedunum]

If the price/performance of this family pans out as promised, it will get foothold in the server market and HPC market. Both will find ways to secure against this -or own their own metal-. Plus there are plenty of uses that run bare metal.

It's difficult to know what to make of this, but as soon as I started reading it it was like they were stirring for something. The Intel Managament Engine on the other hand, no one has the faintest idea what that thing is doing ;-).

If Zen is somewhere in the ballpark of what Intel have, and more importantly gives them an architecture they can build on over the next few years which they just haven't had, then they are going to sell a lot of these. The chips and boards will inevitably be a lot cheaper than Intel's.

Not the point

[mike.mondy]

We show how a malicious hypervisor can force the guest...

So, having access to the physical hardware means game over? Gee, what a surprise. Preventing one VM from accessing or affecting another is useful. Offhand, I can't imagine much of a need to preventing a hypervisor from accessing the VMs that it controls...

Re:Not the point

[Kjella]

So, having access to the physical hardware means game over? Gee, what a surprise. Preventing one VM from accessing or affecting another is useful. Offhand, I can't imagine much of a need to preventing a hypervisor from accessing the VMs that it controls...

Isn't that quite obvious? It's like renting a security deposit box but you don't want a glass box the bank can look inside. If it was just static data you'd encrypt it then send it over. It's lot harder for a running program, but I guess they're trying anyway that they just run it, but you sit on the keys to decrypt what it's really doing.

Re:Not the point

[Luthair]

I imagine the idea is that another VM manages to exploit a flaw in the hypervisor gaining control.

Re:Not the point

[Szeraax]

What if the DHS hacks your Hypervisor? Maybe people will pay a premium to have a more protected VM IaaS setup.

Re:Not the point

[Anonymous Coward]

You don't need "physical hardware" access. You just need access.

Re:Not the point

[gweihir]

The need is pretty clear: Processing of data that needs to be secure against the cloud-provider. That this is very likely infeasible is however quite clear as well. In the worst case, a malicious hypervisor could just run on entirely different hardware and simulate all the protection features that are supposedly preventing it from full access to the VMs, thereby getting that access. The best this technology could ever hope to achieve is to make it somewhat harder for the cloud provider to look at a full, decrypted VM state.

Re:Not the point

[gweihir]

Then it is game over. And this is not a surprise at all. Virtualization _decreases_ security, by offering more attack surface.

Re:Not the point

[Anonymous Coward]

I agree that the cloud provider could bypass this by simply running the VM on different hardware without these features, but if the cloud provider is trustworthy then the VMs they host are better protected against the cloud provider's servers being compromised. Specifically an attacker would have to be able to compromise the HV in a way to make it perform specific malicious actions to bypass SEV.

Re:Not the point

[mike.mondy]

The need is pretty clear: Processing of data that needs to be secure against the cloud-provider. That this is very likely infeasible [...] a malicious hypervisor could just run on entirely different hardware and simulate all the protection features [ ... ]

Right - there's a need for secure remote computing.

But, remote security in general is a different topic than discussing VMs on hostile hypervisors. If you don't trust the people who control the hypervisor, any discussion of vectors of access to the VMs is academic. Because there *will* be ways - both software and hardware (for example, dual ported memory and ICE).

So, the TFA seems to be fluff and FUD in attacking the lack of a pointless feature.

Any solutions for secure remote computing probably need to involve a hosting setup where you have full control over the hardware, not a VM on hardware controlled by the site.

Re:Not the point

[gweihir]

Actually, an attacker would only need to replace the hypervisor as I described and reboot the VMs. Job done. Sure, that is a lot of work, but once somebody writes that emulator, a short while later it will be out there for any criminal (whether private or government-employed) to use.

Re:Not the point

[gweihir]

Yes, and more. For secure remote computing, you must be the only one to be able to access the hardware. The best you can get today is a locked rack in a data-center. That is also the only thing that gives you some level of trust. The cloud is not and will not be secure against the cloud-provider or anybody that hacks the cloud-provider. It also seems unlike that this will be solved on a technology-level anytime in the next few decades.

As a matter of fact, this topic and the need for it is very, very old. When I studied for my Master's in CS (some 25 years back), it was already a hot topic. At that time it was trusted chip-cards offloading computations to untrusted servers and the like, but the base-problem is the same. There have been no convincing approaches on how to do it in > 30 years of research. The only thing we have now is Fully Homomorphic Encryption, but that has major functionality and performance limitations. You cannot even begin to use it to create an untrusted application to work on trusted data, you can just delegate some specific computations.

For the next few decades, if you do not fully control the hardware and software, you are not secure. And it is actually getting worse, not better, with backdoors and bugs in hardware, software and firmware.

Re:All current Intel chips have vulnerabilities et

[Anonymous Coward]

"Intel (and AMD) have NSA and GCHQ back-doors in their CPUs that operate above ring "
And of course you have proof of this statement? Are these back doors similar to the ones supposedly built into Windows? And proof does not include Innuendo and wannabe geeks with active imaginations does not count as proof. The strongest proof that these so called back doors, if the existed, could be exploited by not only the government but pretty much anyone else with the technical know how.

Doesn't need to be:

[Anonymous Coward]

By the very nature of AMD, Intel, and ARM's current generation of processors, all of them expect you to trust the CPU and/or management engine not to be malicious, even while they're adding network capable backdoors and RTOSes with above supervisor level access to the memoryspace. Given that, the keys can be presumed compromisable and since they are symmetric only require a single leak to make the VM just as insecure as if it was cleartext running under a compromised hypervisor.

Much like the Oracle 'memory coloring' it is just another layer of security theatre which doesn't solve the inherent issues of non-conformant processors allow attacks via undocumented 'features'. Fix the cpu errata, then the management engines, and THEN consider adding questionable features to 'enhance security of the vms'. Until those other two exploit channels are fixed, this is just another bypassable feature providing 'corporate grade security' while providing no 'real world' practicality.

Re:All current Intel chips have vulnerabilities et

[Anonymous Coward]

Exactly, more FUD. Fake News crap.

The are only 'Theoretical' until

[Anonymous Coward]

They are only 'theoretical' until someone exploits them.

If I can't trust my processor to properly isolate my virtual machines from my hypervisor , WHY am I running a hypervisor in the first place? There are much easier ways to give someone total access to my entire machine.

tl;dr

[Megane]

This new CPU has a security feature with a theoretical security flaw that at its worst will only make things as bad as they already are right now.

Malicious Hypervisor????

[gweihir]

Seriously? Here is news for all that do not get how virtualization works: If the hypervisor is malicious, you are screwed. It just has far too much control, and it needs it. So this is basically a non-issue.

I just hope the thing competes, somewhere

[AbRASiON]

I have an Intel Quad Core, non HT CPU in both my PCs - one a 4590 other a 4690, I think. They run ok, pretty well, DDR3 - but they are still not 'snappy' enough for some operations.

I want things blisteringly fast and I want Windows to NEVER slow down.
I don't care what it takes, I don't know enough about tech, I just want it. Do I need a faster south or northbridge? Do I need more IO? Do I need the OS re-written to have a DEDICATED CPU at all times for 'basic usability' ?

Apple (generally) has the UI as the highest priority no matter what and trickery to make their devices responsive, even when they aren't. I want this in Windows, somehow.
I want to do some intensive CPU stuff over here, run a VM there, Firefox with 2000 tabs here and if it's in the god damned foreground, have it be damned responsive.

I've got 24GB, my next machine will be 32GB of DDR4, I don't knwo how many cores or what chipset I need, just deliver it.

Also, sidenote, my AMD Microserver running FreeNAS has been great, but man I'd love an ECC DDR4, 4 core compatible machine which can run in low power mode AND ramp up to high intensity at a reasonable price.

Re:I just hope the thing competes, somewhere

[Anonymous Coward]

I want a pony

Re: I just hope the thing competes, somewhere

[Anonymous Coward]

Good luck. I have an oldish phenom II that screams in Linux. In Windows, I am constantly waiting for it to respond to clicks and application switches. Maybe hardware can eventually make windows more usable, but it will always be comparatively slower unless Microsoft fixes it's software.

Re: I just hope the thing competes, somewhere

[Anonymous Coward]

Screams . . . hah. Ha ha. Ha ha ha!

Okay buddy.

So....

[segedunum]

Has anyone looked at Intel's Management System yet......? ;-)

Re:So....

[Highdude702]

Ofcourse but it doesn't bash AMD so.. you know. its not important.

Re:All current Intel chips have vulnerabilities et

[ooloorie]

And worse, Intel (and AMD) have NSA and GCHQ back-doors in their CPUs that operate above ring 0 using chip internal resources that no external security program can lock-down.

Fortunately, there are other choices. If you want a really secure processor, use a soft processor on an FPGA. Many embedded chips probably also fairly secure since there isn't much space to hide anything fancy.

Chip not shipping yet?

[RockDoctor]

AMD, who plans to ship SEV with its upcoming line of Zen processors

So, since no one sensible ever used V0 of anything (with the possible exception of V0 of "broken egg" for making omelettes), then by the time the appropriate die-level or firmware level fixes are incorporated into V1 chips, this should be a non-problem? Am I right?