Vulnerability in AMD’s Secure Encrypted Virtualization for EPYC

[LukeSavenije]

Sources: @AluminiumTech, anandtech

 

One of the key elements of building a processor is that designing a secure product involves reducing the ‘attack surface’ as much as possible: the fewer ways an attack can get in, the safer your product is, but a researcher at Google found a vulnerability in the way AMD’s EPYC processors provide Secure Encrypted Virtualization (SEV) which would allow an attacker to recover a secure key that would provide access between previously isolated VMs on a system. AMD has since released an update to the firmware which patches this issue.

 

Quote

AMD’s Secure Encrypted Virtualization (SEV) feature on its EPYC processors allows a system that runs multiple virtual machines through a hypervisor to have those virtual machines purely isolated from one another. By producing encryption keys at the hardware level, the hypervisor can maintain the equivalent of separate secure enclaves between VMs with individual keys. The SEV code runs deep within the EPYC processor, specifically on a Platform Security Processor (PSP), which is a hardened ARM Cortex core.

 

The SEV feature relies on elliptic-curve cryptography for its secure key generation, which runs when a VM is launched. The VM initiates the elliptic-curve algorithm by providing points along its NIST (National Institute of Standards and Technology) curve and relaying the data based on the private key of the machine. Due to the algorithm involved, if the points provided to the algorithm at the VM launch are both non-standard and small, parts of the algorithm are reduced to zero, leaving behind a path by which over repeated VM launches, an attacker could gather enough data to reassemble the private key of the system.

 

More details are provided in the full disclosure documentation, which indicates that SEV firmware version 0.17 build 11 and earlier are vulnerable.

 

This vulnerability was found by Cfir Cohen as part of the Google Cloud security team, and carries the CVE-2019-9836designation. AMD’s response to this issue can be found on its security website.

 

Quote

Feb 19th: Vulnerability disclosed to AMD PSIRT

Feb 23rd: AMD confirms the bug

Feb 25th: Google shares Proof of Concept with AMD

May 13th: AMD requests a 30 day extension before full disclosure

June 4th: AMD releases fixed firmware to 0.17 Build 22

June 7th: AMD requests a 2 week extension

June 25th: Public disclosure

 

Quote

 

well... time to update again businesses

(and @Den-Fi)

[lewdicrous]

They took a page out of Intel's book, cool.

[LukeSavenije]

Just now, lewdicrous said:

They took a page out of Intel's book, cool.

as they say

 

another day, another vulnerability

[Guest]

Lol, yes I took care of this the day I set it up.

I appreciate the heads up though!

 

Edit: Not because I knew about it, mainly because I always update BIOS and test before deploying something.

[LukeSavenije]

1 minute ago, Den-Fi said:

Lol, yes I took care of this the day I set it up.

I appreciate the heads up though!

 

[AlTech]

1 hour ago, lewdicrous said:

They took a page out of Intel's book, cool.

@LukeSavenije

 

This isn't a hardware vulnerability.

 

It's a software vulnerability which was found on the security coprocessor found in all AMD EPYC CPUs. As such the software has been updated.

 

Edit: I should probably explain the security coprocessor runs its own software and OS.

[TrigrH]

inb4 intels entire R&D department is dedicated to two things:

1. Finding security flaws in AMDs processors then leaking them to press.

2. Trying to get more performance out of 14nm+++++++++++++++++++++++++++++++++.

[Arika]

14 hours ago, AluminiumTech said:

security coprocessor runs its own software and OS

is it kind of like the intel management engine?

 

 

3 minutes ago, TrigrH said:

inb4 intels entire R&D department is dedicated to finding security flaws in AMDs processors then leaking them to press, and trying to get more performance out of 14nm.

...Jesus Christ no thread can go by without a bash at intel can it?...

[AlTech]

1 minute ago, Arika S said:

is it kind of like the intel management engine?

 

Yes.

[RejZoR]

From February to June is quite some time, but I guess such fixes take time if it's across more products that might not interact the same. It's good to hear it was fixed and that it doesn't represent any performance hit. Those are the most annoying ones. Along with unfixable ones that is...

[TrigrH]

4 minutes ago, Arika S said:

...Jesus Christ no thread can go by without a bash at intel can it?...

When you have been on 14nm for nearly 5 years it makes sense.

[Jito463]

This is a perfect example of why I'm not fond of these "secure" modules within the processor (that goes for both AMD and Intel).  At least they got a patch out pretty quickly.

[Sauron]

22 hours ago, AluminiumTech said:

@LukeSavenije

 

This isn't a hardware vulnerability.

 

It's a software vulnerability which was found on the security coprocessor found in all AMD EPYC CPUs. As such the software has been updated.

 

Edit: I should probably explain the security coprocessor runs its own software and OS.

It's also a pretty underwhelming software vulnerability to be honest - the attack vector seems impractical and the fix is really easy.

[Loote]

From the title I was much more afraid, there are always the ones who don't patch, but if that's the case, I'd be much more worries about OS and the rest of the software than this kind of a vulnerability.

[mr moose]

11 hours ago, Tedny said:

Finally, they found something in Epyc. 3 years later) 

It took them 15 years to find Intel's and they knew it was there.  What's your point?

 

This has nothing to do with being AMD or being Intel, and every time I see posts where the brand is brought into the discussion like it has some intrinsic importance my hope for the future dies a little bit.