Slashdot Mirror
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.
[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.
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.
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.
A thousand pounds of wood moving at 300 feet per minute. Don't get in the way.
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.
and are now just releasing this just before the release of the chips?
by TheSpoom (715771) Uncaring Linux user here. I have nothing to add to this but please continue. *munches popcorn*
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?
Silence is a state of mime.
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...
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.
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.
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
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.
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
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.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
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.
Has anyone looked at Intel's Management System yet......? ;-)
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.
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, 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?
Birds are not dinosaur descendants;birds are dinosaurs, for all useful meanings of "birds", "are" and "dinosaurs"
You think you can defend against a malicious hypervisor?
Wow, I have a bridge to sell you...
---
According to the latest ruleset, this post should be modded as Vorpal Flamebait +5.
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.