Header bannerHeader banner
Advisory ID:
BRLY-LOGOFAIL-2023-007

[BRLY-LOGOFAIL-2023-007] Memory Corruption vulnerability in DXE driver

June 20, 2024
Severity:
High
CVSS Score
8.2
Public Disclosure Date:
June 19, 2024
CVE ID:
CVE-2023-40238

Summary

BINARLY efiXplorer team has discovered a OOB Write vulnerability in Insyde firmware. Unchecked ImageSize (which depends on ImageWidth and ImageHeight) results in allocation of a zero-sized buffer and subsequent writing to it during GIF file processing in Insyde firmware.

Vendors Affected

Affected Products

Yoga 7 14IAL7
,

Potential Impact

An attacker with local 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 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."

Summary

BINARLY efiXplorer team has discovered a OOB Write vulnerability in Insyde firmware. Unchecked ImageSize (which depends on ImageWidth and ImageHeight) results in allocation of a zero-sized buffer and subsequent writing to it during GIF file processing in Insyde firmware.

Vulnerability Information

     
  • BINARLY internal vulnerability identifier: BRLY-LOGOFAIL-2023-007  
  • Insyde PSIRT assigned CVE identifier: CVE-2023-40238  
  • CVSS v3.1: 8.2 High AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H

Affected modules with confirmed impact by Binarly team

Module name Module GUID Module SHA256
GifDecoderDxe 1353de63-b74a-4bef-80fd-2c5cfa83040b 9d8b18a89f6b83d3e7b7ea68587415fce6d9f4f4f819ab0f2f068e48e68f7924

Potential impact

An attacker with local access can exploit this vulnerability to elevate privileges from ring 3 or ring 0 (depending 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.

Vulnerability description

The pseudocode of the vulnerable function is shown below:

__int64 __fastcall DecodeLZW(
        char *Image,
        unsigned __int64 ImageSize,
        char a3,
        __int64 a4,
        unsigned __int16 Width,
        unsigned __int16 a6,
        EFI_GRAPHICS_OUTPUT_BLT_PIXEL *BltOutput)
{
  HeapStruct *HeapArray1; // r13
  char Value; // cl
  char *Image1; // r11
  unsigned __int16 Bound; // bx
  unsigned __int8 Total; // r9
  __int16 v13; // di
  unsigned __int16 Idx; // r12
  unsigned __int8 v15; // si
  unsigned int v16; // r10d
  unsigned __int16 v17; // r15
  unsigned __int16 YVar; // r8
  unsigned __int16 Index; // cx
  HeapStruct *HeapArrayEntry; // rax
  unsigned __int16 v21; // bp
  UINT8 *v22; // r14
  unsigned __int64 v23; // rax
  char v24; // cl
  unsigned __int16 CodeVal; // r11
  __int16 v26; // r9
  unsigned __int16 v27; // ax
  unsigned __int16 v28; // ax
  __int64 Idx0; // rdx
  __int64 XVar; // rax
  __int64 v31; // rdx
  char v33; // [rsp+0h] [rbp-68h]
  unsigned __int8 v34; // [rsp+1h] [rbp-67h]
  unsigned __int16 v35; // [rsp+2h] [rbp-66h]
  __int16 v36; // [rsp+4h] [rbp-64h]
  __int16 v37; // [rsp+6h] [rbp-62h]
  unsigned __int16 v38; // [rsp+8h] [rbp-60h]
  unsigned __int16 v39; // [rsp+10h] [rbp-58h]
  char *v40; // [rsp+70h] [rbp+8h]

  HeapArray1 = HeapArray;
  Value = *Image;
  Image1 = Image + 1;
  Bound = 1 << Value;
  v40 = Image1;
  v39 = Bound;
  Total = Value + 1;
  v36 = -1;
  v37 = (1 << Value) + 1;
  v13 = -1;
  v34 = Value + 1;
  v38 = (1 << Value) + 2;
  Idx = v38;
  v35 = v38;
  v15 = Value + 1;
  v33 = Value + 1;
  v16 = 0;
  v17 = 0;
  YVar = 0;
  Index = 0;
  if ( Bound )
  {
    HeapArrayEntry = HeapArray;
    do
    {
      HeapArrayEntry->field_2 = Index++;
      HeapArrayEntry->field_0 = -1;
      ++HeapArrayEntry;
    }
    while ( Index < Bound );
    HeapArray1 = HeapArray;
  }
  if ( Total >> 3 <= ImageSize )
  {
    v21 = a6;
    v22 = qword_1D50;
    do
    {
      v23 = v16 >> 3;
      v24 = v16 & 7;
      v16 += v15;
      CodeVal = ((1 << v15) - 1) & (*&Image1[v23] >> v24);
      if ( CodeVal == v37 )
        return v16;
      if ( CodeVal == Bound )
      {
        Idx = v38;
        v15 = Total;
        v35 = v38;
        v13 = Bound;
        v33 = Total;
        v36 = Bound;
        goto LABEL_40;
      }
      if ( YVar == v21 )
        return v16;
      v26 = -1;
      if ( CodeVal >= Idx )
      {
        if ( v13 == Bound )
          goto LABEL_44;
        v26 = 0;
        v28 = v13;
        if ( v13 != -1 )
        {
          do
          {
            v22[++v26] = HeapArray1[v28].field_2;
            v28 = HeapArray1[v28].field_0;
          }
          while ( v28 != 0xFFFF );
          v15 = v33;
          v21 = a6;
        }
        *v22 = v22[v26];
      }
      else
      {
        v27 = CodeVal;
        if ( CodeVal != 0xFFFF )
        {
          do
          {
            v22[++v26] = HeapArray1[v27].field_2;
            v27 = HeapArray1[v27].field_0;
          }
          while ( v27 != 0xFFFF );
          v21 = a6;
        }
        if ( v13 == Bound )
          goto LABEL_23;
      }
      Idx0 = Idx++;
      v35 = Idx;
      HeapArray1[Idx0].field_0 = v13;
      HeapArray1[Idx0].field_2 = v22[v26];
LABEL_23:
      if ( v26 >= 0 )
      {
        do
        {
          XVar = v26--;
          v31 = v22[XVar];
          LODWORD(XVar) = v17++;
          // Vulnerability:
          // According to EDK2 description of AllocatePool function:
          // If AllocationSize is 0, then a valid buffer of 0 size is returned

          // BltOutput is allocated in previous function:
          // ImageData = (EFI_GRAPHICS_OUTPUT_BLT_PIXEL *)AllocatePool(ImageSize);
          // Where ImageSize = ImageWidth * ImageHeight * sizeof(EFI_GRAPHICS_OUTPUT_BLT_PIXEL)

          // BRLY-LOGOFAIL-2023-007: Unchecked ImageSize (which depends on ImageWidth and ImageHeight) results
          // in allocation of a zero-sized buffer and subsequent writing to it
          
          BltOutput[(XVar + Width * YVar)] = *(a4 + 4 * v31);
          if ( v17 == Width )
          {
            if ( a3 )
            {
              if ( (YVar & 7) != 0 )
              {
                if ( (YVar & 3) != 0 )
                {
                  if ( (YVar & 1) != 0 )
                  {
                    YVar += 2;
                  }
                  else
                  {
                    YVar += 4;
                    if ( YVar >= v21 )
                      YVar = 1;
                  }
                }
                else
                {
                  YVar += 8;
                  if ( YVar >= v21 )
                    YVar = 2;
                }
              }
              else
              {
                YVar += 8;
                if ( YVar >= v21 )
                  YVar = 4;
              }
            }
            else
            {
              ++YVar;
            }
            v17 = 0;
            if ( YVar == v21 )
              break;
          }
        }
        while ( v26 >= 0 );
        Bound = v39;
        v13 = v36;
        v15 = v33;
        Idx = v35;
        HeapArray1 = HeapArray;
      }
LABEL_40:
      if ( Idx < 1 << v15 )
        goto LABEL_43;
      if ( v15 < 0xCu )
      {
        v33 = ++v15;
LABEL_43:
        v13 = CodeVal;
        v36 = CodeVal;
      }
LABEL_44:
      Total = v34;
      Image1 = v40;
    }
    while ( (v16 + v15) >> 3 <= ImageSize );
  }
  return v16;
}

The vulnerable code pattern is located here:

// BRLY-LOGOFAIL-2023-007: Unchecked ImageSize (which depends on ImageWidth and ImageHeight) results
// in allocation of a zero-sized buffer and subsequent writing to it
BltOutput[(XVar + Width * YVar)] = *(a4 + 4 * v31);

Blt buffer will be allocated as follows in the H2OHiiCreateAnimationFromMem() function:

// Vulnerability:
// there are no check for ImageSize
// When ImageSize is 0, AllocatePool will return valid pointer to empty buffer
// This will then lead to an OOB Read
ImageData = AllocatePool(4 * ImageWidth * ImageHeight);
if ( !ImageData )
  break

As we can see from the allocation routine, the result of AllocatePool() is compared with NULL, however when allocation size ( 4 * ImageWidth * ImageHeight) is equal to 0, AllocatePool() will return valid heap pointer to zero-size buffer.

Thus, any read or write operation of the relative allocated buffer will be out-of-bounds.

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 (YYYY-mm-dd)
Lenovo PSIRT is notified 2023-06-21
Lenovo ID (LEN-132940) is assigned 2023-06-22
CERT/CC is notified 2023-07-10
Insyde PSIRT confirmed reported issues 2023-09-10
Insyde PSIRT assigned CVE ID 2023-11-27
Insyde advisory release date 2023-12-06
BINARLY public disclosure date 2024-06-19

Acknowledgements

BINARLY efiXplorer team

Tags
Vulnerability
supply chain
FWHunt
See if you are impacted now with our Firmware Vulnerability Scanner