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-119
• Dell PSIRT assigned CVE identifier: CVE-2023-25938
• DSA identifier: DSA-2023-099/DSA-2023-204
• CVSS v3.1: 4.9 Medium AV:P/AC:L/PR:H/UI:N/S:C/C:H/I:N/A:N

Affected Dell firmware with confirmed impact by Binarly team

Product	Firmware version	CPU	Module name	Module GUID	Module SHA256
XPS 17 9710, Precision 5760	0.1.14.0	Intel	PlatformInitDxe	ca84408a-0929-4f11-bfed-18c7d9576c6b	4b32444ad888c2597de681707449065e75e4b620aa50c2f2e875eca97b875d73

Potential impact

An attacker with high physical 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 XPS 17 9710, Precision 5760's firmware (version: 0.1.14.0, module sha256: 4b32444ad888c2597de681707449065e75e4b620aa50c2f2e875eca97b875d73) as an example.

The following code in the module actually allows leaking memory:

• a call to a gRT->GetVariable() offset: 0x103d
• a call to a gRT->SetVariable() offset: 0x1074

__int64 __fastcall sub_E74()
{
  char v0; // bl
  __int64 result; // rax
  unsigned __int8 v2; // al
  __int64 (__fastcall **v3)(__int64); // rax
  bool v4; // zf
  int v5; // eax
  UINTN v6; // [rsp+30h] [rbp-D0h] BYREF
  UINTN DataSize; // [rsp+38h] [rbp-C8h] BYREF
  char Data[91]; // [rsp+40h] [rbp-C0h] BYREF
  int v9; // [rsp+9Bh] [rbp-65h]
  int v10; // [rsp+9Fh] [rbp-61h]
  int v11; // [rsp+A9h] [rbp-57h]
  char v12[2048]; // [rsp+2D0h] [rbp+1D0h] BYREF
  UINT32 Attributes; // [rsp+AE0h] [rbp+9E0h] BYREF
  UINT32 v14; // [rsp+AE8h] [rbp+9E8h] BYREF
  void *Interface; // [rsp+AF0h] [rbp+9F0h] BYREF
  void *v16; // [rsp+AF8h] [rbp+9F8h] BYREF

  Interface = 0i64;
  v16 = 0i64;
  v0 = 0;
  result = gBS->LocateProtocol(&PLATFORM_NVS_AREA_PROTOCOL_GUID, 0i64, &Interface);
  if ( result >= 0 )
  {
    if ( (gBS->LocateProtocol(&UNKNOWN_PROTOCOL_GUID_0, 0i64, &v16) & 0x8000000000000000ui64) == 0i64 )
    {
      while ( 1 )
      {
        (*((void (__fastcall **)(void *, __int64, __int64))v16 + 3))(v16, 166i64, 1i64);
        __outbyte(0x910u, 0x11u);
        v2 = __inbyte(0x911u);
        if ( ((v2 + 1) & 0xFE) != 0 )
          break;
        if ( (unsigned __int8)++v0 >= 3u )
          goto LABEL_7;
      }
      switch ( v2 )
      {
        case 1u:
LABEL_7:
          *(_BYTE *)(*(_QWORD *)Interface + 2079i64) = 0;
          break;
        case 2u:
          *(_BYTE *)(*(_QWORD *)Interface + 2079i64) = 1;
          break;
        case 4u:
          *(_BYTE *)(*(_QWORD *)Interface + 2079i64) = 2;
          break;
        case 8u:
          *(_BYTE *)(*(_QWORD *)Interface + 2079i64) = 3;
          break;
      }
    }
    DataSize = 654i64;
    result = gRT->GetVariable((CHAR16 *)L"CpuSetup", &CPU_SETUP_VARIABLE_GUID, &Attributes, &DataSize, Data);
    if ( result >= 0 )
    {
      v3 = (__int64 (__fastcall **)(__int64))sub_1824();
      v4 = (v3[1](306i64) & 1) == 0;
      v5 = 100000;
      if ( v4 )
        v5 = 109000;
      v11 = v5;
      v10 = v5;
      v9 = v5;
      gRT->SetVariable((CHAR16 *)L"CpuSetup", &CPU_SETUP_VARIABLE_GUID, Attributes, 0x28Eui64, Data);
      v6 = 2028i64;
      gRT->GetVariable(                         // <= first call (we can rewrite DataSize here)
        (CHAR16 *)L"PchSetup",
        &PCH_SETUP_VARIABLE_GUID,
        &v14,
        &v6,
        v12);
      v12[1712] = 0;
      return gRT->SetVariable(                  // <= second call
               (CHAR16 *)L"PchSetup",
               &PCH_SETUP_VARIABLE_GUID,
               v14,
               v6,
               v12);
    }
  }
  return result;
}

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 PchSetup NVRAM variable is greater than 2028.

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

To fix this vulnerability the DataSize must be re-initialized with the size of PchSetup 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.

Disclosure Activity	Date (YYYY-mm-dd)
Dell PSIRT is notified	2022-12-29
Dell PSIRT confirmed reported issue	2023-03-16
Dell PSIRT assigned CVE number	2023-06-15
Dell PSIRT provide patch release	2023-06-15
BINARLY public disclosure date	2023-06-21

Acknowledgements

BINARLY efiXplorer team