Vulnerability in AMD’s Secure Encrypted Virtualization for EPYC: Update Now to Build 22
by Dr. Ian Cutress on June 26, 2019 7:00 AM EST
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. For the white knights of the security world, when a vulnerability is found, the process usually goes through a period of responsible disclosure, i.e. the issue is presented to the company, and they are often given a certain time to fix the issue (to help customers) before the full disclosure is made public (in case it might be swept under the rug). Using this method, 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.
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.
AMD has identified the code responsible, and has adjusted the algorithm to only accept standard NIST curve points. Any user submitting non-standard points will be met with an error. This fix is applied in SEV firmware version 0.17 build 22, which AMD rolled out to its OEM partners for firmware updates on June 4th. Users that implement SEV within their critical systems are suggested to reach out to their platform vendors for corresponding updates. AMD does state that certificates already generated on vulnerable VMs will still be valid even after VM migration, and as a result VMs should be restarted where possible.
This vulnerability was found by Cfir Cohen as part of the Google Cloud security team, and carries the CVE-2019-9836 designation. AMD’s response to this issue can be found on its security website.
For those interested, the full disclosure document gives the following timeline for this issue:
- 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 (AMD)
- June 7th: AMD requests a 2 week extension
- June 25th: Public disclosure
Update: It's worth noting that the Elliptic Curve Cryptography was one of the units that the Hygon joint venture changed on its EPYC-like Dhyana processors.
Related Reading
- HP’s Endpoint Security Controller: More Details About A New Chip in HP Notebooks
- HP’s Security Push: Sure Sense & Endpoint Security Controller
- BlackBerry Acquires Cylance, Gets AI & ML Security Technology
- Synaptics' Next-Gen Fingerprint Sensor Security: The FS7600 Match-In-Sensor
- Ian Cutress Talks AMDFlaws and Security on TechTeamGB Weekly News
- Security Researchers Publish Ryzen Flaws, Gave AMD 24 hours Prior Notice
- Lenovo, SuperFish and Security
Facebook
Twitter
RSS
33 Comments
View All Comments
nivedita - Friday, June 28, 2019 - link
You don’t run a browser on your home computer?Kvaern1 - Saturday, June 29, 2019 - link
Of course I do, how does this affect my browser in any meaningful way ?mode_13h - Monday, July 1, 2019 - link
Because side-channel attacks have been demonstrated in browser-based code. So, you don't need to download and install anything to be affected by malicious code.PeachNCream - Wednesday, June 26, 2019 - link
Some comment in response to a query about why Anandtech wasn't reporting on the latest Intel issues was answered with a, "We're waiting for Intel to respond," which, given that AT never published anything about the problem, seems like a steaming pile of bull.darkswordsman17 - Wednesday, June 26, 2019 - link
Yep, and considering how severe those vulnerabilities are (both for security and mitigations destroying performance), they should be refusing to cover any Intel news or products until Intel gives them a proper response, and if Intel wants to wait until they have products that aren't affected by them (and also don't suffer huge performance losses to mitigate) then they should expect no one to recommend their stuff until then. I can only imagine how much better these new Epyc chips will be than the Intel stuff for those markets (as they're affected by the mitigations more than general consumer stuff).They should be contacting the groups that found the exploits and have discussions with them as well, since Intel clearly intends there to be a vacuum in coverage of them based on Intel not talking about them at all.
Unfortunately I expect Intel's response is going to be trying to find vulnerabilities in AMD's chips and then try to make them seem every bit as bad, just like they pulled with Spectre/Meltdown.
close - Tuesday, July 2, 2019 - link
The other response was marking the people who asked as spammers ;). IntelTech does have a ring to it.CityBlue - Sunday, July 7, 2019 - link
That was my comment. Believe me now?Come on Anandtech, your silence over Intel vulnerabilities is... deafening. No more excuses - let's see your "deep dive" on the latest Intel vulnerability whether Intel respond to you or not. If you continue to sit on it any longer it just makes you look like Intel apologists.
CityBlue - Sunday, July 7, 2019 - link
The sad fact is that the obvious lack of coverage for Intel vulnerabilities undermines Anandtech's credibility as an authoritative source of CPU information, especially where Intel is concerned. What's the point in writing thousands of words in the latest deep-dive article when a major Intel security vulnerability that significantly impacts performance goes totally unreported? It tends to color most of what this organ now produces, as it's far from independent.Sites such as phoronix.com are far more transparent and willing to dish the dirt when it is necessary regardless of who the vendor may be - the benefit of being fully independent and not funded - (directly or indirectly) - by Intel, I guess.
mode_13h - Tuesday, July 9, 2019 - link
I've found Phoronix' hardware reviews have a tendency to be a bit biased, as he's almost entirely dependent on vendors for supplying the hardware.However, you're right that he doesn't bury embarrassing stories.
WaltC - Thursday, July 4, 2019 - link
Well the article clarifies that AMD had issued a fix several builds back, apparently before this article was written...? Or was it the article updated later? Anyway, the problem no longer exists.