Memory contents leak / information disclosure vulnerability in DXE driver on Dell platform.
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.
Image preview
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 exploitation 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.
Image preview
Vulnerability Information
- BINARLY internal vulnerability identifier: BRLY-2022-101
- Dell PSIRT assigned CVE identifier: CVE-2023-25937
- 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
Image preview
Affected Dell firmware
| Product | Firmware version | CPU | Module name | Module GUID | Module SHA256 |
|---|---|---|---|---|---|
Latitude 3300 | 0.1.17.0 | Intel | 899407D7-99FE-43D8-9A21-79EC328CAC21 | 899407d7-99fe-43d8-9a21-79ec328cac21 | 242a5ea5ff855aed77a41207d3f43546b13a32bb5ceab4e333e7b5f0958afb8a |
XPS 8940 | 0.2.4.0 | Intel | 899407D7-99FE-43D8-9A21-79EC328CAC21 | 899407d7-99fe-43d8-9a21-79ec328cac21 | 3194dcc56c37ac93cedb90571bfbc492f1b5e814bf887c59b3cd7e67087bf752 |
XPS 8940 | 0.2.4.0 | Intel | 899407D7-99FE-43D8-9A21-79EC328CAC21 | 899407d7-99fe-43d8-9a21-79ec328cac21 | 3194dcc56c37ac93cedb90571bfbc492f1b5e814bf887c59b3cd7e67087bf752 |
Insprion/Vostro 3X8X | 0.1.19.0 | Intel | 899407D7-99FE-43D8-9A21-79EC328CAC21 | 899407d7-99fe-43d8-9a21-79ec328cac21 | 366d49466dc5f81aca0846a6bfa64c08efa719349caca0b560787b72ea4fc3d7 |
Insprion/Vostro 3X8X | 0.1.19.0 | Intel | 899407D7-99FE-43D8-9A21-79EC328CAC21 | 899407d7-99fe-43d8-9a21-79ec328cac21 | 366d49466dc5f81aca0846a6bfa64c08efa719349caca0b560787b72ea4fc3d7 |
Precision 5520 | 0.1.30.0 | Intel | 899407D7-99FE-43D8-9A21-79EC328CAC21 | 899407d7-99fe-43d8-9a21-79ec328cac21 | 5811b4bdbf93b2b7fc95200f1f246827f5f366d07d16f06b863920d0b11bf388 |
Precision 5520 | 0.1.30.0 | Intel | 899407D7-99FE-43D8-9A21-79EC328CAC21 | 899407d7-99fe-43d8-9a21-79ec328cac21 | 5811b4bdbf93b2b7fc95200f1f246827f5f366d07d16f06b863920d0b11bf388 |
Precision 5820 Tower X-Series | 0.2.22.0 | Intel | Setup | 899407d7-99fe-43d8-9a21-79ec328cac21 | 7b19487c2b25cda388d8960ea34041513b3c7726e2a0a6010f9a08969ed58a38 |
Inspiron 14-3467 | 0.2.20.0 | Intel | 899407D7-99FE-43D8-9A21-79EC328CAC21 | 899407d7-99fe-43d8-9a21-79ec328cac21 | d692fb75c9ba1779498fa6dd6f9e9463e8a590fb97dc2166f4d41d944b068085 |
Inspiron 14-3467 | 0.2.20.0 | Intel | 899407D7-99FE-43D8-9A21-79EC328CAC21 | 899407d7-99fe-43d8-9a21-79ec328cac21 | d692fb75c9ba1779498fa6dd6f9e9463e8a590fb97dc2166f4d41d944b068085 |
OptiPlex 7050 | 0.1.22.1 | Intel | 899407D7-99FE-43D8-9A21-79EC328CAC21 | 899407d7-99fe-43d8-9a21-79ec328cac21 | d890373a028f4a868eff029342db3bd326dd23d9075c1c1101a41026ff6b8e07 |
Image preview
Vulnerability description
Let's take Latitude 3300's firmware (version: 0.1.17.0, module sha256: 242a5ea5ff855aed77a41207d3f43546b13a32bb5ceab4e333e7b5f0958afb8a) as an example.
The following code in the module actually allows leaking memory:
- a call to a
gRT->GetVariable()offset:0xe7cc - a call to a
gRT->SetVariable()offset:0xe9be
__int64 __fastcall sub_E790()
{
__int64 result; // rax
unsigned int v1; // eax
unsigned __int64 i; // rbx
unsigned int v3; // edx
unsigned int v4; // ecx
char v5; // dl
bool v6; // cl
int v7; // edi
int v8; // esi
unsigned __int64 v9; // rcx
__int64 v10[7]; // [rsp+30h] [rbp-38h] BYREF
int v11; // [rsp+70h] [rbp+8h] BYREF
unsigned int v12; // [rsp+78h] [rbp+10h] BYREF
unsigned int v13; // [rsp+80h] [rbp+18h] BYREF
__int64 v14; // [rsp+88h] [rbp+20h] BYREF
v10[0] = 5360i64;
gRT->GetVariable( // <= first call (we can rewrite DataSize here)
(CHAR16 *)L"CpuSetup",
&CPU_SETUP_VARIABLE_GUID,
(UINT32 *)&v14,
(UINTN *)v10,
&unk_2E570);
result = sub_21B94(3i64, -2147483624, (char *)&v13, &v11);
if ( !v11 )
{
v1 = v13;
for ( i = 0i64; i <= 3; ++i )
{
if ( i )
{
if ( i == 1 )
{
v3 = v1 >> 5;
v4 = v1 >> 9;
}
else if ( i == 2 )
{
v3 = v1 >> 15;
v4 = v1 >> 19;
}
else
{
v3 = v1 >> 20;
v4 = HIBYTE(v1);
}
}
else
{
LOBYTE(v3) = v1;
v4 = v1 >> 4;
}
v5 = v3 & 0xF;
v6 = (v4 & 1) == 0;
if ( *((_BYTE *)&unk_2E570 + i + 1438) == 1 && v6 )
{
v7 = v5 & 0xF;
v8 = v7 << 16;
sub_21B94(3i64, (v7 << 16) | 0x80000118, (char *)&v12, &v11);
if ( !v11 )
{
v9 = (100000 * ((unsigned __int64)v12 >> 16) + 0x80000) >> 20;
*((_WORD *)&unk_2E570 + i + 721) = (100000 * (unsigned __int64)(unsigned __int16)v12 + 0x80000) >> 20;
*((_WORD *)&unk_2E570 + i + 725) = v9;
}
sub_21B94(3i64, v8 | 0x80000518, (char *)&v12, &v11);
if ( !v11 )
*((_WORD *)&unk_2E570 + i + 753) = v12;
sub_21B94(3i64, v8 | 0x80000718, (char *)&v12, &v11);
if ( !v11 )
*((_WORD *)&unk_2E570 + i + 757) = (1000 * v12 + 4096) >> 13;
sub_21B94(3i64, (v7 << 8) | 0x80000019, (char *)&v12, &v11);
if ( !v11 )
*((_WORD *)&unk_2E570 + i + 761) = v12 & 0x7FFF;
v1 = v13;
}
}
return gRT->SetVariable( // <= second call
(CHAR16 *)L"CpuSetup",
&CPU_SETUP_VARIABLE_GUID,
v14,
v10[0],
&unk_2E570);
}
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 CpuSetup NVRAM variable is greater than 5360.
Thus, a potential attacker can dump X - 5360 bytes from the stack (or global memory) into CpuSetup NVRAM variable by setting CpuSetup NVRAM variable's size to X > 5360.
To fix this vulnerability the DataSize must be re-initialized with the size of CpuSetup before calling gRT->SetVariable().
Image preview
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 |
Image preview
Acknowledgements
Image preview
See if you are impacted now with our Firmware Vulnerability Scanner
Find Vulnerabilities, Generate SBOMs & CBOMs