TrustZone Break-in Vulnerabilities in Ampere UEFI MM Drivers (Buffer Overflow and Stack Information Leak)

### Summary A buffer overflow and stack information leak affecting the ARM Ampere Management Mode (MM) Boot Error Record Table (BERT) driver. This code is bundled into the ARM Unified Extensible Firmware Interface (UEFI) firmware and runs in the Secure world at Exception Level 0 (S-EL0). The BERT driver is used to persist unhandled hardware faults (e.g. errors that stem from memory, CPU, system bus, overheating, failing motherboard, or inadequate power supply) from a previous boot cycle. Non-Secure EL1 (NS-EL1) software communicates with this driver using the Secure Monitor Call (SMC) instruction and a predefined shared buffer for message passing. Upon system reboot NS-EL1 would communicate with the BERT driver to check for prior failures and obtain detailed information from the log. Values passed from NS-EL1 to S-EL0 defining the `block_size` of `payload_data` lack proper checks. This allows for an Out-of-Bounds (OOB) write on `payload_data` that could be used for privilege escalation from the normal world to the secure world or an OOB read of stack data from the secure world. Ampere has addressed the vulnerability and posted a [security bulletin](https://amperecomputing.com/products/security-bulletins/amp-sb-0007). #### Analysis NS-EL1 software interacts with the MM BERT driver using the Firmware Framework for A-Profile (FFA) specification through the SMC instruction. The SMC instruction is used to switch to and from the Non-Secure and Secure worlds and FFA is used for dispatching to specific drivers and services. A shared buffer (initialized during the UEFI Driver Execution Environment [DXE] phase as `mNsCommBufferMemRegion` in [ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c](https://github.com/tianocore/edk2/blob/master/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c)) is used to communicate messages between NS-EL1 and the S-EL0 BERT driver. The handler for the BERT MM driver can be reached using the following GUID using the FFA specification. `BertMmHeader` shows the general layout of the communication buffer. Before the `BertMmHandler` dispatch routine is called the MM subsystem copies the shared message buffer to a private memory region to prevent Time-of-Check to Time-of-Use (TOCTOU) issues. As drivers uniquely define the underlying structures in the communicated messages each must perform validation before using the supplied data. *The code snippets included were created through analysis with Ghidra using names contained in string references from the UEFI image. Known functions and variables from the EDK2 repository were also applied.* ``` #define BERT_MM_GUID \ {0xCB01E6A2, 0xB22C, 0x4955, {0xAB, 0x75, 0xAC, 0x65, 0xEF, 0xFA, 0xE9, 0xD8}} #define BERT_MM_MIN_SIZE 0xe #define BERT_MM_MAX_SIZE 0x1000 typedef struct { UINT8 function; UINT8 unknown_0; UINT32 size; RETURN_STATUS status; UINT8 data[1]; } BertMmHeader; ``` The `BertMmHeader` structure includes a function field for dispatching to specific sub-handlers and a `UINT32 size` to represent how much data should be returned. `BERT_MM_MAX_SIZE` defines the maximum size that could be returned. ``` uint8_t *bert_latest; EFI_STATUS BertMmHandler(EFI_HANDLE DispatchHandle,void *RegisterContext, void *CommBuffer, uint64_t *CommBufferSize) { // ... BertMmHeader *header; header = (BertMmHeader *)CommBuffer; if (CommBuffer == NULL || CommBufferSize == 0x0) { return 0; } if (*CommBufferSize < BERT_MM_MIN_SIZE) { if ((size & 0xff) == 0) { return EFI_ACCESS_DENIED; } __LINE__ = 0x21; Debug(DEBUG_ERROR,"%a %d Communication buffer size invalid!\n","BertMmHandler",__LINE__); return EFI_ACCESS_DENIED; } switch(header->function) { case 1: if (BERT_MM_MAX_SIZE < *CommBufferSize - 0xe) { if ((size & 0xff) == 0) { return EFI_ACCESS_DENIED; } __LINE__ = 0x2d;

CVSS 3.1

CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:N/I:L/A:L

Severity from

GitHub (reviewed advisory)

Weakness

CWE-125, CWE-787

• github.com/google/security-research/security/advisories/GHSA-46qj-g894-vrxr
• github.com/google/security-research