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

Summary

Binarly REsearch Team has discovered an integer overflow on memory allocation size that leads to OOB Write operations during PNG file processing in AMI firmware.

Vulnerability Information

 
• BINARLY internal vulnerability identifier: BRLY-LOGOFAIL-2023-019  
• AMI PSIRT assigned CVE identifier: CVE-2023-39538  
• 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 REsearch Team

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:

unsigned __int64 __fastcall sub_33FE4(
        __int64 a1,
        unsigned int a2,
        _QWORD *a3,
        UINTN *a4,
        unsigned int *a5,
        unsigned int *a6)
{
  __int64 v8; // rbx
  __int64 height; // rcx
  __int64 width; // rax
  UINTN size; // rcx
  _BYTE *ZeroPool; // rax MAPDST
  unsigned int i; // r8d
  unsigned int j; // r9d
  __int64 v16; // rdx
  _BYTE *v17; // rdx

  dword_973A0 = sub_186A0;
  dword_97330 = 0x7FFFFFFF;
  dword_97334 = 0x7FFFFFFF;
  dword_97338 = 0x7FFFFFFF;
  v8 = 0i64;
  if ( DecodePNG(a1, a2) )
    return 0x8000000000000015ui64;
  height = Height;
  width = Width;
  *a5 = Height;
  *a6 = width;
  size = 4 * width * height;
  *a4 = size;
  ZeroPool = AllocateZeroPool(size);
  *a3 = ZeroPool;
  if ( !ZeroPool )
    return 0x8000000000000009ui64;
  for ( i = 0; i < *a5; ++i )
  {
    for ( j = 0; j < *a6; ZeroPool += 4 )
    {
      if ( j >= Width )
        v16 = 4 * Width * (i + 1) - 4;
      else
        v16 = 4 * (j + i * Width);
      v17 = (DecodedImg + v16);
      ++j;
      *ZeroPool = v17[2];
      ZeroPool[1] = v17[1];
      ZeroPool[2] = *v17;
    }
  }
  return v8;
}

As we can see from the pseudocode, the width and height variables are not validated. The attacker can arbitrarly set these variables an thus trigger an integer overflow when ZeroPool is initialized from EfiLibAllocateZeroPool((4 * width * height)). Since ZeroPool is later used in this function to copy the uncompressed PNG image, the integer overflow forces the allocation of buffer that is too small to contain the intended data, thus creating an arbitrary heap overflow.

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