[BRLY-DVA-2024-023] 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-023
• 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 c20688cba3c5e6b56cd374285e6c0a1dd07cc614e48b005ec6582a3c28cafa7f. The pseudocode of the vulnerable function is presented below:

__int64 __fastcall SwSmiHandler(
        EFI_HANDLE DispatchHandle,
        const void *Context,
        UINTN *CommBuffer,
        UINTN *CommBufferSize)
{
  UINTN Index; // r9
  __int64 v5; // rbx
  _DWORD *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
  unsigned int RbxValue; // [rsp+22Ch] [rbp-2Ch] BYREF
  _DWORD *DellGnvsPtr; // [rsp+270h] [rbp+18h] BYREF

  Index = *CommBuffer;
  v5 = 0;
  VendorGuid.Data2 = 0x5A0;
  VendorGuid.Data3 = 0x40C4;
  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;
  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;
  if ( *gFuncTable != 255 )
  {
    v9 = 0;
    while ( v8 != *ControllablePtr || *&gFuncTable[v9 + 2] != *(ControllablePtr + 1) )
    {
      ++v5;
      v9 = 12 * v5;
      v8 = *&gFuncTable[12 * v5];
      if ( v8 == 255 )
        return 0;
    }
    // multiple unchecked writes (SMRAM corruption) in functions from gFuncTable
    (*&gFuncTable[12 * v5 + 4])(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 first function from the gFuncTable:

char __fastcall sub_6A9C(__int64 Ptr)
{
  // [COLLAPSED LOCAL DECLARATIONS. PRESS NUMPAD "+" TO EXPAND]

  v2 = *(Ptr + 4);
  v3 = *(Ptr + 2) == 1;
  DataSize = 3072;
  v4 = 14;
  if ( v3 )
    v4 = 0;
  if ( *(Ptr + 2) == 2 )
    v4 = 0;
  if ( v2 < v4 )
  {
    // ...
    // SMRAM write
    *(Ptr + 24) = v10 >> v8;
    *(Ptr + 28) = *(&off_D50 + v6 + 24);
    LODWORD(v5) = *(&off_D50 + v6 + 28);
    *(Ptr + 20) = 0;
    *(Ptr + 32) = v5;
  }
  else
  {
    LOBYTE(v5) = sub_5DC8(Ptr);
    if ( !v5 )
LABEL_7:
      *(Ptr + 20) = -1; // SMRAM write
  }
  return v5;
}

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

‍