[BRLY-2023-006] Multiple vulnerabilities in image parsing functions can be exploited by an attacker with local access.

Summary

Lenovo firmware allows end-users to customize the logo displayed by a device during boot.BINARLY REsearch team has uncovered multiple critical vulnerabilities in the image parsing libraries used to parse customized boot logos.This vulnerability poses a high-severity risk as it introduces an unexplored attack surface that can be exploited by malicious actors with only write permissions over the EFI System Partition (ESP) of a device.Our analysis over a dataset of Lenovo firmware identified hundreds of Lenovo products affected by this issue, including devices running firmware developed by Insyde Software, American Megatrends International and Phoenix Technologies.Given the systemic industry-wise scope of this vulnerability we will refer to it as LogoFAIL.

Vulnerability Information

• BINARLY internal vulnerability identifier: BRLY-2023-006
• Insyde PSIRT assigned CVE identifier: CVE-2023-40238
• Phoenix PSIRT assigned CVE identifier: CVE-2023-5058
• 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 Lenovo firmware with confirmed impact by Binarly REsearch Team

Vulnerability Summary

An attacker can exploit LogoFAIL by storing a maliciously crafted logo image on the ESP of the victim device (e.g., under \EFI\lenovo\logo\mylogo_2240x1200.bmp) and restart the system under attack.During the boot process the system firmware will parse the attacker-supplied logo, thus an attacker can exploit any vulnerability in the image parser and take control of the execution flow.LogoFAIL can be exploited by attackers with write access to the ESP of the victim device, and can be used to bypass SecureBoot and infect any operating system.

In the following sections, we explore the functions and protocols used to retrieve a logo image from the ESP.Then, we explore how image parsing libraries and their respective protocols are installed and used during the boot process.

Vulnerability description (Insyde firmware)

How logos are read from the ESP

In Insyde-based firmware the interactions with the ESP happen in a custom protocol (4b11ff5b-590c-4bfe-96a5-04bc5cca5c11) installed by the OemBadgingSupportDxe driver.More precisely, the function at address 0x44F4 initializes the variable ImagePath by concatenating the string  EFI\lenovo\logo\ and the content of the NVRAM variable LBLDESPFN.The function ReadsLogo is then called, which, as the name suggests, reads the logo stored at ImagePath and stores the image content and the image size into v21 and v22, respectively.Next, as a form of integrity checking, the ChecksCRC32 function compares the CRC32 of the image logo with the content of the LBLDVC variable.When the CRC32 comparison succeeds, the LogoData and LogoDataSize parameters are finally set to v21 and v22.

EFI_STATUS __fastcall sub_44F4(__int64 a1, char **LogoData, _QWORD *LogoDataSize)
{
...
  v11 = gRT->GetVariable("LBLDESPFN", &VendorGuid, 0i64, &DataSize, Data);
  v14 = "EFI\\lenovo\\logo\\"
  ImagePathSize = 2 * (strlen(v14) + strlen(Data+4)) + 4;
  ImagePath = Alloc(ImagePathSize);

  if ( ImagePath )
  {
    snprintf(ImagePath, v16, "%s%s", "EFI\\lenovo\\logo\\", Data + 4);
    ReadsLogo(ImagePath, &v21, &v22); // sub_419C
    v20 = ChecksCRC32(v21); // sub_43E8
    if ( v20 >= 0 )
    {
      *LogoDataSize = v22;
      *LogoData = v21;
      *(a1 + 16) = *Data; // Setting the logo format (0=BMP, 1=JPEG..)
    }
    return v20;
  }

(Vulnerable) Image Parsing Protocols

During our analysis of a Lenovo Yoga's firmware image, we observed the presence of the following image parsers:

Upon analyzing them, we discovered that these drivers exhibit a common structure: the driver entry point function registers the corresponding image parsing protocol using InstallProtocolInterface and the protocol interface comprises of a single function (an exception is the Gif Decoder protocol that exports four functions) responsible for implementing the actual parser for a specific image type.The prototype of the parsing function is the following:

EFI_STATUS sub_1A689C(
  unsigned int *LogoImage, unsigned __int64 LogoImageSize,
  char* DecodedLogoImage, unsigned int *DecodedLogoImageSize,
  int *LogoWidth, int *LogoHeight
  )

Combining Reading and Parsing

We then set out to find a function where an image read from the ESP is passed to any image parsers: after some reversing, we found such function (sub_1C27EC) in the BdsDxe driver. Finally, we confirmed our findings empirically: saving an image under EFI\lenovo\logo\mylogo_2240x1400.bmp and setting the NVRAM variables LBLDESP and LBLDVC accordingly was enough to make our custom logo shown during boot.

In the upcoming section "Finding Crashes in Image Parsers" we will discuss how we found crashes in the aforementioned image parsers. In particular, we identified an out-of-bounds bug in the BMP parser that allows an attacker to write any memory address in the 4GB region below a specific heap address with arbitrary values.After installing this maliciously-crafted BMP image, we confirmed that the device bricks during the boot process, as the image parser write to an unmapped memory address.To "unbrick" the device, we found two possible solutions:1) Extract the SSD, connect it to another device, mount the ESP partition and remove the logo image2) Reflash the SPI to rewrite LBLDESP variable (this will effectively remove support from custom logo, since the "MaybeLogoSupport" of LBLDESP_STRUCT will be set to 0)

Please note that we followed the official Lenovo recommendation of "hold the power button for at least 10 second", but this didn't work for us and the device remained unable to boot.

Vulnerability description (Phoenix firmware)

For Phoenix firmware, sub_ABD33C of SystemAcpiBgrtDxe calculates the six different combinations of ("EFI\Lenovo\logo\mylogo", "EFI\Lenovo\logo\mylogo_WxH") and (".jpg", ".bmp", ".gif") and check if the resulting file exists on the ESP. When an existing file is found, the function checks whether the CRC32 of the first 512 bytes of the logo matches the content of the variable LBLDVC. If the check is successful, the logo image is passed to the image parsing protocol installed by the SystemImageDecoderDxe module.

The internals of this parsing protocol are quite simple: after finding the logo image type by matching various magic numbers, it invokes the correct parser.This image parsing module supports the following image types: JPEG, GIF89, GIF87 and BMP.

Vulnerability description (AMI firmware)

For AMI firmware, both reading and parsing the logo happen inside the AMITSE driver.In particular, function sub_3A96C creates a filename by concatenating the content of the variable LnvOemLogoData and the string "User.gif", and stores the content of the resulting file in a global variable (sub_3A1B8). If this file does not exists, sub_3A96C will try a similar approach with string "User.bmp".

The execution will then continue until the image parsing library located at sub_D5C4 is called. This function support parsing the logo as a BMP, PNG, GIF or JPEG image.

Finding Crashes in Image Parsers

To evaluate the robustness of the image parsers mentioned in this advisory, we tested each of them with fuzz testing techniques.This resulted in the discovery of multiple crashes in all tested parsers, except for the PNG parser contained in the Insyde-based firmware.These crashes cover a wide range of issues, from less severe out-of-bounds reads to more critical out-of-bounds arbitrary writes where the attacker controls both the target memory address and the written content.In the next sections we summarize the crashes we found during this security evaluation.

Insyde

Phoenix

AMI

Preliminarly list of affected Lenovo devices

Finally, to evaluate the impact of out findings, we explored an internal dataset of Lenovo firmware. The firmware images contained in the following table matched any of the following rules:- PHOENIX: the module with GUID b8e63775-bb0a-43f0-a843-5be8b14f8ccd uses LBLDVC but not LBLDESPFN- INSYDE: the module with GUID 12aedbea-392d-4e2a-8789-5f6dc6b23661 uses LBLDESPFN, LBLDVC and LBLDESP- AMI: the firmware image contains the strings LnvOemLogoData and User.gif

‍

How to fix it

The easiest way to fix this issue is to disable the support for user-supplied logos.However, on the longer term, we the recommended to either support only BMP files and use the well-tested BMP parsing libraries to process the logos.In case Lenovo wants to support multiple image file formats then we recommend to thoroughly test any image parsers shipped with Lenovo firmware.

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