An attacker with local privileged access can exploit this vulnerability to read the contents of the stack and use this information to exploit other vulnerabilities in DXE. A malicious code installed as a result of the vulnerability exploitation in a DXE driver could survive across an operating system (OS) boot process and runtime or modify NVRAM area on SPI flash storage (to gain persistence on target platform). Additionally, this vulnerability potentially could be used by threat actors to bypass OS security mechanisms (modify privileged memory or runtime variables), influence on the OS boot process, and in some cases would allow an attacker to hook or modify EFI Runtime services.
Binarly REsearch Team has discovered a stack memory leak vulnerability that allows a potencial attacker to write stack memory to NVRAM variable.
An attacker with local privileged access can exploit this vulnerability to read the contents of the stack and use this information to exploit other vulnerabilities in DXE. A malicious code installed as a result of the vulnerability exploitation in a DXE driver could survive across an operating system (OS) boot process and runtime or modify NVRAM area on SPI flash storage (to gain persistence on target platform).Additionally, this vulnerability potentially could be used by threat actors to bypass OS security mechanisms (modify privileged memory or runtime variables), influence on the OS boot process, and in some cases would allow an attacker to hook or modify EFI Runtime services.
The vulnerable function located at offet 0x2570
in the binary.The pseudocode of the vulnerable function is shown below:
__int64 __fastcall EventNotifier()
{
__int64 result;
EFI_SET_VARIABLE SetVariable;
EFI_GET_VARIABLE GetVariable;
EFI_SET_VARIABLE SetVariable_1;
__int64 DataSize;
unsigned int Attributes;
__int64 UnknownProtocolInterface;
__int16 LenovoAbtStatusValue[7];
char LenovoSecurityConfig[139];
result = LocateProtocol(&gProtocolGuid, &gDataSegmentBase);
if ( (result & 0x8000000000000000) == 0 )
{
DataSize = 0x8B;
result = (gRT->GetVariable)(
L"LenovoSecurityConfig",
&LENOVO_SECURITY_CONFIG_VARIABLE_GUID,
&Attributes,
&DataSize,
LenovoSecurityConfig);
if ( (result & 0x8000000000000000) == 0 )
{
SetVariable = gRT->SetVariable;
LenovoSecurityConfig[38] = 1;
if ( ((SetVariable)(
L"LenovoSecurityConfig",
&LENOVO_SECURITY_CONFIG_VARIABLE_GUID,
Attributes,
DataSize,
LenovoSecurityConfig) & 0x8000000000000000) == 0 )
(*(UnknownProtocolInterface + 0x10))(); // aa5978d6-4fba-4827-b776-9a11fc8cce4c
GetVariable = gRT->GetVariable;
DataSize = 14;
if ( ((GetVariable)(L"LenovoAbtStatus", &unk_4030, &Attributes, &DataSize, LenovoAbtStatusValue) & 0x8000000000000000) != 0 )
{
sub_28A8(LenovoAbtStatusValue, 14);
LenovoAbtStatusValue[2] = 0x100;
LenovoAbtStatusValue[0] = 1;
sub_28A8(&LenovoAbtStatusValue[3], 7);
}
SetVariable_1 = gRT->SetVariable;
LOBYTE(LenovoAbtStatusValue[2]) = 1;
return (SetVariable_1)(L"LenovoAbtStatus", &unk_4030, Attributes, DataSize, LenovoAbtStatusValue);
}
}
return result;
}
As we can see from the pseudocode, for the LenovoAbtStatus
variable gRT->SetVariable()
service is called with the DataSize
value, which can be overwritten inside the gRT->GetVariable()
service.
Thus, a potential attacker can write X - 14
bytes from the stack to NVRAM if writes any buffer of length X > 14
to the LenovoAbtStatus
NVRAM variable.
In order to fix this vulnerability, the DataSize
variable must be initialized before gRT->SetVariable()
.
This vulnerability is subject to a 90 day disclosure deadline. After 90 days elapsed or a patch has been made broadly available (whichever is earlier), the vulnerability report will become visible to the public.
Binarly REsearch Team