[BRLY-DVA-2024-022] SMM memory corruption vulnerability in SMM module on Dell device (SMRAM write).

This vulnerability was detected by the Deep Vulnerability Analysis (DVA) component from Binarly Platform

Vulnerability Information

• BINARLY internal vulnerability identifier: BRLY-DVA-2024-022
• Dell PSIRT assigned CVE identifier: CVE-2024-32858/CVE-2024-32859
• DSA identifier: DSA-2024-124
• CVSS v3.1: 8.2 High AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H

Affected Dell firmware with confirmed impact by BINARLY team

For supported affected platforms, Dell has addressed this vulnerability in DSA-2024-124. All other affected platforms have been determined to be End of Support Life.

Vulnerability description

Let's consider the vulnerability on the example of a module with SHA256 e5cdd6bb5ecbb12c7a591bb252e8edeb27c16dc4825f8f4ebbf498e6878e437d. The pseudocode of the vulnerable function is presented below:

EFI_STATUS __fastcall SwSmiHandler(
        EFI_HANDLE DispatchHandle,
        const void *Context,
        UINTN *CommBuffer,
        UINTN *CommBufferSize)
{
  UINTN Index; // r9
  __int64 v5; // rbx
  unsigned __int64 ControllablePtr; // rdi
  _DWORD *Ptr; // r11
  __int16 v8; // ax
  __int64 v9; // rcx
  EFI_GUID VendorGuid; // [rsp+30h] [rbp-228h] BYREF
  UINTN DataSize; // [rsp+40h] [rbp-218h] BYREF
  int RbxValue[11]; // [rsp+22Ch] [rbp-2Ch] BYREF
  _DWORD *DellGnvsPtr; // [rsp+270h] [rbp+18h] BYREF

  Index = *CommBuffer;
  v5 = 0;
  VendorGuid.Data2 = 0x5A0;
  VendorGuid.Data3 = 0x40C4;
  DellGnvsPtr = 0;
  VendorGuid.Data1 = 0xA602C5B;
  VendorGuid.Data4[0] = 0x91;
  VendorGuid.Data4[1] = 0x81;
  VendorGuid.Data4[2] = 0xED;
  VendorGuid.Data4[3] = 0xCD;
  VendorGuid.Data4[4] = 0x89;
  VendorGuid.Data4[5] = 0x1D;
  VendorGuid.Data4[6] = 0;
  VendorGuid.Data4[7] = 3;
  gEfiSmmCpuProtocol->ReadSaveState(gEfiSmmCpuProtocol, 4, EFI_SMM_SAVE_STATE_REGISTER_RBX, Index, RbxValue);
  ControllablePtr = RbxValue[0];
  DataSize = 4;
  gRT_0->GetVariable(L"DELL_GNVS_PTR", &VendorGuid, 0, &DataSize, &DellGnvsPtr);
  Ptr = DellGnvsPtr;
  if ( *DellGnvsPtr == 'TESQ' )
  {
    ControllablePtr = (DellGnvsPtr + 2);
    *DellGnvsPtr = 0;                           // unchecked write (SMRAM corruption)
    Ptr = DellGnvsPtr;
  }
  if ( *Ptr == 'DESQ' )
  {
    ControllablePtr = (Ptr + 2);
    *Ptr = 0;                                   // unchecked write (SMRAM corruption)
  }
  v8 = gFuncTable[0];
  if ( gFuncTable[0] != 255 )
  {
    v9 = 0;
    while ( v8 != *ControllablePtr || gFuncTable[v9 + 1] != *(ControllablePtr + 2) )
    {
      ++v5;
      v9 = 6 * v5;
      v8 = gFuncTable[6 * v5];
      if ( v8 == 255 )
        return 0;
    }
    // multiple unchecked writes (SMRAM corruption) in functions from gFuncTable
    (*&gFuncTable[6 * v5 + 2])(ControllablePtr);
  }
  return 0;
}

The GetVariable call initializes DellGnvsPtr with the value stored in the DELL_GNVS_PTR NVRAM variable. Since the DELL_GNVS_PTR NVRAM variable is controlled by an attacker, they can perform an arbitrary write operation here:

*DellGnvsPtr = 0;                           // unchecked write (SMRAM corruption)
...
*Ptr = 0;                                   // unchecked write (SMRAM corruption)

It must be noted that these write can be reached only if DellGnvsPtr points to the signatures DESQ or TESQ, thus limiting the memory locations that can be corrupted by an attacker. However, an attacker can overwrite these signatures during the first run of the SMI handler (by pointing to the code with signatures), then obtain a more powerful write primitive in one of the functions from the gFuncTable. For example in the sub_7268 function from the gFuncTable:

__int64 __fastcall sub_7268(_DWORD *ControllablePtr)
{
  __int64 result; // rax

  result = 0;
  ControllablePtr[6] = 0;
  ControllablePtr[7] = 0;
  ControllablePtr[5] = 0;
  return result;
}

In order to fix this vulnerability, all user-controllable offsets and pointers should be checked with SmmIsBufferOutsideSmmValid() or analogues before any write attempt.

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

‍