Stack buffer overflow vulnerability leading to arbitrary code execution during DXE phase.
BINARLY efiXplorer team has discovered a stack buffer overflow vulnerability that allows an attacker to execute arbitrary code.
Image preview
Potential Impact
An attacker with local privileged access can exploit this vulnerability to elevate privileges from ring 3 or ring 0 (depends on the operating system) to a DXE driver and execute an arbitrary code. 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.
Image preview
Vulnerability Information
- BINARLY internal vulnerability identifier: BRLY-2023-002
- Insyde/Lenovo PSIRT assigned CVE identifier: CVE-2023-39281
- CVSS v3.1 Score 8.2 High AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H
Image preview
Affected Lenovo firmware
| Firmware | Module name | Module SHA256 | File GUID |
|---|---|---|---|
AsfSecureBootDxe | 5531a0720cf7b72d99937276df70d7971a137630d5ec8958e1a19f1dee989ff6 | feea2404-752e-4e6e-823c-877d848cb12b |
Image preview
Vulnerability description
The pseudocode of the vulnerable function is shown below (located at offset 0x520):
__int64 __fastcall AsfSecureBootChanged(EFI_EVENT Event)
{
// [COLLAPSED LOCAL DECLARATIONS. PRESS KEYPAD CTRL-"+" TO EXPAND]
EfiAmtWrapperProtocol = 0;
Size = 561;
Status = gBS->LocateProtocol(&EFI_AMT_WRAPPER_PROTOCOL_GUID, 0, &EfiAmtWrapperProtocol);
Result = Status;
if ( Status >= 0 )
{
gBS->CloseEvent(Event);
Status = gBS->LocateProtocol(&EFI_NON_VOLATILE_VARIABLE_PROTOCOL_GUID, 0, &EfiNonVolatileVariableProtocol);
Result = Status;
if ( Status >= 0 )
{
Status = gBS->LocateProtocol(&EFI_SMM_COMMUNICATION_PROTOCOL_GUID, 0, &EfiSmmCommunicationProtocol);
Result = Status;
if ( Status >= 0 )
{
Status = (*EfiNonVolatileVariableProtocol)(&CommBuffer, &CommSize);
Result = Status;
if ( Status >= 0 )
{
Status = Size;
if ( CommSize >= Size )
{
Status = gBS->LocateProtocol(&EDKII_VARIABLE_LOCK_PROTOCOL_GUID, 0, &EdkiiVariableLockProtocol);
Result = Status;
if ( Status >= 0 )
{
Result = EdkiiVariableLockProtocol->RequestToLock(
EdkiiVariableLockProtocol,
L"AsfSecureBoot",
&ASF_SECURE_BOOT_VARIABLE_GUID);
DataSize = 1;
Result = CommonGetVariable(L"AsfSecureBoot", &ASF_SECURE_BOOT_VARIABLE_GUID, &DataSize, Data);
Status = EFI_BUFFER_TOO_SMALL;
if ( Result == EFI_BUFFER_TOO_SMALL )
{
Status = CommonGetVariable(L"AsfSecureBoot", &ASF_SECURE_BOOT_VARIABLE_GUID, &DataSize, Data);
Result = Status;
}
if ( !Result )
{
// ...
}
}
}
}
}
}
}
return Status;
}
Let's take a closer look to the following code snippet:
Result = EdkiiVariableLockProtocol->RequestToLock(
EdkiiVariableLockProtocol,
L"AsfSecureBoot",
&ASF_SECURE_BOOT_VARIABLE_GUID);
DataSize = 1;
Result = CommonGetVariable(L"AsfSecureBoot", &ASF_SECURE_BOOT_VARIABLE_GUID, &DataSize, Data);
Status = EFI_BUFFER_TOO_SMALL;
if ( Result == EFI_BUFFER_TOO_SMALL )
{
Status = CommonGetVariable(L"AsfSecureBoot", &ASF_SECURE_BOOT_VARIABLE_GUID, &DataSize, Data);
Result = Status;
}
As we can see after the first call to CommonGetVariable() DataSize will be re-initialized if the actual size of the AsfSecureBoot variable is more then 1 byte.
In this case after the second call to CommonGetVariable() stack overflow may occur.
Attacker is able to rewrite return address of the current function or EfiSmmCommunicationProtocol.
This will result in executing an arbitrary code during the DXE phase.
-0000000000000068 Data db 8 dup(?)
...
-0000000000000030 EfiSmmCommunicationProtocol dq ? ; offset
...
+0000000000000000 r db 8 dup(?)
In order to fix this vulnerability, it is necessary to allocate memory for the value of the AsfSecureBoot variable after the DataSize update.
It should be noted that the AsfSecureBoot variable is write protected (locked). However, an attacker can change its value from runtime using a special IHISI service (VatsWrite). This is a separate security issue which will be reported within a separate advisory.
Image preview
Disclosure timeline
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.
| Disclosure Activity | Date (YYYY-mm-dd) |
|---|---|
Insyde/Lenovo PSIRT is notified | 2023-06-23 |
Insyde/Lenovo PSIRT assigned CVE number | 2023-09-15 |
Insyde/Lenovo PSIRT provide patch release | 2023-10-31 |
BINARLY public disclosure date | 2024-03-07 |
Image preview
Acknowledgements
Image preview
See if you are impacted now with our Firmware Vulnerability Scanner
Find Vulnerabilities, Generate SBOMs & CBOMs