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

__int64 __fastcall SwSmiHandler(__int64 a1, __int64 a2, _QWORD *Index, __int64 a4)
{
  __int64 v4; // rsi
  __int64 Status_1; // rdi
  EFI_STATUS Status; // rax
  _DWORD *Ptr; // rcx
  __int16 v8; // ax
  _WORD *ControllablePtr; // rbx
  __int64 v10; // rcx
  void (__fastcall **AmiNvramControlProtocol)(__int64); // rax
  __int64 v12; // rcx
  _DWORD *DellGnvsPtr; // [rsp+30h] [rbp-28h] BYREF
  UINTN DataSize; // [rsp+38h] [rbp-20h] BYREF
  EFI_GUID VendorGuid; // [rsp+40h] [rbp-18h] BYREF
  _WORD *Value; // [rsp+70h] [rbp+18h] BYREF

  v4 = 0;
  VendorGuid.Data1 = 0xA602C5B;
  DellGnvsPtr = 0;
  VendorGuid.Data2 = 0x5A0;
  VendorGuid.Data3 = 0x40C4;
  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;
  if ( !Index || !a4 || *Index == -1 )
    return 0;
  Status_1 = (gSmmCpu->ReadSaveState)(gSmmCpu, 4, EFI_SMM_SAVE_STATE_REGISTER_RBX, *Index, &Value);
  if ( gFromVariable == 1 )
  {
    DataSize = 4;
    Status = gRT_0->GetVariable(L"DELL_GNVS_PTR", &VendorGuid, 0, &DataSize, &DellGnvsPtr);
    Ptr = DellGnvsPtr;
    Status_1 = Status;
    if ( *DellGnvsPtr == 'TESQ' )
    {
      Value = DellGnvsPtr + 2;
      *DellGnvsPtr = 0;                         // unchecked write (SMRAM corruption)
      Ptr = DellGnvsPtr;
    }
    if ( *Ptr == 'DESQ' )
    {
      Value = Ptr + 2;
      *Ptr = 0;                                 // unchecked write (SMRAM corruption)
    }
  }
  v8 = gFuncTable[0];
  if ( gFuncTable[0] != 255 )
  {
    ControllablePtr = Value;
    v10 = 0;
    while ( v8 != *Value || *(&gFuncTable[1] + v10) != Value[1] )
    {
      ++v4;
      v10 = 12 * v4;
      v8 = gFuncTable[6 * v4];
      if ( v8 == 255 )
        return Status_1;
    }
    AmiNvramControlProtocol = gAmiNvramControlProtocol;
    if ( gAmiNvramControlProtocol
      || (AmiNvramControlProtocol = GetVendorTable(&AMI_NVRAM_CONTROL_PROTOCOL_GUID),
          (gAmiNvramControlProtocol = AmiNvramControlProtocol) != 0) )
    {
      LOBYTE(v10) = 1;
      (*AmiNvramControlProtocol)(v10);
      if ( gAmiNvramControlProtocol )
        (*(gAmiNvramControlProtocol + 8))(0);
      ControllablePtr = Value;
    }
    // multiple unchecked writes (SMRAM corruption) in functions from gFuncTable
    (*&gFuncTable[6 * v4 + 2])(ControllablePtr);
    if ( gAmiNvramControlProtocol )
    {
      (*gAmiNvramControlProtocol)(0);
      if ( gAmiNvramControlProtocol )
      {
        LOBYTE(v12) = 1;
        (*(gAmiNvramControlProtocol + 8))(v12);
      }
    }
  }
  return Status_1;
}

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_160C function from the gFuncTable:

_WORD *__fastcall sub_160C(__int64 ControllablePtr)
{
  _WORD *result; // rax

  result = *(ControllablePtr + 4);
  *result = 1;
  result[17] = 1;
  result[1] = 2;
  result[18] = 2;
  result[2] = 3;
  result[3] = 4;
  result[4] = 5;
  result[5] = 6;
  result[6] = 128;
  result[7] = 8;
  result[8] = 9;
  result[9] = 12;
  result[10] = 13;
  result[11] = 14;
  result[12] = 15;
  result[13] = 18;
  result[14] = 19;
  result[15] = 20;
  result[16] = 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

‍