Summary

BINARLY efiXplorer team has discovered a heap buffer overflow vulnerability in the child SW SMI handler on multiple HP devices that allows heap data corruption.

Vulnerability Information

• BINARLY internal vulnerability identifier: BRLY-2021-038
• HP PSIRT assigned CVE identifier: CVE-2022-23930
• CERT/CC assigned case number: VU#683814
• CVSS v3.1 8.2 High AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H

Affected HP firmwares with confirmed impact by Binarly team

Device/Firmware	File Name	SHA256 (File PE32 section)	File GUID
Device / firmware version: 02.05.01 Rev.A	0193	40b09ebb66f7bf702edaaccb08a3f4a5ae96d1f08e1b14cb33b9341d6539fee2	12D06948-6569-42C9-ABA3-E12BACE7B234

Potential impact

An attacker can exploit this vulnerability to elevate privileges from ring 0 to ring -2, execute arbitrary code in System Management Mode - an environment more privileged than operating system (OS) and completely isolated from it. Running arbitrary code in SMM additionally bypasses SMM-based SPI flash protections against modifications, which can help an attacker to install a firmware backdoor/implant into BIOS. Such a malicious firmware code in BIOS could persist across operating system re-installs. Additionally, this vulnerability potentially could be used by malicious actors to bypass security mechanisms provided by UEFI firmware (for example, Secure Boot and some types of memory isolation for hypervisors).

Vulnerability description

The vulnerability exists in child the SW SMI handler registered with GUID 4dd19464-68d5-4c6d-9a6f-a6049afed855 and located at offset 0x19A0 in the driver.

It should be noted, that the HandlerType is a stack variable in this case:

.text:000000000000160D                 mov     [rbp+HandlerType.Data1], 4DD19464h
.text:0000000000001614                 ...
.text:000000000000161B                 mov     dword ptr [rbp+HandlerType.Data2], 4C6D68D5h
.text:0000000000001622                 mov     dword ptr [rbp+HandlerType.Data4], 4A66F9Ah
.text:0000000000001629                 mov     dword ptr [rbp+HandlerType.Data4+4], 55D8FE9Ah

The pseudocode for this handler is shown below:

EFI_STATUS __fastcall SmiHandler_19A0(
        EFI_HANDLE DispatchHandle,
        const void *Context,
        void *CommBuffer,
        UINTN *CommBufferSize)
{
  // [COLLAPSED LOCAL DECLARATIONS. PRESS KEYPAD CTRL-"+" TO EXPAND]

  ...
  // size not validated, we can allocate small buffer, then write out of bounds
  CommBufferCopy = (unsigned __int64 *)GetCopy(*CommBufferSize, CommBuffer);
  if ( CommBufferCopy )
  {
    ...
    *((_QWORD *)CommBufferCopy + 2) = Status;     // OOB write
    CopyMemS(CommBuffer, *CommBufferSize, CommBufferCopy, *CommBufferSize);
    Clear(&CommBufferCopy1, *CommBufferSize);
  }
  return 0;
}

GetCopy will allocate a buffer of size *CommBufferSize and copy the contents of the CommBuffer into this buffer:

void *__fastcall GetCopy(UINTN Size, const void *Buffer)
{
  // [COLLAPSED LOCAL DECLARATIONS. PRESS KEYPAD CTRL-"+" TO EXPAND]

  result = AllocatePool(Size); // gSmst->SmmAllocatePool wrapper
  if ( result && Size && result != Buffer )
    return CopyMem(result, Buffer, Size);
  return result;
}

It means that CommBufferCopy is a pointer to a buffer on the heap with the size *CommBufferSize. *CommBufferSize not validated in the SMI handler. Thus, if the *CommBufferSize is less than 24, then out-of-bounds write in heap buffer may occur.

To exploit this vulnerability it is enough to:

1. Set up a Communication Buffer (with MessageSize < 24).
2. Trigger the SW SMI Handler (SW SMI number and pointer to Communication Buffer are specified in UEFI ACPI table) via 0xB2 IO port.

Disclosure timeline

This bug is subject to a 90 day disclosure deadline. After 90 days elapsed or a patch has been made broadly available (whichever is earlier), the bug report will become visible to the public.

Disclosure Activity	Date
HP PSIRT is notified	2021-07-12
HP PSIRT confirmed reported issue	2021-08-09
HP PSIRT assigned CVE number	2021-08-19
CERT/CC created a case	2021-11-16
HP PSIRT provide patch release	2022-03-08
BINARLY public disclosure date	2022-03-08

Acknowledgements

BINARLY efiXplorer team