Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
AMD Privacy Security Cloud Communications Encryption Software

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.

This discussion has been archived. No new comments can be posted.

Researchers Point Out 'Theoretical' Security Flaws In AMD's Upcoming Zen CPU

Comments Filter:
  • by mhkohne ( 3854 ) on Friday December 09, 2016 @08:47PM (#53456973) Homepage

    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.

    • by 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 hypervi
      • 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.

    • by haruchai ( 17472 ) on Friday December 09, 2016 @09:43PM (#53457191)

      "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.

    • 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 even

  • by 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 ab

    • 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.

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

  • Non story (Score:5, Insightful)

    by wbr1 ( 2538558 ) on Friday December 09, 2016 @10:04PM (#53457263)

    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?

    • 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

      • 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.
      • 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.

    • by 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

    • 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

  • 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 Kjella ( 173770 )

      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.

    • by Luthair ( 847766 )
      I imagine the idea is that another VM manages to exploit a flaw in the hypervisor gaining control.
      • by gweihir ( 88907 )

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

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

    • by gweihir ( 88907 )

      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

      • 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

        • by gweihir ( 88907 )

          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

  • by Megane ( 129182 ) on Saturday December 10, 2016 @07:34AM (#53458563) Homepage
    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.
  • 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 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

  • Has anyone looked at Intel's Management System yet......? ;-)
  • 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?

Simplicity does not precede complexity, but follows it.

Working...