REsearch

REsearch

REsearch

Finding LogoFAIL: The Dangers of Image Parsing During System Boot

Binarly REsearch

Binarly REsearch team investigates vulnerable image parsing components across the entire UEFI firmware ecosystem and finds all major device manufacturers are impacted on both x86 and ARM-based devices.

[ See previous blog post “The Far-Reaching Consequences of LogoFAIL” preview of Black Hat EU presentation ]

As discussed in our previous blog, security defects in image parsers expose significant attack surfaces across the entire UEFI firmware ecosystem. Our LogoFAIL research, presented at Black Hat EU today, discusses a set of security vulnerabilities affecting all major device manufacturers on both x86 and ARM-based devices.

In this post, we discuss the motivation for the research, how we used fuzz-testing to discover this set of vulnerabilities, how we built a proof-of-concept to show the path to arbitrary code execution.

Most image parsers exist to make it possible to display logos during boot or in BIOS setup. However, vendors introduce features, like customization of a device’s boot logo, that allow users to specify data input for these parsers. This feature creates an additional and very serious threat to the security of modern devices.

Some raw realities:

Keeping in mind classical firmware supply chain complexity and its asynchronous nature, we asked ourselves: what if the graphic image parsers embedded into system firmware do not update frequently and use not only outdated but also customized versions of the common image parsing libraries?

While researching image parsers, our REsearch team realized that the impact of these sightings on the entire UEFI firmware industry is significant, so we decided to reference the exposed attack surfaces as LogoFAIL.

Icon of LogoFail: opened laptop with flames behind the lid, [Logo.fail] text with distortion effect over it

Identifying the attack surface of LogoFAIL

Earlier this year, our research team looked at some of the vulnerabilities discovered by the Binarly Transparency Platform and found that the number of image parsers have significantly increased over the years.

To identify how image data can reach the code in each parser, we used a bottom-up approach: starting from the image parsing function, we then just look “backwards” to find the sources of image data.

Code snippet from AMI-based firmware extracted for a Lenovo device
Code snippet from AMI-based firmware extracted for a Lenovo device

For example, in the previous screenshot, the ParseImage() function receives the output of the GetImage() function exported by EfiOemBadgingProtocol. By further analyzing GetImage(), we can understand how the ImageData variable is created and thus where the logo image is read from.

Normally, the logo is read directly from a firmware volume. Since the volumes are often signed and protected by a hardware-based Verified Boot technology (e.g., Intel Boot Guard), an attacker cannot store a custom logo there — that’s it, as long as the OEM private keys used to sign these sections are not leaked affecting the entire industry. But in this case, an attacker wouldn't care about the logo at all, because it allows them to inject any custom modules instead.

In other cases, OEM-specific customizations allow users to supply their own logo, so attackers can do that too. Most of these OEMs-specific customization read the logo from the EFI System Partition (ESP), a disk partition that is used by system firmware to load additional software such as boot loaders.

Given its role in the UEFI boot process, the ESP has been targeted by modern UEFI bootkits (such as ESPecter and FinSpy) by replacing OS bootloaders and achieving persistency.

Our advisories BRLY-2023-006 and BRLY-2023-018 contain a complete overview of the OEM-specific customizations we found, but in general we observed the following behaviors:

  1. The logo is read from a fixed location on the ESP, such as from “\EFI\OEM\Logo.jpg”;
  2. The OEM/IBV provides vendor-specific integrator tooling that can install a custom logo in a firmware capsule and flash the capsule from the OS;
  3. An NVRAM variable contains an ESP path where the logo is read from;
  4. The logo itself is stored inside an NVRAM variable in a compressed form.

These customization features represent a new attack surface because they allow attackers to modify the logo parsed during system boot and mount data-only attacks.

Screenshot from UEFITool with Intel Boot Guard coverage markings on
Screenshot from UEFITool with Intel Boot Guard coverage markings on

Keep in mind that even when none of the above customization methods are available, a device can still be exploited with a physical attack if the firmware region containing the logo is not covered by Boot Guard. In this case, the attack can be performed using an SPI flash programmer to inject the logo.

Certainly, this attack vector is worth being thoroughly researched to help the industry protect from such threats. However, the amount of code to be analyzed is huge, and for this reason, we decided to expand Binarly's internal program analysis framework, which empowers our products and supports instrumentation with emulation, to help manage this task. We were able to find all the documented vulnerabilities via fuzz-testing.

The sheer volume and severity of security problems we found during this research is further proof of the endemic security problems that affect the firmware supply chain ecosystem:

BRLY/CVE ID

Type

CVSS

Score

Impacted

IBV

Impacted Vendors

CWE

BRLY-LOGOFAIL-2023-001

DXE Memory Content Disclosure

5.1
(Medium)

Insyde

Acer, Dell, Framework, Fujitsu, HP, Intel, Lenovo

CWE-200

BRLY-LOGOFAIL-2023-002

DXE Memory Corruption

8.2
(High)

Insyde

Acer, Dell, Framework, Fujitsu, HP, Intel, Lenovo

CWE-122

BRLY-LOGOFAIL-2023-003

DXE Memory Corruption

8.2
(High)

Insyde

Acer, Dell, Framework, Fujitsu, HP, Intel, Lenovo

CWE-122

BRLY-LOGOFAIL-2023-004

DXE Memory Corruption

8.2
(High)

Insyde

Acer, Dell, Framework, Fujitsu, HP, Intel, Lenovo

CWE-122, CWE-125

BRLY-LOGOFAIL-2023-005

DXE Out-of-bounds Read

4.4
(Medium)

Insyde

Acer, Dell,Framework, Fujitsu, HP, Intel, Lenovo

CWE-125

BRLY-LOGOFAIL-2023-006

DXE Memory Corruption

8.2
(High)

Insyde

Acer, Dell, Framework, Fujitsu, HP, Intel, Lenovo

CWE-122, CWE-125

BRLY-LOGOFAIL-2023-007

DXE Memory Corruption

8.2
(High)

Insyde

Acer, Dell, Framework, Fujitsu, HP, Intel, Lenovo

CWE-122

BRLY-LOGOFAIL-2023-008

DXE Null Pointer Dereference

3.4
(Low)

Insyde

Acer, Dell, Framework, Fujitsu, HP, Intel, Lenovo

CWE-476

BRLY-LOGOFAIL-2023-009

DXE Out-of-bounds Read

4.4
(Medium)

Insyde

Acer, Dell, Framework, Fujitsu, HP, Intel, Lenovo

CWE-125

BRLY-LOGOFAIL-2023-010

DXE Null Pointer Dereference

3.4
(Low)

Insyde

Acer, Dell, Framework, Fujitsu, HP, Intel, Lenovo

CWE-476

BRLY-LOGOFAIL-2023-011

DXE Memory Content Disclosure

5.1
(Medium)

Insyde

Acer, Dell, Framework, Fujitsu, HP, Intel, Lenovo

CWE-200

BRLY-LOGOFAIL-2023-012

DXE Memory Corruption

8.2
(High)

Insyde

Acer, Dell, Framework, Fujitsu, HP, Intel, Lenovo

CWE-122, CWE-125

BRLY-LOGOFAIL-2023-013

DXE Memory Content Disclosure

5.1
(Medium)

AMI

Acer, Dell, Gigabyte, HP, Intel, Lenovo, MSI, Samsung, Supermicro

CWE-200

BRLY-LOGOFAIL-2023-014

DXE Out-of-bounds Read

4.4
(Medium)

AMI

Acer, Dell, Gigabyte, HP, Intel, Lenovo, MSI, Samsung, Supermicro

CWE-125

BRLY-LOGOFAIL-2023-015

DXE Out-of-bounds Read

4.4
(Medium)

AMI

Acer, Dell, Gigabyte, HP, Intel, Lenovo, MSI, Samsung, Supermicro

CWE-125

BRLY-LOGOFAIL-2023-016

DXE Memory Corruption

8.2
(High)

AMI

Acer, Dell, Gigabyte, HP, Intel, Lenovo, MSI, Samsung, Supermicro

CWE-122, CWE-190

BRLY-LOGOFAIL-2023-017

DXE Memory Corruption

8.2
(High)

AMI

Acer, Dell, Gigabyte, HP, Intel, Lenovo, MSI, Samsung, Supermicro

CWE-122

BRLY-LOGOFAIL-2023-018

DXE Memory Corruption

8.2
(High)

AMI

Acer, Dell, Gigabyte, HP, Intel, Lenovo, MSI, Samsung, Supermicro

CWE-122, CWE-190

BRLY-LOGOFAIL-2023-019

DXE Memory Corruption

8.2
(High)

AMI

Acer, Dell, Gigabyte, HP, Intel, Lenovo, MSI, Samsung, Supermicro

CWE-122, CWE-190

BRLY-LOGOFAIL-2023-020

DXE Memory Corruption

8.2
(High)

AMI

Acer, Dell, Gigabyte, HP, Intel, Lenovo, MSI, Samsung, Supermicro

CWE-787

BRLY-LOGOFAIL-2023-021

DXE Out-of-bounds Read

4.4
(Medium)

AMI

Acer, Dell, Gigabyte, HP, Intel, Lenovo, MSI, Samsung, Supermicro

CWE-125

BRLY-LOGOFAIL-2023-022

DXE Memory Corruption

8.2
(High)

AMI

Acer, Dell, Gigabyte, HP, Intel, Lenovo, MSI, Samsung, Supermicro

CWE-787

BRLY-LOGOFAIL-2023-023

DXE Memory Corruption

8.2
(High)

AMI

Acer, Dell, Gigabyte, HP, Intel, Lenovo, MSI, Samsung, Supermicro

CWE-122

BRLY-LOGOFAIL-2023-024

DXE Memory Corruption

8.2
(High)

AMI

Acer, Dell, Gigabyte, HP, Intel, Lenovo, MSI, Samsung, Supermicro

CWE-787

PS: This table does not cover all vendors in the device manufacturing industry. Our main priority was to research major UEFI IBVs, since the vulnerable parsers are in the codebase maintained by them as shown in the picture below. UML of vulnerable parsers are in the codebase maintained by them: Silicon vendor connected to EDK 2, which connected to Insyde, AMI, Phoenix, each of them is connected to OEM and Device vendor blocks. LogoFAIL vector of attack relies to EDK 2 and vendors described here.

We are constantly expanding our firmware dataset to improve coverage and detection capabilities of the Binarly Transparency Platform. It allowed us to determine that image parsers are common in device’s firmware. They are used to process not only most popular image formats like BMP, PNG and JPEG, but also more esoteric and less-known formats such as PCX and TGA. And all of them contain multiple high-impact security vulnerabilities.

Finding Bugs in Image Parsers

Allowing users, and thus potentially attackers, to customize their boot logo would be a totally acceptable behavior if the image libraries used to parse the logo did not contain any security flaws. To prove this point, we decided to run a fuzzer against these parsers, as fuzz-testing is very suited for finding bugs in parsing code. Our fuzzer is based on emulation capabilities that we developed for this research, which were specifically designed to be easily integrated with the modern fuzzing environment LibAFL.

After this, we prepared a fuzzing harness for every parser we discovered. The harness is a crucial component for fuzzing, since it initializes the environment and allows the fuzzer to interact with the program under test. In our case, the harness receives an image generated by the fuzzer, invokes the parsing function by setting the correct arguments and then checks for any crashes.

We then started a fuzzing campaign and fuzzed each parser for a variable period of time depending on the parser’s complexity. When the campaign finished, we were overwhelmed by the amount of crashes we found, so much that triaging them manually was going to be challenging. For this reason, we decided to expand Binarly's internal program analysis framework, which empowers our products and supports instrumentation with emulation, to support us in this task.

Demonstration of LogoFail Fuzzer work process

IBV

Vendor

Image Parser

Number of
Unique Root
Causes

Number of
Exploitable
Root Causes

CWE

Insyde

BMP

3

2

CWE-200: Exposure of Sensitive Information
CWE-122: Heap-based Buffer Overflow

GIF

4

2

CWE-122: Heap-based Buffer Overflow
CWE-125: Out-of-bounds Read

JPEG

3

0

CWE-125: Out-of-bounds Read
CWE-476: NULL Pointer Dereference

PCX

1

0

CWE-200: Exposure of Sensitive Information

PNG

0

0

 

TGA

1

1

CWE-122: Heap-based Buffer Overflow

CWE-125: Out-of-bounds Read

AMI

BMP

1

0

CWE-200: Exposure of Sensitive Information

GIF

2

2

CWE-122: Heap-based Buffer Overflow
CWE-787: Out-of-bounds Write

JPEG

3

2

CWE-125: Out-of-bounds Read

CWE-787: Out-of-bounds Write

PNG

6

4

CWE-122: Heap-based Buffer Overflow

CWE-125: Out-of-bounds Read

CWE-190: Integer Overflow

Phoenix

BMP

3

1

CWE-122: Heap-based Buffer Overflow

CWE-125: Out-of-bounds Read

GIF

2

1

CWE-125: Out-of-bounds Read

TOTAL

 

29

15

 

The table above breaks down the triaged crashes per vendor and image parser. In total, we found 29 unique crashes, out of which we consider 15 to be exploitable with arbitrary code execution as a likely outcome.

These results also show the scope and the impact of LogoFAIL, since each IBV has at least one exploitable bug inside their parsers, and every parser contains bugs. The only exception is Insyde’s PNG parser that is based on an open-source project, and was likely already well-tested by the community. As we can see from the CWE column, we found a lot of different bug classes, from division-by-zero exceptions to NULL pointer dereference, from out-of-bounds reads to heap overflows.

Root Causes

This triaging process gave us a good understanding of the root causes behind these vulnerabilities. While they cover a wide range of software security problems, the underlying theme is a lack of validation on attacker-supplied data.

OOB Write in BMP parser from Insyde firmware
OOB Write in BMP parser from Insyde firmware
Integer overflow in PNG parser from AMI firmware
Integer overflow in PNG parser from AMI firmware

For example, the first screenshot shows a bug in the BMP parser of Insyde. This bug is present in the code supporting the RLE4/RLE8 compression, a feature we haven’t seen in any other BMP parsers. This vulnerability manifests itself when PixelHeight (which is under the control of the attacker) and the variable i is 0. In this case, the variable Blt will be initialized to the address of BltBuffer[PixelWidth * -1]. In other words, the attacker can arbitrarily set Blt to any address below BltBuffer, and thus corrupt this memory when Blt is used to write.

The second screenshot is taken from the PNG parser of AMI and contains two different security vulnerabilities. The first bug is a missing check on the return value of the “EfiLibAllocateZeroPool” function, which returns NULL on failure. The second bug is an integer overflow on the 32-bit integer representing the allocation size. When the attacker sets the variable “PngWidth” to a large value, the multiplication by two will make the result overflow around and become a small value (for example: 0x80000200 * 2 = 0x400). In this way, the attacker can force the allocation of a buffer that is too small to hold the decoded PNG data and thus overflow the buffer when it is used.

The results from our fuzzing and subsequent bug triaging unequivocally say that none of these image parsers were ever tested by IBVs or OEMs. We can confidently say this because we found crashes in almost every parser we tested. Moreover, the fuzzer was able to find the first crashes after running just for a few seconds and, even worse, certain parsers were crashing on valid images found on the Internet.

Developing a Proof-of-Concept

In the firmware ecosystem, any bug can have profound consequences on the entire platform security and must therefore be addressed and fixed promptly. We decided to prove the severity of our findings by turning one of the crashes found by the fuzzer into arbitrary code execution during the DXE phase. We decided to postpone the release of the nitty-gritty details behind our PoC to give more time to end-users and vendors to patch and mitigate LogoFAIL.

Illustration of PoC process: PNG image contains IDAT Chunk, compressed IDAT chunk,  OutputBuffer contains attacker code.

The crash we selected as a starting point for developing the exploit is the integer overflow in the PNG parser discussed in the previous section. This picture shows a high-level overview of how this PNG parser works. Starting from the PNG image, the parser first locates and extracts the PNG chunks of the image. In particular, it finds the IHDR chunk to retrieve some information regarding the image, such as the width and height, and it concatenates all the IDAT chunks, which contains the PNG image data, into a single buffer (called “Compressed IDAT chunks” in the previous figure). The parser then decompresses the compressed IDAT chunks and writes the results to the “OutputBuffer.”

The value affected by the integer overflow depends on the image width (so it’s attacker controlled) and it’s used as an allocation size for the OutputBuffer. The attacker is therefore able to allocate an OutputBuffer that is too small and that will be overflown with attacker-controlled data during the decompression phase. By using this bug, it’s straightforward to overflow an arbitrary amount of attacker-controlled data on the UEFI heap.

From heap overflow to arbitrary code execution, the road is still long and winding. For now, we just want to anticipate that it involves a new exploitation technique for preserving allocated chunks and the corruption of core UEFI objects (PROTOCOL_ENTRY) to hijack the control flow.

As a proof of all we said in this blog, and in particular in this last section, we release the following video showing how an exploitation chain for LogoFAIL looks on a real device. After logging in, we start a terminal with Admin privileges. We then check that Secure Boot and Intel Boot Guard (Verified Boot) are enabled, and run the proof of concept. The PoC prepares some of the aforementioned objects, saves the malicious PNG file inside an NVRAM variable, and finally restarts the device. During the boot, the system firmware will parse the injected PNG and so the LogoFAIL attack will take place. In the video we demonstrate arbitrary code execution during DXE phase by printing a message on the display and by showing that our final payload is able to create a file on the Windows file system.

How do LogoFAIL vulnerabilities work?

Since the vulnerable parsers are developed and distributed by the IBVs – AMI, Insyde and Phoenix – a large percentage of devices UEFI firmware image out there contains a parser vulnerable to LogoFAIL. This is also confirmed by the data our platform constantly scans. Thanks to our triaging efforts, we were able to produce rules for fwhunt, our firmware vulnerability scanner, and confirm that every OEM is impacted by this supply chain problem. As we can see in the following table, we detected parsers vulnerable to LogoFAIL in hundreds of devices sold by Lenovo, Supermicro, MSI, HP, Acer, Dell, Fujitsu, Samsung and Intel.

Device

Vendor

IBV(s)

Vendor

Devices

Validated

LogoFAIL
Vulnerable
Parsers

LogoFAIL
Exploitable
Devices

Acer

AMI
Insyde

2218

614

139

Dell

AMI
Insyde
Phoenix

1420

526

0

Fujitsu

AMI
Insyde
Phoenix

549

347

0

Gigabyte

AMI

1329

1273

0

HP

AMI
Insyde

3312

940

0

Intel

AMI
Insyde

132

72

51

Lenovo

AMI
Insyde
Phoenix

1707

421

241

MSI

AMI

614

612

0

Samsung

AMI
Phoenix

46

10

0

Supermicro

AMI

5382

4225

0

The exploitability of these vulnerabilities relies on whether the user is able to input data to a parser. When these parsers are used to display a logo during boot and when this logo can be replaced by an attacker, using any of the OEM customization techniques described in the Attack Surface section of this blogpost, then LogoFAIL becomes an exploitable threat. And there are multiple scenarios that could lead to it:

  1. We found that certain vendors such as Lenovo, Intel and Acer allow users – and so attackers – to customize the logo shown during boot. It could be simply done via placing it into ESP (EFI System Partition) and adding or modifying certain variables in NVRAM, then rebooting the system. Administrator privileges are enough to perform this. In this case, hardware-based Verified Boot security features such as Intel Boot Guard or AMD Hardware-Validated Boot won’t protect against it since the logo is read outside the range covered by these.

    This attack vector can give an attacker an advantage in bypassing most endpoint security solutions and delivering a stealth firmware bootkit that will persist in an ESP partition or firmware capsule with a modified logo image. Technically, from a high-level perspective, the attack can be simplified into three steps, shown in the picture below.

    The LogoFAIL attack vector
    The LogoFAIL attack vector
  2. Another discovered way to customize the logo is the firmware update procedure, for example, using AMI tool: it allows patching firmware capsules in PFAT format and then flash firmware capsules in PFAT format. This is possible in case the logo is not a part of any signed block.
  3. When there is no expected way to customize the logo, it is still possible via physical attack vector: just with an SPI flash programmer if a logo is not covered with any hardware-based Verified Boot technology like Intel Boot Guard or AMD Hardware-Validated Boot.

The main restriction of latter cases are explained in the following pictures. Some vendors such as Dell are not directly exploitable for two reasons. First, as shown in the previous screenshots, Dell distributes firmware where the logo is covered by Intel Boot Guard and thus cannot be replaced by an attacker, even using a physical attack. Second, Dell doesn’t provide any logo customization and so it effectively secures the LogoFAIL attack surface. However, despite these devices not being at immediate risk, they still contain image parsers with high-severity vulnerabilities that need to be fixed, as they represent a hazard that could inadvertently turn into a security issue.

AMI ROM hole is covered with Boot Guard Dell devices (not exploitable)
AMI ROM hole is covered with Boot Guard Dell devices (not exploitable)
AMI ROM hole is not covered with Boot Guard on non-Dell device (exploitable)
AMI ROM hole is not covered with Boot Guard on a non-Dell device (exploitable)

What are the implications of LogoFAIL?

Some important things to keep in mind:

  1. These vulnerabilities can compromise the entire system's security, rendering "below-the-OS" security measures like any shade of Secure Boot ineffective, including Intel Boot Guard. This level of compromise means attackers can gain deep control over the affected systems.
  2. We’ve previously seen attackers abusing ESP partitions multiple times to modify operating system-related bootloaders to deliver UEFI bootkits (including BlackLotus). The LogoFAIL case creates a different perspective on the ESP partition attack surface with data-only exploitation by modifying the logo image. The comparison of LogoFAIL to most known recent threats is summarized in the following table.

    Attack Vector

    Vulnerability ID

    Exploited

    In-The-Wild

    Impact

    CVSS

    Score

    CWE

    LogoFAIL

    VU#811862

    N/A

    Intel Boot Guard and Secure Boot Bypass

    High
    Medium

    CWE-122: Heap-based Buffer Overflow

    CWE-125:Out-of-bounds Read

    Baton Drop

    CVE-2022-21894

    CVE-2023-24932

    BlackLotus

    Secure Boot Bypass

    6.7
    Medium

    CWE-358: Improperly Implemented Security Check for Standard

    3rd-party Bootloaders

    VU#309662

    N/A

    Secure Boot Bypass

    6.7
    Medium

    CWE-358: Improperly Implemented Security Check for Standard

    BootHole

    VU#174059

    N/A

    Secure Boot Bypass

    8.2
    High

    CWE-120: Buffer Copy without Checking the Size of Input

    As we can see, a LogoFAIL differs from BlackLotus or BootHole threats because it doesn't break runtime integrity by modifying the bootloader or firmware component. In this case, we are dealing with continued exploitation with a modified boot logo image, triggering the payload delivery in runtime, where all the integrity and security measurements happen before the firmware components are loaded.

    UEFI Secure Boot Root of Trust

    We can see from the figure above that any compromised signed UEFI component can break and bypass secure boot integrity without being detected by platform integrity or Secure Boot related mitigations. Existing device security measurements can effectively detect other threats from the comparison table.

  3. Since LogoFAIL targets UEFI specific code, this new threat is not confined to a single architecture, but it's instead another example of cross-silicon exploitation that affects both x86 and ARM devices.

    The Binarly Transparency Platform uniquely detects LogoFAIL vulnerable components in system firmware, and all our customers are informed about the impact on their code bases or enterprise infrastructure.

    Screenshot of Binarly Transparency platform with LogoFAIL detections
    A list of findings from the Binarly Transparency Platform
    Screenshot of detailed description of LogoFAIL finding from Binarly Transparency platform
    Detailed description of the selected LogoFAIL finding from the Binarly Transparency Platform

Are you interested in learning more about Binarly Transparency Platform or other solutions? Don't hesitate to contact us at fwhunt@binarly.io.

Tag list
Back to overview