[BRLY-2021-036] SMM memory corruption vulnerability in SMM driver on multiple HP devices.

Summary

Binarly REsearch Team has discovered a SMM memory corruption vulnerability on multiple HP devices allowing a possible attacker to write fixed or predictable data to SMRAM. Exploiting this issue could lead to escalating privileges to SMM.

Vulnerability Information

• BINARLY internal vulnerability identifier: BRLY-2021-036
• HP PSIRT assigned CVE identifier: CVE-2022-23928
• 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 REsearch Team

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 the SMM additionally bypasses SMM-based SPI flash protections against modifications, which can help an attacker to install a firmware backdoor/implant into the BIOS. Such a malicious firmware code in the BIOS could persist across operating system re-installs. Additionally, this vulnerability potentially could be used by threat actors to bypass security mechanisms provided by the UEFI firmware (for example, Secure Boot and some types of memory isolation for hypervisors).

Vulnerability description

The vulnerability exists in the child SW SMI handler registered with GUID 1992c4b6-04b1-47f9-45a8-bd698b194292 and located at offset 0x1CA4 in the driver.The pseudocode for this handler is shown below:

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

  if ( CommBuffer && CommBufferSize && (-(*CommBufferSize != 28) & 0x8000000000000002) == 0 )
  {
    if ( !CommBuffer->BufferPtr )
      goto _Exit;
    p_BufferSize = &CommBuffer->BufferSize;
    Size = *&CommBuffer->BufferSize;
    if ( !Size )
      goto _Exit;
    Res = SmmIsBufferOutsideSmmValid(CommBuffer->BufferPtr, Size);
    Status = -(Res == 0) & EFI_SECURITY_VIOLATION;
    if ( Res )
    {
      Res1 = 0;
      if ( p_BufferSize )
        Res1 = SmmIsBufferOutsideSmmValid(p_BufferSize, 8);
      Status = -(Res1 == 0) & EFI_SECURITY_VIOLATION;
    }
    if ( !Status )
    {
_Exit:
      BufferPtr = CommBuffer->BufferPtr;
      if ( CommBuffer->Case == 1 )
        Status1 = sub_1A48(BufferPtr);
      else
        // Vulnerability here
        Status1 = sub_1AB8(BufferPtr);
      Status = Status1;
    }
    CommBuffer->Status = Status;
  }
  return 0i64;
}

In this case the CommBuffer has the following structure:

00000000 CommBufferStruct struc ; (sizeof=0x1C, mappedto_235)
00000000 BufferPtr       dq ?
00000008 BufferSize      dd ?
0000000C field_C         dd ?
00000010 Status          dq ?
00000018 Case            dd ?
0000001C CommBufferStruct ends

As we can see, the nested pointer CommBuffer->BufferPtr with size CommBuffer->BufferSize is validated (checking that it does not overlap with SMRAM).But CommBuffer->BufferSize is only compared to zero, not the expected fixed value.This means that an attacker can set the CommBuffer->BufferSize value to 1 and then the SmmIsBufferOutsideSmmValid function will check that only the first byte does not overlap with SMRAM.

The pseudocode of the function sub_1AB8 is shown below:

EFI_STATUS __fastcall sub_1AB8(__int64 BufferPtr)
{
  // [COLLAPSED LOCAL DECLARATIONS. PRESS KEYPAD CTRL-"+" TO EXPAND]

  Status = EFI_INVALID_PARAMETER;
  if ( BufferPtr )
  {
    AllocatedBuffer = SmmAllocatePool(BufferPtr, 0x30);
    if ( AllocatedBuffer )
    {
      Buffer = ZeroMem(AllocatedBuffer, 0x30);
      if ( Buffer )
      {
        // Always return 0
        Status = sub_1F20(&v7);
        if ( !Status )
        {
          *(_DWORD *)(BufferPtr + 21) = v7;
          *(_WORD *)(BufferPtr + 25) = v8;
          *(_BYTE *)(BufferPtr + 27) = v9;
          CopyMem48BytesMax(Buffer, v5, BufferPtr + 20, *(unsigned __int16 *)(BufferPtr + 2));
        }
        if ( !Status )
          Status = sub_1A48(Buffer);
        Free(Buffer);
      }
    }
  }
  return Status;
}

The following code should always trigger:

*(_DWORD *)(BufferPtr + 21) = v7;
*(_WORD *)(BufferPtr + 25) = v8;
*(_BYTE *)(BufferPtr + 27) = v9;

Suppose that CommBuffer->BufferSize is 1 and CommBuffer->BufferPtr points to (SMRAM_BASE - 1).It mean that potencial attacker can corrupt some structures at the beginning of SMRAM (for example, change the SMM S3 resume code pointer and hijack execution flow during SMM S3 wake up procedure). This could lead to gaining arbitrary code execution in SMM.

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.

Acknowledgements

Binarly REsearch Team