TPM2 Log prevention by firmware patching⌗

Introduction⌗

TCG logs can be used to verify the boot chain against tampering, and are often used by software to check that the early boot sequence has not been tampered with, and thus that the kernel is (likely) intact.

However because the root of trust is often the SPI flash itself, such a system is vulnerable to patching of the routines that log and extend the TPM2 Platform Configuration Registers (PCRs). This post will discuss a simple patch that prevents logging of UEFI image hashes and extension of the PCRs related the boot sequence.

Reversing UEFI firmware⌗

Given a firmware binary, the location of the code that performs the measurement must be identified. An easy way I have found to do this is to reference the EDKII source code and find functions relating to measurement, log creation and PCR extension. Tcg2HashLogExtendEvent is a function that resides in Tcg2Dxe, so analysis should be started by dumping the PE with this name or its associated GUID using a tool that can parse a UEFI firmware image, such as UEFITool.

EFI_STATUS   
EFIAPI     
Tcg2HashLogExtendEvent (   
  IN EFI_TCG2_PROTOCOL *This,   
  IN UINT64 Flags,   
  IN EFI_PHYSICAL_ADDRESS DataToHash,   
  IN UINT64 DataToHashLen,   
  IN EFI_TCG2_EVENT *Event   
)

After extracting this binary, the image can be analyzed. I will be using IDA Pro with efiXplorer to more easily manage the GUIDs and automatic location of boot services functions. After performing analysis with efiXplorer, a list of multiple protocols interfaces was produced. AMI_PROTOCOL_INTERNAL_HLXE looked like a good place to start analysis.

Some other interfaces of interest were also found in the same call to
gBS->InstallMultipleProtocolInterfaces.

Given that this is an interface, it likely has other functions, but the function pointer at offset 0 of the pointer appears to perform hashing of the images because of a call to a function in AMI_DXE_HASH_INTERFACE.

Given this discovery, I am going to refer to this function as AMI_PROTOCOL_INTERNAL_HLXE, HLXE being short for Hash Log eXtend Event.

The function responsible for measuring the images in the DXE phase when they are loaded has been identified, and now creating the aforementioned patch is simple. By synchronizing the hex view with the disassembly, we can copy the function bytes to create a crude signature for this firmware.

The resultant bytes are:

48 8B C4 48 89 58 10 4C 89 40 18 48 89 48 08 55 56 57 41 54 41 55 41 56 41 57 48 83 EC

This was present on most firmwares, but I’ve noticed recently that some new firmware builds have some structural changes, thus the following signature handles these two cases:

48 8B C4 48 89 58 10 4? 89 ?? ?? 4? 89 4? ?8 ?? ?? ?? ?? ?? 41 5? 41 5? 41

This appears to work for many modern AMI binaries, but for some older ones, the function signature is vastly different:

4C 89 4C 24 20 4C 89 44 24 18 48 89 54 24 10 48 89 4C 24 08 48 81 EC E8 01 00 00 48 C7

Patch⌗

In either case measurement can be avoided by replacing the measurement function with a stub that returns EFI_SUCCESS early.

48 31 C0   xor rax, rax   (0x0 = EFI_SUCCESS)
C3         ret

The final patch, after converting to a format UEFIPatch can use, is as follows:

# Return EFI_SUCCESS early in AMI's internal HashLogExtendEvent function.   
39045756-FCA3-49BD-8DAE-C7BAE8389AFF 10 P:488BC4488958104.89....4.894..8..........415.415.41:4831C0C3..........................................
39045756-FCA3-49BD-8DAE-C7BAE8389AFF 10 P:4C894C24204C89442418488954241048894C24084881ECE801000048C7:4831C0C3..................................................

Results⌗

This patch functions as expected on my MSI AM5 motherboard, here are the results of the PCRs after the patch. PCR0 still contains at least one measurement, but I believe this is only the EV_S_CRTM_VERSION, which is unaffected by these patches. I have not verified this.

Applications⌗

By combining this firmware patch with a secure boot patch, (e.g. InsecureBoot), and UEFI bootkit that replays clean logs while loading a malicous payload, it is possible to pass boot attestation for applications that require it.

A wasm based UEFIPatch (with this patch available to apply in a few clicks) is available at https://uefipatch.virtfunc.com/

Future Work⌗

This patch is a very blunt instrument, a better solution would involve embedding a flag in the EFI binary to request that the firmware does not measure the image.

TPM2 AntiLog