[BRLY-DVA-2023-025] SMM memory corruption vulnerability in combined DXE/SMM driver on Fujitsu device (SMRAM write)

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

Let's consider the vulnerability on the example of a module with SHA256 c93e4b4e5962d689a0e8c075f2ee5c21e6f3ae1a7438f65645ed16cac12d26c3. The pseudocode of the vulnerable ChildSwSmiHandler function (with the HandlerType: EFI_ATA_PASS_THRU_PROTOCOL_GUID) is presented below:

EFI_STATUS __fastcall ChildSwSmiHandler(
        EFI_HANDLE DispatchHandle,
        const void *Context,
        _QWORD *CommBuffer,
        UINTN *CommBufferSize)
{
  __int64 v4; // r13
  __int64 NestedPtr; // rsi
  __int64 Status; // rbx
  __int64 Ptr; // rdi
  bool Res; // al
  UINTN v10; // rdi
  unsigned __int8 v11; // r12
  __int64 v12; // rax
  EFI_STORAGE_SECURITY_SEND_DATA *p_SendData; // r14
  __int64 i; // rax
  __int64 v15; // rbx
  EFI_STORAGE_SECURITY_COMMAND_PROTOCOL *EfiStorageSecurityCommandProtocol; // [rsp+30h] [rbp-10h] BYREF
  void *Buffer; // [rsp+90h] [rbp+50h] BYREF
  UINTN BufferSize; // [rsp+98h] [rbp+58h] BYREF

  BufferSize = 0;
  v4 = 0;
  Buffer = 0;
  if ( gUnknownProtocol == CommBuffer && *CommBufferSize == 31 && CommBuffer )
  {
    NestedPtr = CommBuffer[2];
    gGlobalPtr1 = *(NestedPtr - 16);
    gGlobalPtr2 = *(NestedPtr - 8);
    if ( *CommBuffer == 1 )
    {
      Status = Command1(*(NestedPtr + 16), 1, NestedPtr);
      goto _Exit;
    }
    if ( *CommBuffer != 2 )
    {
      if ( *CommBuffer == 3 )
      {
        Ptr = Deref1(NestedPtr);
        Res = Compare(NestedPtr, Ptr);
        Status = Buffer;
        while ( !Res )
        {
          if ( *(Ptr + 16) )
          {
            Status = gSmst_0->SmmUninstallProtocolInterface(
                       *(Ptr - 136),
                       &EFI_STORAGE_SECURITY_COMMAND_PROTOCOL_GUID,
                       (Ptr - 88));
            if ( Status >= 0 )
            {
              Status = gSmst_0->SmmUninstallProtocolInterface(*(Ptr - 136), &EFI_DEVICE_PATH_PROTOCOL_GUID, *(Ptr - 56));
              if ( Status >= 0 )
                *(Ptr + 16) = 0; // unchecked write (SMRAM corruption)
            }
          }
          Ptr = Deref2(NestedPtr, Ptr);
          Res = Compare(NestedPtr, Ptr);
        }
      }
      else
      {
        Status = EFI_UNSUPPORTED;
      }
      goto _Exit;
    }
    ...
_Exit:
    CommBuffer[1] = Status;
  }
  return EFI_SUCCESS;
}

The pseudocode for the Deref1 function is shown below:

__int64 __fastcall Deref1(__int64 Address)
{
  return *Address;
}

As we can see from the pseudocode above, command 3 branch (if ( *CommBuffer == 3 )) contains an unchecked write operation to a nested pointer derived from the CommBuffer structure, which is specified by a user. So that the user can write fixed value 0x00 to a controllable address in SMRAM, which could lead to arbitrary code execution and privileges escalation to SMM.

In order to fix this vulnerability, it is necessary to check all nested pointers for overlapping with SMRAM before attempting to write to buffer pointed by it.

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.