[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[FD] AMD-PSP: fTPM Remote Code Execution via crafted EK certificate

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 Coreboot’s git repository [5] and in
several BIOS update files. The TPM reference implementation code is
published in trustedcomputinggroup.org (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, we’ve 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.

[1] http://www.amd.com/en-us/innovations/software-technologies/security
[3] https://en.wikipedia.org/wiki/Trusted_Platform_Module
[5] https://github.com/coreboot/blobs/tree/master/southbridge/amd/avalon/PSP
[6] https://en.wikipedia.org/wiki/X.690#DER_encoding
[7] http://www.unicorn-engine.org/

Sent through the Full Disclosure mailing list
Web Archives & RSS: http://seclists.org/fulldisclosure/