Vulnerability in AMD’s Secure Encrypted Virtualization for EPYC: Update Now to Build 22by 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.
- 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
Post Your CommentPlease log in or sign up to comment.
View All Comments
mode_13h - Tuesday, July 9, 2019 - linkIt exists on unpatched hardware. Therefore, publicizing the issue is relevant.
imaskar - Wednesday, June 26, 2019 - link>reasonable disclosure
imaskar - Wednesday, June 26, 2019 - link>Any user submitting non-standard points will be met with an error.
So, to summarize - only irresponsible people who didn't replace testing values with actual secure seeds are affected.
HyperText - Thursday, June 27, 2019 - linkThis should be highlighted in the article as well!
edzieba - Thursday, June 27, 2019 - linkOr anyone not happy with using the NIST curves. A not wholely imaginary issue, as was seen with Dual_EC_DRBG backdoor. No-one wants to be the next BSAFE
Khato - Wednesday, June 26, 2019 - linkI look forward to seeing what other security vulnerabilities are to be found in AMD's architecture now that the industry will start to have reason to look for them.
Irata - Thursday, June 27, 2019 - linkThey have been / are looking for them.
Gondalf - Friday, June 28, 2019 - linkI knowed AMD cpus are safe by default......ho wait !!! they are bugged too !!!
The number of exploits will rise exponentially with the wider adoption of Epyc SKUs.
No cpu is safe in these days.
Korguz - Friday, June 28, 2019 - linkum yea ok Gondalf... that sounds more like your own hope and speculation then anything.. hasnt amd's chips already shown to be safer then intel's, and the security bugs in those, are not in amd's chips ? but in the end.. we will see...
Targon - Friday, June 28, 2019 - linkDon't forget that since AMD doesn't sit on the same design for all that long, even if a problem were found in an old CPU, the new processors would probably have had enough changes to mean the new chips don't have the problem.
Intel...problems in the memory controller for ALL Intel Core processors are affected? So Intel hasn't done a significant design change? Hyperthreading, no updated implementation in all this time? Honestly, problems from ten years ago should have been resolved, just as a normal part of improving the design, unless the design itself hasn't gotten a major overhaul.