Epyc Fail? Researchers Say They Can Defeat AMD’s Virtual Machine Encryption

Discussion in '[H]ard|OCP Front Page News' started by Megalith, May 27, 2018.

  1. Megalith

    Megalith 24-bit/48kHz Staff Member

    Messages:
    12,549
    Joined:
    Aug 20, 2006
    AMD's Epyc server chips utilize Secure Encrypted Virtualization (SEV) to automatically encrypt virtual machines on the fly while stored in memory, but researchers say that they can get around it with a technique dubbed SEVer: “miscreants at the host level can alter a guest's physical memory mappings, using standard page tables, so that the SEV mechanism fails to properly isolate and scramble parts of the VM in RAM.”

    This is not the first time eggheads have uncovered shortcomings in SEV's ability to lock down VMs: previous studies have examined how the memory management system can be exploited by hackers to poke inside encrypted guests. Fraunhofer AISEC's study, emitted on Thursday this week, takes this a step further, demonstrating that, indeed, the entire memory contents of a virtual machine could be pulled by a hypervisor even when SEV is active.
     
  2. thebufenator

    thebufenator Gawd

    Messages:
    998
    Joined:
    Dec 8, 2004
    Looks pretty hard to protect vm's from the host. I mean........ The vm's are running on the just so..........
     
    clockdogg likes this.
  3. BloodyIron

    BloodyIron 2[H]4U

    Messages:
    2,828
    Joined:
    Jul 11, 2005
    While the effort to make VMs secure in this regard is worth applause, it's generally expected that if any system has been compromised at the root, such as at the hypervisor level, that all data is, or will be, effectively fully breached.

    Typically the best way to address this is to make it as impossible as you can for outside parties to even come close to this state. As in, not be able to reach the underlying host.
     
    clockdogg likes this.
  4. Foobario

    Foobario n00bie

    Messages:
    5
    Joined:
    Apr 14, 2018
    Seems this is more of an external security issue in that if one locks the doors and require security clearance one does not get Hypervisor level access to pull off this attack.

    Assuming one got Hypervisor access they could 100s of things before having to resort to using SEVer.
     
    clockdogg likes this.
  5. DukenukemX

    DukenukemX 2[H]4U

    Messages:
    3,900
    Joined:
    Jan 30, 2005
    Is this another one of those exploits that require root? Has Intel been giving someone research money?
     
  6. Ranma

    Ranma Limp Gawd

    Messages:
    163
    Joined:
    Jan 31, 2008
    This exploit only works on guest VM's on the physical host machine that the sysadmin has access to. You can not do it across the network, you can not do it from outside the network. It already requires the sysadmin to be dirty. This is another one of those exploits that requires several other massive security breaches before it can even be done. If you don't trust your sysadmin, you've got other problems than this.
     
  7. velusip

    velusip [H]ard|Gawd

    Messages:
    1,369
    Joined:
    Jan 24, 2005
    It's a good demonstration of how unreliable such a feature really is. "Baked in" security never works.
     
    BitMaster likes this.
  8. pcgeekesq

    pcgeekesq [H]ard|Gawd

    Messages:
    1,306
    Joined:
    Apr 23, 2012
    Trusting your sysadmins is always a mistake. In any well-designed crypto-security system, people are always the easiest attack vector to exploit.

    Like the launch buttons on nuclear missiles, good cryptosecurity systems require two or more authorized people giving independent near-simultaneous two-factor authorization for any operations that might create a vulnerability-- compromising two people is a lot harder than compromising just one. But I don't know whether any of the common hypervisors support this.
     
  9. BitMaster

    BitMaster Limp Gawd

    Messages:
    329
    Joined:
    Nov 10, 2016
    This whole IT landscape is insecure by design.

    You just have to punch hard and long enough to get through, I dare to say that works with any security measure, with tangible things as with logical constructions.

    Someone will always be smarter than you, face it !


    Why am I not surprised at all ?
     
    Sulphademus and clockdogg like this.
  10. M76

    M76 [H]ardness Supreme

    Messages:
    7,707
    Joined:
    Jun 12, 2012
    TLDR: Is this another "hole" where you need physical access to exploit it, discovered by "security researchers" paid for by intel?
     
    clockdogg, Ranma and jnemesh like this.
  11. sirmonkey1985

    sirmonkey1985 [H]ard|DCer of the Month - July 2010

    Messages:
    20,509
    Joined:
    Sep 13, 2008

    at this point i think every half baked security "researcher" and their mom wants their 15 minutes of fame, so if they can find any type of security hole whether it's the most useless crap ever that requires a crap load of other exploits just to do it they're going to publish it..
     
    clockdogg and ZeqOBpf6 like this.
  12. alxlwson

    alxlwson You Know Where I Live

    Messages:
    5,352
    Joined:
    Aug 25, 2013
    This was Intel's response to that new 2-8% performance hit announced yesterday over more S&M stuff
     
    clockdogg and tetris42 like this.
  13. Paul_Johnson

    Paul_Johnson [H] PSU Editor & Admin Staff Member

    Messages:
    14,725
    Joined:
    Aug 29, 2004
    No, it's just more proof of something that mankind has known since the very earliest attacks of any kind. Offense is inherently more successful then defense. Nothing will ever be completely secure or invulnerable to attack.
     
  14. PaulP

    PaulP Gawd

    Messages:
    651
    Joined:
    Oct 31, 2016
    SEV was really meant to counter attacks from other VMs running on the system, which is common in cloud computing environments; you don't know who else you are sharing the hardware with. It would be too much to expect it to have good protection from a compromised hypervisor. So this article is mostly a "no shit sherlock" situation.
     
    clockdogg, alxlwson and Darth Kyrie like this.
  15. aaronspink

    aaronspink [H]ard|Gawd

    Messages:
    1,760
    Joined:
    Jun 7, 2004
    The whole point of SEV is to protect the VM from a malicious admin, so it is a perfectly valid issue.
     
  16. tetris42

    tetris42 [H]ardness Supreme

    Messages:
    4,194
    Joined:
    Apr 29, 2014
    This got me to laugh out loud, thanks.
     
  17. FearTheCow

    FearTheCow [H]ardness Supreme

    Messages:
    6,652
    Joined:
    May 2, 2006
    Oh hey, another locked door yet someone with a key can get in" exploit, who would of thought that would be possible!
     
  18. Grimlaking

    Grimlaking 2[H]4U

    Messages:
    2,243
    Joined:
    May 9, 2006
    Oh my god the horror if you can acess the root you could set up your OWN vm and attach it to the same storage that others were mapped to and access it and NOBODY could stop you!! THE HORROR...

    Who the hell approved this as a vulnerability. This article is full of stupid.
     
  19. aaronspink

    aaronspink [H]ard|Gawd

    Messages:
    1,760
    Joined:
    Jun 7, 2004
    Um, considering the WHOLE ENTIRE POINT OF SEV is to prevent that....

    Stop being ignorant people, the whole entire point of SEV is to prevent the hypervisor from reading the VMs memory to provide isolation and privacy in a hosted environment.
     
    juanrga and ZeroBarrier like this.
  20. Grimlaking

    Grimlaking 2[H]4U

    Messages:
    2,243
    Joined:
    May 9, 2006
    From the mouths of babes... think about this. IT only protects the RUNNING VM's. You stop a VM, change some access perimeters, or even DISABLE that functionality at the OS level then force start the VM suddenly those protections are gone. If you are at the hypervisor level already it is only a matter of time before everything else is compromised in that environment.

    If you have less security on your Hypervisor than you do on your running VM's you have a bigger problem. The Hypervisor should be NEIGH impossible for someone to access that isn't the manager/administrator of that environment. If it is, you need a security review yesterday.
     
    Sulphademus likes this.
  21. urbanman2004

    urbanman2004 Limp Gawd

    Messages:
    176
    Joined:
    Apr 15, 2014
    If the VM's get compromised which would've been under the watch of the assigned network admin then they need to be fired
     
  22. Grimlaking

    Grimlaking 2[H]4U

    Messages:
    2,243
    Joined:
    May 9, 2006
    There is no level of security that will prevent a compromised admin from giving access. Period. I would guess that 30% of corporate entities have one such individual in their employ that is actively leaking data to competitors for a payday on the side. Just a guess mind you. I really hope I am wrong.
     
  23. aaronspink

    aaronspink [H]ard|Gawd

    Messages:
    1,760
    Joined:
    Jun 7, 2004
    In a hosted environment, there can be hundreds to thousands of people that have credentials for hypervisor admin. Things like changing access parameters, stopping, moving, etc a VM are easy to detect and log. A memory poke however is virtually impossible to detect. The whole point of SEV is to isolate and protect the VM from the hypervisor.
     
  24. Grimlaking

    Grimlaking 2[H]4U

    Messages:
    2,243
    Joined:
    May 9, 2006
    If you have hundreds to thousands of people accessing your hypervisor you deserve to be hacked.

    Yes I just said that. If you are irresponsible enough to give hundreds to thousands of users unfettered access to your Hypervisor.

    Now on to this vulnerability. For it to work you need a linux guest running apache. Through this you can access the memory on that host by requesting web pages based on patterns of memory access as noticed from the hypervisor. (Due to this I presume this is the command line hypervisor.) Then you can use that information to formulate web requests to send you the memory areas from the VM in question.

    So this isn't the Epyc Encryption being defeated because you are actually pulling unencrypted data from the VM itself via program calls within the VM.

    For this 'vulnerability' to work, you have to have a specific OS running a Specific Software that is a web host. A compromised Host that you can pull data from as well (meaning memory access requests and such.) THEN using that you can target specific we requests to pull specific memory areas as plane unencrypted text. (Because it is being pulled from within the OS of course it isn't encrypted.).

    For this to NOT work you would need a DLP solution ALSO built into all of this... but that might be a big failure on the part of the OS to not be able to fulfill it's job and the Apache software not to deliver web pages.

    Again this is a shitty version of a vulnerability. I fail to see how this makes the news.
     
  25. Sulphademus

    Sulphademus Limp Gawd

    Messages:
    264
    Joined:
    Mar 18, 2010
    "We are also happy to clarify that the Apache server used to exfiltrate information was running within the encrypted guest – that is, an HTTP web server within an SEV-encrypted virtual machine was used to lift plaintext data out of said protected guest."

    Wait, what? The guest VM was hijacking its own data?