[BRLY-2022-010] SMM memory corruption vulnerability in SMM driver on HP device (SMRAM write

Summary

Binarly REsearch Team has discovered an SMM memory corruption vulnerability in an HP device 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-2022-010
• CERT/CC assigned case number: VU#917518
• HP PSIRT assigned CVE identifier: CVE-2022-23930
• 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 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 SMM driver registers a child software System Management Interrupt (SW SMI) handler with GUID 4dd19464-68d5-4c6d-9a6f-a6049afed855, which contains the actual vulnerability:

Status = gSmst->SmiHandlerRegister(SmiHandler, &SmiHandlerGuid, &gSmiHandlerDispatchHandle);

The SMI handler itself is located at offset 0x1A14 in the driver:

EFI_STATUS __fastcall SmiHandler(EFI_HANDLE DispatchHandle, const void *Context, void *CommBuffer, UINTN *CommBufferSize)
{
  ...
  
  // CommBuffer size not validated
  ptr = SmmAllocateWrite(*CommBufferSize, CommBuffer);
  
  if ( ptr )
  {
      ...
      
      nested_ptr = (void *)*((_QWORD *)ptr + 5);
      ptr_plus40_ptr = (char *)ptr + 0x40;
      
      if ( nested_ptr )
        // Data pointer calculation
        dest = (char *)ptr + *((_QWORD *)ptr + 6) + 0x40;
        
      ptr_plus18_ptr = (char *)ptr + 0x18;
      
      if ( *(_BYTE *)ptr )
	      // Read variable
        v15 = sub_800016FC(                     
                (__int64)&v22,
                ptr_plus40_ptr, // Name
                ptr_plus18_ptr, // Guid
                (char *)ptr + 0x38,
                (size_t *)ptr + 5, // Size
                dest); // Data
      else
	      // Write variable
        v15 = sub_800018A8(
                (__int64)&v22,
				        ptr_plus40_ptr, // Name
				        ptr_plus18_ptr, // Guid
				        *((_DWORD *)ptr + 0xE),
				        nested_ptr, // Size
				        dest); // Data
				        
    ...

As we can see the Communication Buffer contents is copied into a buffer allocated in SMRAM via SmmAllocateWrite(). However the size of a copied contents (=size of Communication Buffer) is not checked to be an expected value, which allows a possible attacker to partially bypass the validation provided by PiSmmCommunicationSmm module for example by specifying the CommBuffer = SMRAM_BASE - 1 and *CommBufferSize = 1 byte. This in turn will lead to nested_ptr, ptr_plus40_ptr, ptr_plus18_ptr, ptr + 0x38, (size_t *)ptr + 5 and dest will be pointing inside SMRAM.

These values (which are actually Name, Guid, Size, Data and others) are passed into routines for further processing:- reading EFI variable sub_800016FC() or- writing into EFI variable sub_800018A8().

The last argument for these routines dest is calculated in a way, that allows to build an address in SMRAM in a relatively accurate way:

// Data pointer calculation
dest = (char *)ptr + *((_QWORD *)ptr + 6) + 0x40;

The QWORD value in *((_QWORD *)ptr + 6) is controllable by an SMI caller and could be used as a 64-bit offset to add to a (char *)ptr + 0x40.

In case the execution flow goes into routine sub_800016FC(), the following code will be executed:

unsigned __fastcall sub_800016FC(__int64 a1, void *ptr_plus40_ptr, void *ptr_plus18_ptr, void *ptr_plus38_ptr, size_t *size_ptr, void *dest)
{
  ...
  
  Status = GetVar(ptr_plus40_ptr, ptr_plus18_ptr, &Buffer, (UINTN *)v15);
  
  ...
  
    memcpy(dest, Buffer, BufferSize);
  
  ...
}

This leads to corrupting memory in SMRAM at a controllable address with a predictable data and size. It could be used for example to change SMI handler's code or modify SMRAM Map structures to break input pointers validation for other SMI handlers, hence to completely make this mitigation inefficient. This could lead to gaining arbitrary code execution in SMM.

The other routine in the SMI handler sub_800018A8() could be used by a possible attacker to achieve the opposite - read SMRAM contents (memory leak).

To exploit this vulnerability it is enough to specify in a CommBuffer:1. Valid EFI variable Name, Guid and Size.2. First byte should be not zero to enter sub_800018A8().3. Call SW SMI (SwSmi number is specified in the UEFI ACPI table) via 0xB2 IO port, prior to it SMI handler GUID 4dd19464-68d5-4c6d-9a6f-a6049afed855 and Communication Buffer size should be specified in Communication Buffer.

It should be noted that this SMI handler will be unregistered in a callback-notifier for SMM protocol 296eb418-c4c8-4e05-ab59-39e8af56f00a:

Status = gSmst->SmmRegisterProtocolNotify(&gUnknownProtocol296EB418Guid, UnknownProtocol296EB418Notifier, &Registration);

EFI_STATUS __fastcall UnknownSmmProtocol2Notifier(const EFI_GUID *Protocol, void *Interface, EFI_HANDLE Handle)
{
  if ( gSmiHandlerDispatchHandle )
  {
    gSmst->SmiHandlerUnRegister(gSmiHandlerDispatchHandle);
    gSmiHandlerDispatchHandle = 0;
  }
  return 0;
}

Due to this fact the vulnerability cannot be exploited from an operating system. However, there is a time window before the above mentioned event will occur and the handler will be unregistered. A possible attacker capable of executing code in DXE phase could exploit this vulnerability to escalate privileges to SMM (ring -2).

To fix this vulnerability, it is essential to wrap all the input pointers (including the nested pointers) of the SMI handlers with sanity checks to make sure they are not pointing into SMRAM.

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