[BRLY-2022-150] Memory contents leak / information disclosure vulnerability in DXE driver on Dell platform.

Summary

BINARLY efiXplorer team has discovered a memory contents leak / information disclosure vulnerability that allows a potential attacker to dump stack memory or global memory into an NVRAM variable. This in turn could help building a successful attack vector based on exploiting a memory corruption vulnerability.

Vulnerability Information

• BINARLY internal vulnerability identifier: BRLY-2022-150
• Dell PSIRT assigned CVE identifier: CVE-2023-28061
• DSA identifier: DSA-2023-099
• CVSS v3.1: 6.0 Medium AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:N/A:N

Affected Dell firmware with confirmed impact by Binarly team

Potential impact

An attacker with high local access can exploit this vulnerability to read the contents of stack memory or global memory. This information could help with explotation of other vulnerabilities in DXE to elevate privileges from ring 3 or ring 0 (depends on the operating system) to a DXE driver and execute arbitrary code. Malicious code installed as a result of this exploitation could survive operating system (OS) boot process and runtime, or modify NVRAM area on the SPI flash storage (to gain persistence). Additionally, threat actors could use this vulnerability to bypass OS security mechanisms (modify privileged memory or runtime variables), influence OS boot process, and in some cases allow an attacker to hook or modify EFI Runtime services.

Vulnerability description

Let's take 's firmware (version: 0.1.0.16, module sha256: 8c47ee9d5bc62dbeb24ed4dc210f488291dce972b6cfd801ac47ea281e0d9421) as an example.

The following code in the module actually allows leaking memory:

• a call to a gRT->GetVariable() offset: 0x2bb7
• a call to a gRT->SetVariable() offset: 0x2c0c

void __fastcall sub_2A5C(EFI_EVENT Event, void *Context)
{
  unsigned __int64 v2; // rbx
  int v3; // edi
  int v4; // esi
  __int64 v5; // rcx
  int v6; // r8d
  unsigned int v7; // ecx
  __int64 v8; // rax
  char v9; // cl
  int v10; // [rsp+30h] [rbp-20h] BYREF
  __int64 v11; // [rsp+38h] [rbp-18h] BYREF
  __int64 v12; // [rsp+40h] [rbp-10h] BYREF
  void (__fastcall **v13)(_QWORD, __int64, void *, __int64 *, __int64 *); // [rsp+48h] [rbp-8h] BYREF
  char v14; // [rsp+90h] [rbp+40h] BYREF
  __int64 v15; // [rsp+98h] [rbp+48h] BYREF

  v10 = 0;
  v2 = *(unsigned int *)(sub_2A2C() + 12);
  v3 = -1;
  v14 = 0;
  v4 = 0;
  v11 = 1i64;
  ((void (__fastcall *)(EFI_GUID *, _QWORD, void (__fastcall ***)(_QWORD, __int64, void *, __int64 *, __int64 *)))gBS->LocateProtocol)(
    &DELL_PROPERTY_DXE_PROTOCOL_GUID,
    0i64,
    &v13);
  v12 = 1i64;
  (*v13)(v13, 3610i64, &unk_4140, &v12, &v15);
  if ( !(_BYTE)v15 )
    goto LABEL_20;
  if ( (unsigned int)v2 <= 0x20 )
  {
    v5 = 0x100040010i64;
    if ( _bittest64(&v5, v2) )
      goto LABEL_20;
  }
  sub_3C58(v5, 293613704, v6, &v10);
  if ( MEMORY[0xE001A000] != -1 && (unsigned __int8)(MEMORY[0xE001A019] - 1) <= 0xFDu )
  {
    v7 = MEMORY[0xE001A019] << 20;
    v3 = *(_DWORD *)(v7 + 0xE0000000i64);
    if ( v3 != -1 )
      v4 = *(_DWORD *)(v7 + 48 + 0xE0000000i64);
  }
  if ( (v10 & 0xF) != 1 && MEMORY[0xE001A000] != -1 && v3 != -1 && v4 )
  {
    v14 = 0;
    ((void (__fastcall *)(const __int16 *, EFI_GUID *, __int64, __int64, char *))gRT->SetVariable)(
      L"RebootCounter10GLom",
      &VendorGuid,
      7i64,
      v11,
      &v14);
    goto LABEL_20;
  }
  v8 = ((__int64 (__fastcall *)(const __int16 *, EFI_GUID *, _QWORD, __int64 *, char *))gRT->GetVariable)(// <= first call (we can rewrite DataSize here)
         L"RebootCounter10GLom",
         &VendorGuid,
         0i64,
         &v11,
         &v14);
  if ( v8 >= 0 )
  {
    v9 = v14;
  }
  else
  {
    v9 = v14;
    if ( v8 == 0x800000000000000Eui64 )
      v9 = 0;
  }
  if ( (unsigned __int8)v9 >= 5u )
LABEL_20:
    JUMPOUT(0x2C24i64);
  sub_2BE9(v9 + 1);
}

The gRT->SetVariable() service is called with the DataSize as an argument, which will be overwritten inside the gRT->GetVariable() service if the length of RebootCounter10GLom NVRAM variable is greater than 1.

Thus, a potential attacker can dump X - 1 bytes from the stack (or global memory) into RebootCounter10GLom NVRAM variable by setting RebootCounter10GLom NVRAM variable's size to X > 1.

To fix this vulnerability the DataSize must be re-initialized with the size of RebootCounter10GLom before calling gRT->SetVariable().

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 efiXplorer team