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

Summary

Binarly REsearch Team has discovered a stack buffer overflow vulnerability that allows a attacker to execute arbitrary code.

Vulnerability Information

• BINARLY internal vulnerability identifier: BRLY-2022-019
• Insyde PSIRT assigned CVE identifier: CVE-2022-36337
• FwHunt rule: BRLY-2022-019
• CVSS v3.1 Score 7.7 High AV:L/AC:L/PR:H/UI:R/S:C/C:H/I:H/A:H

Affected Insyde firmwares with confirmed impact by Binarly REsearch Team

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 Runtime UEFI application and execute 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.

Vulnerability description

The vulnerability exists in a function from the protocol b2b63aa3-6c0c-44a4-a052-2c0d85e01c96.

.data:0000000000000610 ProprietaryProtocolInterface dq 1
.data:0000000000000618                 dq offset sub_3C8 ; <- vulnerable function
.data:0000000000000620                 dq offset sub_4D4

This function can be called in the following modules:

• MebxSetup {1ce34cff-dfe9-4d9d-b264-166ffcb8315a}
• Mebx {90dadb68-b868-4d62-a07f-09b3b64da039}

The pseudocode of the vulnerable function is shown below:

EFI_STATUS __fastcall sub_3C8(UINTN DataSize, void *Data)
{
  __int64 Status;
  EFI_HANDLE Handle;
  void *Dst;
  char MebxDataValue;
  UINTN DataSizea;

  Dst = Data;
  DataSizea = 0;
  Status = gRT->GetVariable(L"MebxData", &MEBX_DATA_GUID, 0, &DataSizea, &MebxDataValue);
  if ( Status == EFI_BUFFER_TOO_SMALL )
    Status = gRT->GetVariable(L"MebxData", &MEBX_DATA_GUID, 0, &DataSizea, &MebxDataValue);
  if ( Status >= 0 && (DataSizea != DataSize || DataSizea && CompareMem(&Dst, &MebxDataValue, DataSizea))
    || Status == EFI_NOT_FOUND )
  {
    gRT->SetVariable(L"MebxData", &MEBX_DATA_GUID, 3, DataSize, Dst);
    Handle = 0;
    return gBS->InstallProtocolInterface(&Handle, &UPDATE_SMBIOS_HW_ASSET_TABLE_GUID, EFI_NATIVE_INTERFACE, 0);
  }
  return Status;
}

As we can see from the pseudocode, the gRT->GetVariable() will be called twice (the first time in order to get the DataSizea, the second time in order to get the value of the MebxData NVRAM variable).However, there are no checks for DataSizea before second gRT->GetVariable() call.

An attacker can change the value of the MebxData NVRAM variable and thus control the DataSizea.This can lead to stack overflow and arbitrary code execution.

+0000000000000018  r              db 8 dup(?)
+0000000000000020                 db ? ; undefined
+0000000000000021                 db ? ; undefined
+0000000000000022                 db ? ; undefined
+0000000000000023                 db ? ; undefined
+0000000000000024                 db ? ; undefined
+0000000000000025                 db ? ; undefined
+0000000000000026                 db ? ; undefined
+0000000000000027                 db ? ; undefined
+0000000000000028 Dst             dq ?                    ; offset
+0000000000000030 MebxDataValue   db ?
...
+00000000000000XX return address of the parent function

The variable MebxDataValue is located on the stack above the return address from the current function, but an attacker can overwrite the return address of the parent function.

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.

Acknowledgements

Binarly REsearch Team