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.
Binarly REsearch 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.
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.
Let's take Inspiron 15 3511, Vostro 15 3510's firmware (version: 0.1.18.2, module sha256: 85d1e1cf6f5175d22ab262bc5034720287bfaf54e5a1b9074e624b106f627808) as an example.
The following code in the module actually allows leaking memory:
gRT->GetVariable()
offset: 0xe3e
gRT->SetVariable()
offset: 0xe6c
__int64 __fastcall sub_BC8(EFI_CAPSULE_HEADER **a1)
{
__int64 result; // rax
__int64 v3; // [rsp+30h] [rbp-D0h] BYREF
_BYTE v4[144]; // [rsp+40h] [rbp-C0h] BYREF
_BYTE v5[688]; // [rsp+D0h] [rbp-30h] BYREF
_BYTE v6[1072]; // [rsp+380h] [rbp+280h] BYREF
_BYTE v7[1952]; // [rsp+7B0h] [rbp+6B0h] BYREF
_BYTE v8[2096]; // [rsp+F50h] [rbp+E50h] BYREF
__int64 v9; // [rsp+17A0h] [rbp+16A0h] BYREF
__int64 v10; // [rsp+17A8h] [rbp+16A8h] BYREF
result = ((__int64 (__fastcall *)(EFI_GUID *, _QWORD, __int64 *))gBS->LocateProtocol)(
&AMI_TSE_SETUP_ENTER_PROTOCOL_GUID,
0i64,
&v3);
if ( result >= 0 )
{
sub_11D84();
v10 = 1943i64;
((void (__fastcall *)(const __int16 *, EFI_GUID *, _QWORD, __int64 *, _BYTE *))gRT->GetVariable)(// <= first call (we can rewrite DataSize here)
L"Setup",
&EFI_SETUP_VARIABLE_GUID,
0i64,
&v10,
v7);
((void (__fastcall *)(const __int16 *, EFI_GUID *, __int64, __int64, _BYTE *))gRT->SetVariable)(// <= second call
L"ColdReset",
&EFI_SETUP_VARIABLE_GUID,
2i64,
v10,
v7);
v10 = 1057i64;
((void (__fastcall *)(const __int16 *, EFI_GUID *, _QWORD, __int64 *, _BYTE *))gRT->GetVariable)(// <= first call (we can rewrite DataSize here)
L"SaSetup",
&SA_SETUP_VARIABLE_GUID,
0i64,
&v10,
v6);
((void (__fastcall *)(const __int16 *, EFI_GUID *, __int64, __int64, _BYTE *))gRT->SetVariable)(// <= second call
L"SaColdReset",
&SA_SETUP_VARIABLE_GUID,
2i64,
v10,
v6);
v10 = 143i64;
((void (__fastcall *)(const __int16 *, EFI_GUID *, _QWORD, __int64 *, _BYTE *))gRT->GetVariable)(// <= first call (we can rewrite DataSize here)
L"MeSetup",
&ME_SETUP_VARIABLE_GUID,
0i64,
&v10,
v4);
((void (__fastcall *)(const __int16 *, EFI_GUID *, __int64, __int64, _BYTE *))gRT->SetVariable)(// <= second call
L"MeColdReset",
&ME_SETUP_VARIABLE_GUID,
2i64,
v10,
v4);
v10 = 678i64;
((void (__fastcall *)(const __int16 *, EFI_GUID *, _QWORD, __int64 *, _BYTE *))gRT->GetVariable)(// <= first call (we can rewrite DataSize here)
L"CpuSetup",
&CPU_SETUP_VARIABLE_GUID,
0i64,
&v10,
v5);
((void (__fastcall *)(const __int16 *, EFI_GUID *, __int64, __int64, _BYTE *))gRT->SetVariable)(// <= second call
L"CpuColdReset",
&CPU_SETUP_VARIABLE_GUID,
2i64,
v10,
v5);
v10 = 2083i64;
((void (__fastcall *)(const __int16 *, EFI_GUID *, _QWORD, __int64 *, _BYTE *))gRT->GetVariable)(// <= first call (we can rewrite DataSize here)
L"PchSetup",
&PCH_SETUP_VARIABLE_GUID,
0i64,
&v10,
v8);
((void (__fastcall *)(const __int16 *, EFI_GUID *, __int64, __int64, _BYTE *))gRT->SetVariable)(// <= second call
L"PchColdReset",
&PCH_SETUP_VARIABLE_GUID,
2i64,
v10,
v8);
v10 = 2i64;
((void (__fastcall *)(const __int16 *, EFI_GUID *, _QWORD, __int64 *, __int64 *))gRT->GetVariable)(// <= first call (we can rewrite DataSize here)
L"SiSetup",
&SI_SETUP_VARIABLE_GUID,
0i64,
&v10,
&v9);
((void (__fastcall *)(const __int16 *, EFI_GUID *, __int64, __int64, __int64 *))gRT->SetVariable)(// <= second call
L"SiColdReset",
&SI_SETUP_VARIABLE_GUID,
2i64,
v10,
&v9);
return ((__int64 (__fastcall *)(EFI_CAPSULE_HEADER **))gBS->CloseEvent)(a1);
}
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 SiSetup
NVRAM variable is greater than 2
.
Thus, a potential attacker can dump X - 2
bytes from the stack (or global memory) into SiColdReset NVRAM variable by setting SiSetup
NVRAM variable's size to X > 2
.
To fix this vulnerability the DataSize
must be re-initialized with the size of SiColdReset
before calling gRT->SetVariable()
.
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.
Binarly REsearch Team