Skip to main content

AMD Discloses Vulnerabilities in EPYC Processors’ Secure Encrypted Virtualization

AMD EPYC Processor
(Image credit: AMD)

AMD disclosed two exploits targeting the Secure Encrypted Virtualization (SEV) feature used by its first-, second-, and third-gen EPYC processors ahead of their presentation at the 15th IEEE Workshop on Offensive Technologies (WOOT’21).

The first exploit, CVE-2020-12967, is set to be presented in a paper from researchers at Fraunhofer AISEC and the Technical University of Munich titled “SEVerity:  Code Injection Attacks against Encrypted Virtual Machines.”

AMD said the researchers who discovered that flaw “make use of previously discussed research around the lack of nested page table protection in the SEV/SEV-ES feature which could potentially lead to arbitrary code execution within the guest.” 

The second exploit, CVE-2021-26311, will be detailed in a paper with the interestingly capitalized title of  “undeSErVed trust: Exploiting Permutation-Agnostic Remote Attestation” from researchers at the University of Lübeck.

AMD said the research showed ”memory can be rearranged in the guest address space that is not detected by the attestation mechanism which could be used by a malicious hypervisor to potentially lead to arbitrary code execution within the guest.”

Even though both exploits affect three generations of EPYC processors, only third-generation models will receive a mitigation directly from AMD courtesy of the SEV-Secure Nested Paging feature described in a white paper in January 2020.

As for first- and second-gen EPYC processors: AMD said it “recommends following security best practices” to mitigate exposure to these exploits. That isn’t particularly actionable advice, but fortunately, it shouldn’t prove too hard to follow. We're following up to see if these issues will receive their own mitigations. 

AMD said the “exploits mentioned in both papers require a malicious administrator to have access in order to compromise the server hypervisor.” Requiring physical access should limit the exploits’ reach—especially during a global pandemic.

More information about both exploits is supposed to arrive during WOOT’21 on May 27. (The papers are listed as “Trololo (Title under embargo)” on the workshop’s website; it seems AMD posted their titles earlier than it was supposed to.)

  • hotaru.hino
    This makes me wonder how secure AMD's PSP really is, considering the feature relies on that.

    Or rather, if AMD wants to really put a leg up against Intel, they should make it open for auditing.
    Reply
  • ginthegit
    Love it, Just like Intel, it seems that the features meant to increase security actuually decreases it!

    Some would almost say they have yielded to the FBI in their desired want for Backdoors for spying on its citizens.

    LOL Security features = Failed security
    Reply
  • waltc3
    Yawn, both vulnerabilities require Administrator access...another dud "report" from university hackers that a company has to respond to. No exploits (of course)...and the sensational tech press strikes out again, imo.
    Reply
  • Soaptrail
    "Requiring physical access should limit the exploits’ reach" can companies trust their cloud server provider?
    Reply
  • NatalieEGH
    If this is a vulnerability that must be addressed then EVERY system administrator in the world should be fired.

    The so-called vulnerability requires a system administrator to be physically connected with the system. That means on-site using a trusted console (the one used to start, restart after a termination (hopefully from a system shutdown done at that terminal and not a system abort/crash, application of updates, initiate system debugging, ...). The system administrator should be a "Trusted User". They have all power on the machine.

    Okay they discovered the system administrator working from the system console has the ability to cause the injection of code into a running virtual system. BIG FREAKING DEAL.

    I was a system programmer/system administrator for years. I actually broke the system (luckily a development and testing system with only a few hundred users on) on more than one occasion. I regularly was working on extraction of information from the OS and when needed injection/modification of information. IT WAS MY JOB. PEOPLE KNEW WHEN I WAS BEING DANGEROUS.

    Maybe there was no intention to allow the system administrator that particular ability. Maybe if the administrator is a thief, terrorist, or just stupid prankster they can cause problems. If a site hires an administrator and gives them the complete set of keys to the kingdom (including in this case a few keys not known on the key chain), they are stupid and the HR personnel, the supervisor, and everyone involved in the hiring should be fired.

    To be honest depending on what was done and whether I consider the person was a further danger, if I was the boss, I would consider hiring the person to be head of the department with a salary big enough the person will stay legal just because of the legal/respectable/small bragging rights lifestyle they would be living.

    This might be a flaw in the intended way the chip works but it is hardly a security issue.
    Reply
  • NatalieEGH
    Soaptrail said:
    "Requiring physical access should limit the exploits’ reach" can companies trust their cloud server provider?

    If not, they should either be looking for a different provider or bringing the functions back in-house.
    Reply