Researchers Point Out 'Theoretical' Security Flaws In AMD's Upcoming Zen CPU (bleepingcomputer.com) 57
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.
[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.
Re: (Score:2)
Re:Question (Score:4, Insightful)
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: (Score:2)
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: (Score:2)
You think you can defend against a malicious hypervisor?
Wow, I have a bridge to sell you...
Re: (Score:2)
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 (Score:5, Insightful)
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: (Score:1)
Re: (Score:1)
Re: (Score:3)
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 (Score:4)
"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: (Score:2)
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 even
All current Intel chips have vulnerabilities etc (Score:2, Funny)
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 ab
Re: (Score:2)
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.
So how long did they know? (Score:2)
and are now just releasing this just before the release of the chips?
Non story (Score:5, Insightful)
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: (Score:2)
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 befor
Re: (Score:1)
Re: (Score:2)
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.
Doesn't need to be: (Score:1)
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
Re: (Score:2)
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
Not the point (Score:2)
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: (Score:2)
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: (Score:2)
Re: (Score:2)
Then it is game over. And this is not a surprise at all. Virtualization _decreases_ security, by offering more attack surface.
Re: (Score:1)
What if the DHS hacks your Hypervisor? Maybe people will pay a premium to have a more protected VM IaaS setup.
Re: (Score:2)
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, de
Re: (Score:2)
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: (Score:2)
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
Re: (Score:2)
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. Wh
tl;dr (Score:3)
Malicious Hypervisor???? (Score:2)
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 (Score:2)
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
So.... (Score:2)
Re: (Score:1)
Chip not shipping yet? (Score:2)
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?