AMD PSP fTPM Remote Code Execution

AMD PSP suffers from an fTPM remote code execution vulnerability that can be performed through a crafted EK certificate.

MD5 | 49627edce894ee302ff8f2fcf54e0f53

AMD PSP [1] is a dedicated security processor built onto the main CPU die.
ARM TrustZone provides an isolated execution environment for sensitive and
privileged tasks, such as main x86 core startup. See [2] for details.

fTPM is a firmware TPM [3] implementation. It runs as a trustlet
application inside the PSP. fTPM exposes a TPM 2.0 interface over MMIO to
the host [4].

The fTPM trustlet code was found in Corebootas git repository [5] and in
several BIOS update files. The TPM reference implementation code is
published in (TCG) TPM specification. In fact,
the code *is* the spec.
Most TPM vendors implement their TPMs based on the TCG spec code. Vendors
implement the storage layer (where non-volatile data and persistent objects
are stored), connect the crypto library to a good source of entropy, and
sometimes re-implement the low-level crypto functions. However, a lot of
the TPM code is shared with the publicly accessible TPM specification:
request/response marshaling, session management and command execution logic.
This research focused on vendor specific code that diverged from the TCG

Through manual static analysis, weave found a stack-based overflow in the
function EkCheckCurrentCert.
This function is called from TPM2_CreatePrimary with user controlled data -
a DER encoded [6] endorsement key (EK) certificate stored in the NV

A TLV (type-length-value) structure is parsed and copied on to the parent
stack frame. Unfortunately, there are missing bounds checks, and a
specially crafted certificate can lead to a stack overflow:

NESTED_CERT_DATA1 = '\x03\x82\x07\xf0' + 'A * 0x7f0
NESTED_CERT_DATA2 = '\x03\x82' + pack('>H', len(NESTED_CERT_DATA1)) +
CERT_DATA = '\x03\x82' + pack('>H', len(NESTED_CERT_DATA2)) +

Proof Of Concept
Without access to a real AMD hardware, we used an ARM emulator [7] to
emulate a call to EkCheckCurrentCert with the CERT_DATA listed above. We
verified that full control on the program counter is possible:

EkCheckCurrentCert+c8 : B loc_10EE4
EkCheckCurrentCert+60 : LDR R4, =0xB80
EkCheckCurrentCert+62 : ADDS R4, #0x14
EkCheckCurrentCert+64 : ADD SP, R4
EkCheckCurrentCert+66 : POP {R4-R7,PC}
41414140 : ????

As far as we know, general exploit mitigation technologies (stack cookies,
NX stack, ASLR) are not implemented in the PSP environment.

This vulnerability was discovered and reported to AMD by Cfir Cohen of the
Google Cloud Security Team.

09-28-17 - Vulnerability reported to AMD Security Team.
12-07-17 - Fix is ready. Vendor works on a rollout to affected partners.
01-03-18 - Public disclosure due to 90 day disclosure deadline.


Related Posts