[BRLY-2022-021] The stack buffer overflow vulnerability leads to arbitrary code execution.

March 21, 2023

Summary

BINARLY efiXplorer team has discovered a stack buffer overflow vulnerability that allows a attacker to execute arbitrary code.

Vulnerability Information

BINARLY internal vulnerability identifier: BRLY-2022-021
Insyde PSIRT assigned CVE identifier: CVE-2022-35897
FwHunt rule: BRLY-2022-021
CVSS v3.1 Score 7.6 High AV:P/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

Affected Insyde firmwares with confirmed impact by Binarly team

Fimware	Module name	Module SHA256	File GUID
Framework_Laptop_12th_Gen_Intel_Core_capsule_EFI_signed_allsku_3.01.bin	BdsDxe	d713c908151cf9085add4dce3059cf7b59cd337825b4c5d6b08afdfde23c06e6	fc5c7020-1a48-4198-9be2-ead5abc8cf2f

Potential impact

An attacker with physical access can exploit this vulnerability to execute arbitrary code during DXE phase. A malicious code installed as a result of the vulnerability exploitation could survive across an operating system (OS) boot process. 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.

Vulnerability description

The pseudocode of the vulnerable function is shown below:

EFI_STATUS __fastcall sub_2F338(__int64 a1)
{
  // [COLLAPSED LOCAL DECLARATIONS]

  DataSize = 1;
  v0 = sub_2A23C(2);
  v1 = sub_2A23C(1);
  (gRT->GetVariable)(L"SecureBootEnforce", &EFI_GENERIC_VARIABLE_GUID, &Attributes, &DataSize, &SecureBootEnforceData);
  gRT->GetVariable(L"SecureBoot", &EFI_SIMPLE_BOOT_FLAG_VARIABLE_GUID, 0, &DataSize, &SecureBootData);
  Res = SecureBootEnforceData & SecureBootData;
  Status = 0;
  if ( !gRT->GetVariable(L"RestoreBootSettings", &gVendorGuid, 0, &DataSize, &RestoreBootSettingsData)
    && RestoreBootSettingsData == 1
    && !Res
    && (!v1 || v0) )
  {
    Res = 1;
    sub_2FFC4(1);
    gRT->SetVariable(L"RestoreBootSettings", &gVendorGuid, 0, 0, 0);
    gRT->ResetSystem(EfiResetCold, 0, 0, 0);
  }
  if...
  return Status;
}

Consider following code snippet:

DataSize = 1;
...
(gRT->GetVariable)(L"SecureBootEnforce", &EFI_GENERIC_VARIABLE_GUID, &Attributes, &DataSize, &SecureBootEnforceData);
gRT->GetVariable(L"SecureBoot", &EFI_SIMPLE_BOOT_FLAG_VARIABLE_GUID, 0, &DataSize, &SecureBootData);
Res = SecureBootEnforceData & SecureBootData;
Status = 0;
if ( !gRT->GetVariable(L"RestoreBootSettings", &gVendorGuid, 0, &DataSize, &RestoreBootSettingsData) ) ...

As we can see, the DataSize variable is not initialized before every gRT->GetVariable() service call (it is only initialized once before the first service call).

If an attacker can change the values of at least two variables out of three (SecureBootEnforce, SecureBoot, RestoreBootSettings), it will possible to execute arbitrary code via stack overflow:

a first service call gRT->GetVariable() can be used to set the stack variable DataSize
a second gRT->GetVariable() service call can be used to overflow the stack buffer and overwrite the return address of the parent function

Below is the location of variables on the stack:

+0000000000000028  r              db 8 dup(?)
+0000000000000030 RestoreBootSettingsData db ?
+0000000000000031                 db ? ; undefined
+0000000000000032                 db ? ; undefined
+0000000000000033                 db ? ; undefined
+0000000000000034                 db ? ; undefined
+0000000000000035                 db ? ; undefined
+0000000000000036                 db ? ; undefined
+0000000000000037                 db ? ; undefined
+0000000000000038 SecureBootData  db ?
+0000000000000039                 db ? ; undefined
+000000000000003A                 db ? ; undefined
+000000000000003B                 db ? ; undefined
+000000000000003C                 db ? ; undefined
+000000000000003D                 db ? ; undefined
+000000000000003E                 db ? ; undefined
+000000000000003F                 db ? ; undefined
+0000000000000040 SecureBootEnforceData db ?
...
+00000000000000XX return address of the parent function

As a rule, the values of the listed variables cannot be changed from the operating system. However, these values can be changed by hardware overwriting the NVRAM area on the SPI Flash.

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
Framework PSIRT is notified	2021-06-27
Insyde PSIRT confirmed reported issue	2022-07-19
Insyde PSIRT assigned CVE number	2022-07-27
Insyde provide patch release	2022-11-04
BINARLY public disclosure date	2023-03-21

Acknowledgements

BINARLY efiXplorer team

Back to overview

Binarly Advisories

REsearch