Header bannerHeader banner

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

June 22, 2023

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-155
  • Dell PSIRT assigned CVE identifier: CVE-2023-28050
  • 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
Precision 7X50 0.1.19.0 Intel 9BCEDB6D-13CA-473E-B605-8A47688729FA 9bcedb6d-13ca-473e-b605-8a47688729fa 9c19c06003311c102b91353d1b88fe23c9d2bd89c57f80afcc82b5fab9c2eab6
Latitude 3120 0.1.13.1 AMD 9BCEDB6D-13CA-473E-B605-8A47688729FA 9bcedb6d-13ca-473e-b605-8a47688729fa adc756cd7143c8c1ec9e1f776aa1c7cee49da09f6e02b5bc609bc6969d977dcb

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 Precision 7X50's firmware (version: 0.1.19.0, module sha256: 9c19c06003311c102b91353d1b88fe23c9d2bd89c57f80afcc82b5fab9c2eab6) as an example.

The following code in the module actually allows leaking memory:

  • a call to a gRT->GetVariable() offset: 0xe2c
  • a call to a gRT->SetVariable() offset: 0xe71
// positive sp value has been detected, the output may be wrong!
__int64 __fastcall sub_D1F(__int64 a1, EFI_GUID *a2, EFI_GUID *VendorGuid, _QWORD *a4)
{
  __int64 v4; // rax
  __int64 v5; // rbp
  __int64 v6; // r9
  __int64 v7; // r8
  EFI_RUNTIME_SERVICES *v8; // rax
  __int64 v9; // r9
  __int64 v10; // r8
  EFI_RUNTIME_SERVICES *v11; // rax
  _DWORD v13[4]; // [rsp-BC8h] [rbp-BC8h] BYREF
  _DWORD v14[750]; // [rsp-BB8h] [rbp-BB8h] BYREF

  sub_11E8((__int64)&EFI_ODMEM_GNVS_AREA_PROTOCOL_GUID, (__int64)sub_554, (__int64)VendorGuid, a4, v4);
  v14[0] = -1332766721;
  v14[1] = 1100211944;
  v14[2] = -1637967959;
  v14[3] = 853215899;
  v13[0] = 1165015025;
  v13[1] = 1229172200;
  v13[2] = 1681965965;
  v13[3] = -2078047118;
  sub_1330((int *)(v5 + 752), 0, 0x7ECui64);
  *(_QWORD *)(v5 + 2840) = 845i64;
  ((void (__fastcall *)(const __int16 *, _DWORD *, __int64, __int64, __int64))gRT->GetVariable)(// <= first call (we can rewrite DataSize here)
    L"CpuSetup",
    v14,
    v5 + 2816,
    v5 + 2840,
    v5 - 96);
  v6 = *(_QWORD *)(v5 + 2840);
  v7 = *(unsigned int *)(v5 + 2816);
  v8 = gRT;
  *(_WORD *)(v5 + 125) = 256;
  ((void (__fastcall *)(const __int16 *, _DWORD *, __int64, __int64, __int64))v8->SetVariable)(// <= second call
    L"CpuSetup",
    v14,
    v7,
    v6,
    v5 - 96);
  *(_QWORD *)(v5 + 2840) = 2028i64;
  ((void (__fastcall *)(const __int16 *, _DWORD *, __int64, __int64, __int64))gRT->GetVariable)(// <= first call (we can rewrite DataSize here)
    L"PchSetup",
    v13,
    v5 + 2816,
    v5 + 2840,
    v5 + 752);
  v9 = *(_QWORD *)(v5 + 2840);
  v10 = *(unsigned int *)(v5 + 2816);
  v11 = gRT;
  *(_BYTE *)(v5 + 2471) = 0;
  *(_BYTE *)(v5 + 762) = 0;
  *(_BYTE *)(v5 + 2512) = 0;
  ((void (__fastcall *)(const __int16 *, _DWORD *, __int64, __int64, __int64))v11->SetVariable)(// <= second call
    L"PchSetup",
    v13,
    v10,
    v9,
    v5 + 752);
  return 0i64;
}

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

Tags
No items found.