AMD confirmed the security concerns raised by CTS-Labs last week. The CTS-Labs vulnerability disclosure was widely criticized, even at STH, for not following industry standard practice in a 90-day notification. AMD flipped the script on CTS-Labs both confirming the vulnerabilities and then explaining why they are essentially a marginal issue and saying that fixes are underway.
How AMD Flipped the Script
During the disclosure, CTS-Labs representatives said the reason for a day 0 / day 1 disclosure was that AMD could not release mitigations in time. AMD is showing quite the opposite. About a week after the disclosure, AMD says that it will have BIOS updates and patches available in the coming weeks to address the vulnerabilities. There are two parts to how this is an excellent response. First, it is contrasting its response with Intel’s multi-month work on the Meltdown and Spectre vulnerabilities. Second, it is clearly showing that CTS-Labs, following responsible, industry standard, 90-day disclosure would have given plenty of time to mitigate before disclosure. A not-so-subtle dig at Intel and CTS-Labs while showing it is taking security seriously is a good way to change the storyline.
AMD Addresses CTS-Labs Vulnerabilities
AMD says it confirmed the vulnerabilities but there is a big caveat. These vulnerabilities require low-level admin access. Most administrators will tell you that this is a recipe for disaster. If an attacker has this level of access, they have wide purvue to launch attacks. Essentially, if your security has completely failed already, then the CTS-Labs exploits can be utilized.
Here is the table from AMD on the vulnerabilities, the potential impact and the mitigations:
| Vulnerability Groups | Problem Description & Method of Exploitation | Potential Impact | Planned AMD Mitigation |
| MASTERKEY
and PSP Privilege Escalation (AMD Secure Processor or “PSP” firmware) |
Issue: Attacker who already has compromised the security of a system updates flash to corrupt its contents. AMD Secure Processor (PSP) checks do not detect the corruption.
Method: Attacker requires Administrative access |
Attacker can circumvent platform security controls. These changes are persistent following a system reboot. | Firmware patch release through BIOS update. No performance impact is expected.
AMD is working on PSP firmware updates that we plan to release in the coming weeks. |
|
RYZENFALL and FALLOUT
(AMD Secure Processor firmware) |
Issue: Attacker who already has compromised the security of a system writes to AMD Secure Processor registers to exploit vulnerabilities in the interface between x86 and AMD Secure Processor (PSP).
Method: Attacker requires Administrative access. |
Attacker can circumvent platform security controls but is not persistent across reboots.
Attacker may install difficult to detect malware in SMM (x86). |
Firmware patch release through BIOS update. No performance impact is expected.
AMD is working on PSP firmware updates that we plan to release in the coming weeks. |
| “Promotory” Chipset |
|||
| CHIMERA
“Promontory” chipset used in many socket AM4 desktop and socket TR4 high-end desktop (HEDT) platforms. AMD EPYC server platforms, EPYC and Ryzen Embedded platforms, and AMD Ryzen Mobile FP5 platforms do not use the “Promontory” chipset. |
Issue: Attacker who already has compromised the security of a system installs a malicious driver that exposes certain Promontory functions.
Method: Attacker requires Administrative access. |
Attacker accesses physical memory through the chipset.
Attacker installs difficult to detect malware in the chipset but is not persistent across reboots. |
Mitigating patches released through BIOS update. No performance impact is expected.
AMD is working with the third-party provider that designed and manufactured the “Promontory” chipset on appropriate mitigations. |
(Source: AMD CTO Mark Papermaster)
Yeah, if those are important security bugs, a lot of the hardware from 5 years ago was ridden with such bugs given that signed firmware or checks was not always there…
I wonder how CTS-lab would have described meltdown and spectre if they had discovered them…
Probably like the Armageddon and the rise of the dead.
I would not call the disclosure of Meltdown / Spectre responsible, quite the opposite. It was selective disclosure, and I believe strongly anti-competitive.
I also don’t know why we still put up with closed firmware and other anti-features in CPUs / Chipsets (like Intel ME).