[BRLY-2022-100] 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-100
- Dell PSIRT assigned CVE identifier: CVE-2023-28039
- 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
Product | Firmware version | CPU | Module name | Module GUID | Module SHA256 |
---|---|---|---|---|---|
Latitude 9420, Latitude 9420 | 0.1.16.2 | Intel | DynamicUpdatePDTDxe | 440bd554-fa04-4b26-b099-188a3e724b20 | 22c8db2e39fa0ad26f38e77f32a2e86d16e50465654ffeb9a0124006d1584fc2 |
Latitude 9420, Latitude 9420 | 0.1.16.2 | Intel | DynamicUpdatePDTDxe | 440bd554-fa04-4b26-b099-188a3e724b20 | 22c8db2e39fa0ad26f38e77f32a2e86d16e50465654ffeb9a0124006d1584fc2 |
Latitude 9510 | 0.1.16.0 | Intel | 440BD554-FA04-4B26-B099-188A3E724B20 | 440bd554-fa04-4b26-b099-188a3e724b20 | 4e00ff7aab780ea693ced1222a18f13139f9b4b30f3bbfb9e522d3248d5bd017 |
Latitude 9510 | 0.1.16.0 | Intel | 440BD554-FA04-4B26-B099-188A3E724B20 | 440bd554-fa04-4b26-b099-188a3e724b20 | 4e00ff7aab780ea693ced1222a18f13139f9b4b30f3bbfb9e522d3248d5bd017 |
Precision 5470 | 0.1.8.0 | Intel | DynamicUpdatePDTDxe | 440bd554-fa04-4b26-b099-188a3e724b20 | 4fec0aa417a431da9d8f609278b8e94bc7e3ffafb61cf415ffe898ec429ae252 |
Precision 5470 | 0.1.8.0 | Intel | DynamicUpdatePDTDxe | 440bd554-fa04-4b26-b099-188a3e724b20 | 4fec0aa417a431da9d8f609278b8e94bc7e3ffafb61cf415ffe898ec429ae252 |
Precision 5470 | 0.1.8.0 | Intel | DynamicUpdatePDTDxe | 440bd554-fa04-4b26-b099-188a3e724b20 | 4fec0aa417a431da9d8f609278b8e94bc7e3ffafb61cf415ffe898ec429ae252 |
Precision 7X50 | 0.1.19.0 | Intel | 440BD554-FA04-4B26-B099-188A3E724B20 | 440bd554-fa04-4b26-b099-188a3e724b20 | a7db870ba9f51b1e9cfeac2fab02511bd4aa70f025c522ad3f82c3aa4173f6b0 |
Latitude 9410 | 0.1.18.0 | Intel | 440BD554-FA04-4B26-B099-188A3E724B20 | 440bd554-fa04-4b26-b099-188a3e724b20 | f667101460ff0497cd4520d58b7d65177feb14833bf66939e2eb5ce08e645c1c |
Latitude 9410 | 0.1.18.0 | Intel | 440BD554-FA04-4B26-B099-188A3E724B20 | 440bd554-fa04-4b26-b099-188a3e724b20 | f667101460ff0497cd4520d58b7d65177feb14833bf66939e2eb5ce08e645c1c |
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 Latitude 9420, Latitude 9420's firmware (version: 0.1.16.2, module sha256: 22c8db2e39fa0ad26f38e77f32a2e86d16e50465654ffeb9a0124006d1584fc2) as an example.
The following code in the module actually allows leaking memory:
- a call to a
gRT->GetVariable()
offset:0x61f
- a call to a
gRT->SetVariable()
offset:0x754
void __fastcall NotifyFunction(EFI_CAPSULE_HEADER **Event, void *Context)
{
unsigned __int64 i; // rdi
__int64 v4; // r8
__int64 v5; // r8
__int64 v6; // rax
unsigned __int64 v7; // [rsp+40h] [rbp-9h] BYREF
__int64 v8; // [rsp+48h] [rbp-1h] BYREF
__int64 v9; // [rsp+50h] [rbp+7h] BYREF
__int64 v10; // [rsp+58h] [rbp+Fh] BYREF
__int64 v11; // [rsp+60h] [rbp+17h] BYREF
__int64 v12; // [rsp+68h] [rbp+1Fh] BYREF
char *v13; // [rsp+70h] [rbp+27h] BYREF
_BYTE v14[16]; // [rsp+78h] [rbp+2Fh] BYREF
__int64 v15[3]; // [rsp+88h] [rbp+3Fh] BYREF
unsigned __int16 v16; // [rsp+C0h] [rbp+77h] BYREF
int v17; // [rsp+C8h] [rbp+7Fh] BYREF
v12 = 0i64;
v8 = 0i64;
v9 = 0i64;
v10 = 0i64;
v11 = 0i64;
v17 = 0;
if ( ((__int64 (__fastcall *)(__int64, EFI_GUID *, _QWORD, unsigned __int64 *, __int64 *))gBS->LocateHandleBuffer)(
2i64,
&EFI_FIRMWARE_VOLUME2_PROTOCOL_GUID,
0i64,
&v7,
v15) >= 0
&& v7 )
{
v9 = 15i64;
((void (__fastcall *)(const __int16 *, EFI_GUID *, _QWORD, __int64 *, _BYTE *))gRT->GetVariable)(// <= first call (we can rewrite DataSize here)
L"MPDTContent",
&NameGuid,
0i64,
&v9,
v14);
for ( i = 0i64; i < v7; ++i )
{
if ( ((__int64 (__fastcall *)(_QWORD, EFI_GUID *, __int64 *))gBS->HandleProtocol)(
*(_QWORD *)(v15[0] + 8 * i),
&EFI_FIRMWARE_VOLUME2_PROTOCOL_GUID,
&v11) < 0 )
goto LABEL_18;
LOBYTE(v4) = 25;
if ( (*(__int64 (__fastcall **)(__int64, EFI_GUID *, __int64, _QWORD, __int64 *, __int64 *, int *))(v11 + 24))(
v11,
&NameGuid,
v4,
0i64,
&v12,
&v8,
&v17) >= 0 )
{
((void (__fastcall *)(__int64, __int64, __int64 *))gBS->AllocatePool)(4i64, v8, &v10);
v10 = v12;
v13 = 0i64;
v16 = 0;
if ( v12 )
{
v6 = sub_C58(v14[1], v12, v8, &v16, (unsigned int **)&v13, v12);
if ( v6 >= 0 )
{
if ( v13 )
v6 = sub_EF8(v13, v16);
else
v6 = 0x8000000000000002ui64;
}
v5 = v6;
if ( v6 >= 0 )
continue;
}
else
{
v5 = 0x8000000000000015ui64;
}
sub_4E0((__int64)v14, 129, v5);
}
}
((void (__fastcall *)(const __int16 *, EFI_GUID *, __int64, __int64, _BYTE *))gRT->SetVariable)(
L"MPDTContent",
&NameGuid,
7i64,
v9,
v14);
if ( i >= v7 )
((void (__fastcall *)(EFI_CAPSULE_HEADER **))gBS->CloseEvent)(Event);
((void (__fastcall *)(__int64))gBS->FreePool)(v10);
}
LABEL_18:
((void (__fastcall *)(EFI_CAPSULE_HEADER **))gBS->CloseEvent)(Event);
}
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 MPDTContent
NVRAM variable is greater than 15
.
Thus, a potential attacker can dump X - 15
bytes from the stack (or global memory) into MPDTContent NVRAM variable by setting MPDTContent
NVRAM variable's size to X > 15
.
To fix this vulnerability the DataSize
must be re-initialized with the size of MPDTContent
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