This is an adaptation for Steemit of Trail of Bits Blog. if you want to have it in HTML format you can see it here.
Two weeks ago, we were engaged by CTS Labs as independent consultants at our standard consulting rates to review and confirm the technical accuracy of their preliminary findings. We participated neither in their research nor in their subsequent disclosure process. Our recommendation to CTS was to disclose the vulnerabilities through a CERT.
Our review of the vulnerabilities was based on documentation and proof-of-concept code provided by CTS. We confirmed that the proof-of-concept code worked as described on the hardware we tested, but we will defer to AMD for a final determination of their full impact, patches, and remediation recommendations.
So this https://t.co/vYktqat10K business… CTS Labs asked us to review their research last week, and sent us a full technical report with PoC exploit code for each set of bugs.
— Dan Guido (
@dguido) March 13, 2018
Most of the discussion after the public announcement of the vulnerabilities has been focused on the way they were disclosed rather than their technical impact. In this post, we have tried to extract the relevant technical details from the CTS whitepaper so they can be of use to the security community without the distraction of the surrounding disclosure issues.
The security architecture of modern computer systems is based on a defense in depth. Security features like Windows Credential Guard, TPMs, and virtualization can be used to prevent access to sensitive data from even an administrator or root.
The AMD Platform Security Processor (PSP) is a security coprocessor that resides inside AMD CPUs and is implemented as a separate ARM CPU. It is similar to Intel ME or the Apple Secure Enclave. It runs applications that provide security features like the TPM or Secure Encrypted Virtualization. The PSP has privileged access to the lowest level of the computer system.
The PSP firmware can be updated through a BIOS update, but it must be cryptographically signed by AMD. Physical access is usually not required to update the BIOS and this can be done with administrator access to the computer. The MASTERKEY vulnerability bypasses the PSP signature checks to update the PSP with the attacker’s firmware. Cfir Cohen on the Google Cloud Security Team discovered a similar issue in an adjacent area of the AMD PSP in September 2017.
The PSP also exposes an API to the host computer. The FALLOUT and RYZENFALL vulnerabilities exploit the PSP APIs to gain code execution in the PSP or the SMM.
The “chipset” is a component on the motherboard used to broker communication between the processor, memory, and peripherals. The chipset has full access to the system memory and devices. The CHIMERA vulnerability abuses exposed interfaces of the AMD Promontory chipset to gain code execution in the chipset processor.
Exploitation requirements
Potential technical impact
There is no immediate risk of exploitation of these vulnerabilities for most users. Even if the full details were published today, attackers would need to invest significant development efforts to build attack tools that utilize these vulnerabilities. This level of effort is beyond the reach of most attackers (see https://www.usenix.org/system/files/1401_08-12_mickens.pdf, Figure 1)
These types of vulnerabilities should not surprise any security researchers; similar flaws have been found in other embedded systems that have attempted to implement security features. They are the result of simple programming flaws, unclear security boundaries, and insufficient security testing. In contrast, the recent Meltdown and Spectre flaws required previously unknown techniques and novel research advances to discover and exploit.
