[BRLY-2022-018] SMM memory leak vulnerability in SMM driver (SMRAM read).

Summary

Binarly REsearch Team identified an SMM memory leak vulnerability, which allows an attacker to read portions of SMRAM memory. This in turn could help building a successful attack vector exploiting SMM memory corruption vulnerability.

Vulnerability Information

• BINARLY internal vulnerability identifier: BRLY-2022-018
• Insyde PSIRT assigned CVE identifier: CVE-2022-35894
• FwHunt rule: BRLY-2022-018
• CVSS v3.1 6.0 Medium CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:N/A:N

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 evironment 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 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 vulnerable module registers a child SW SMI handler with GUID 2970687c-618c-4de5-b8f9-6c7576dca83d:

gSmst->SmiHandlerRegister)(SmiHandler, &UNKNOWN_PROTOCOL_2970687C_GUID, &Handle);

Also, it installs protocol with the same GUID 2970687c-618c-4de5-b8f9-6c7576dca83d:

Buffer = (char *)AllocPoolWrapper((EFI_MEMORY_TYPE)(gSmramMap != 0i64 ? 6 : 4), 0x58ui64);
gSmfbFuncArray = Buffer;
if ( !Buffer )
  return EFI_OUT_OF_RESOURCES;

ZeroMemory(Buffer, 0x58ui64);
SmfbFuncArray = (_QWORD *)gSmfbFuncArray;

*(_DWORD *)gSmfbFuncArray = 'bfms';
byte_80006B30 = 0;
SmfbFuncArray[9] = &byte_80006B30;
SmfbFuncArray[2] = SmfbFunc0;
SmfbFuncArray[3] = SmfbFunc1;
SmfbFuncArray[4] = SmfbFunc2;
SmfbFuncArray[5] = SmfbFunc3;
SmfbFuncArray[6] = SmfbFunc4;
SmfbFuncArray[7] = SmfbFunc5;
SmfbFuncArray[8] = SmfbFunc6;

Handle = 0;
gSmst->SmmInstallProtocolInterface)(&Handle, &UNKNOWN_PROTOCOL_2970687C_GUID, 0);

The handler is located at offset 0x19D0:

EFI_STATUS __fastcall SmiHandler(EFI_HANDLE DispatchHandle, const void *Context, void *CommBuffer, UINTN *CommBufferSize)
{
  if ( CommBuffer && CommBufferSize && !gExitBootServicesFlag2EfiEventLegacyBootFlag )
  {

    ...

    v6 = (char *) gUnknownProtocol74d936fa;

    ...

    if ( *CommBufferSize == qword_80006B20 - 24 && CommBuffer == v6 + 0x18 )
    {
      switch ( *(_QWORD *)CommBuffer )
      {
        case 2:
          if ( *((_QWORD *)CommBuffer + 3) <= 0x1000 )
          {
            v7 = SmfbFunc1(
                   0,
                   *((_QWORD *)CommBuffer + 2),
                   0,
                   (_QWORD *)CommBuffer + 3,
                   (__int64)(CommBuffer + 0x20));
            goto LABEL_17;
          }
          break;

As we can see before EFI_EVENT_EXIT_BOOT_SERVICES is triggered, if a caller specifies*(_QWORD *)CommBuffer = 2 routine SmfbFunc1() will be invoked (located at offset 0x1E54) with controllable arguments:- addr (retrieved *((_QWORD *)CommBuffer + 2)) - main pointer for the operation- size (located at (_QWORD *)CommBuffer + 3) - size of data for the operation- dest (the rest of Communication Buffer located at (__int64)(CommBuffer + 0x20)) - destination buffer address for the operation (if applicable)

__int64 __fastcall SmfbFunc1(__int64 a1, __int64 addr, __int64 offset, _QWORD *size_ptr, __int64 dest)
{
  src = (const void *)(offset + addr);
  size = *size_ptr;

  if ( *(_DWORD *)gValueInitializedByUnknownProtocol1c2e4602 == 3 )
    return sub_800031CC(size, dest, src);  // SMM memory read from a controllable address
  if ( *(_DWORD *)gValueInitializedByUnknownProtocol1c2e4602 > 1u )
    return EFI_UNSUPPORTED;

  v7 = 0;
  if ( size && (const void *)dest != src )
    memcpy((void *)dest, src, *size_ptr);  // SMM memory read from a controllable address

  return v7;
}

Because no validation is applied for the addr argument, a possible attacker can make it to point into SMRAM contents. Then memcpy() or sub_800031CC() will lead to copying memory from addr to dest. Hence, this primitive could be used by an attacker for dumping SMRAM contents which in turn helps building attack vectors on exploiting SMM memory corruption vulnerabilities in case an attacker needs to know some information about addresses.

Despite the vulnerability cannot be exploited from the operating system an attacker capable of executing code in DXE phase could exploit this vulnerability to escalate privileges to SMM (ring -2).

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