Just about every Windows and Linux device vulnerable to new LogoFAIL firmware attack

UEFIs booting Windows and Linux devices can be hacked by malicious logo images.

Hundreds of Windows and Linux computer models from virtually all hardware makers are vulnerable to a new attack that executes malicious firmware early in the boot-up sequence, a feat that allows infections that are nearly impossible to detect or remove using current defense mechanisms.

The attack—dubbed LogoFAIL by the researchers who devised it—is notable for the relative ease in carrying it out, the breadth of both consumer- and enterprise-grade models that are susceptible, and the high level of control it gains over them. In many cases, LogoFAIL can be remotely executed in post-exploit situations using techniques that can’t be spotted by traditional endpoint security products. And because exploits run during the earliest stages of the boot process, they are able to bypass a host of defenses, including the industry-wide Secure Boot, Intel’s Secure Boot, and similar protections from other companies that are devised to prevent so-called bootkit infections.

Game over for platform security

LogoFAIL is a constellation of two dozen newly discovered vulnerabilities that have lurked for years, if not decades, in Unified Extensible Firmware Interfaces responsible for booting modern devices that run Windows or Linux. The vulnerabilities are the product of almost a year’s worth of work by Binarly, a firm that helps customers identify and secure vulnerable firmware.

The vulnerabilities are the subject of a coordinated mass disclosure released Wednesday. The participating companies comprise nearly the entirety of the x64 and ARM CPU ecosystem, starting with UEFI suppliers AMI, Insyde, and Phoenix (sometimes still called IBVs or independent BIOS vendors); device manufacturers such as Lenovo, Dell, and HP; and the makers of the CPUs that go inside the devices, usually Intel, AMD or designers of ARM CPUs. The researchers unveiled the attack on Wednesday at the Black Hat Security Conference in London.

The affected parties are releasing advisories that disclose which of their products are vulnerable and where to obtain security patches. Links to advisories and a list of vulnerability designations appears at the end of this article.

As its name suggests, LogoFAIL involves logos, specifically those of the hardware seller that are displayed on the device screen early in the boot process, while the UEFI is still running. Image parsers in UEFIs from all three major IBVs are riddled with roughly a dozen critical vulnerabilities that have gone unnoticed until now. By replacing the legitimate logo images with identical-looking ones that have been specially crafted to exploit these bugs, LogoFAIL makes it possible to execute malicious code at the most sensitive stage of the boot process, which is known as DXE, short for Driver Execution Environment.

“Once arbitrary code execution is achieved during the DXE phase, it’s game over for platform security,” researchers from Binarly, the security firm that discovered the vulnerabilities, wrote in a whitepaper. “From this stage, we have full control over the memory and the disk of the target device, thus including the operating system that will be started.”

From there, LogoFAIL can deliver a second-stage payload that drops an executable onto the hard drive before the main OS has even started. The following video demonstrates a proof-of-concept exploit created by the researchers. The infected device—a Gen 2 Lenovo ThinkCentre M70s running an 11th-Gen Intel Core with a UEFI released in June—runs standard firmware defenses, including Secure Boot and Intel Boot Guard.

In an email, Binarly founder and CEO Alex Matrosov wrote:

LogoFAIL is a newly discovered set of high-impact security vulnerabilities affecting different image parsing libraries used in the system firmware by various vendors during the device boot process. These vulnerabilities are present in most cases inside reference code, impacting not a single vendor but the entire ecosystem across this code and device vendors where it is used. This attack can give a threat actor an advantage in bypassing most endpoint security solutions and delivering a stealth firmware bootkit that will persist in a firmware capsule with a modified logo image.

Hijacking the execution flow

There are several ways to exploit LogoFAIL. Remote attacks work by first exploiting an unpatched vulnerability in a browser, media player, or other app and using the administrative control gained to replace the legitimate logo image processed early in the boot process with an identical-looking one that exploits a parser flaw. The other way is to gain brief access to a vulnerable device while it’s unlocked and replace the legitimate image file with a malicious one.

In either case, the malicious logo causes the UEFI to execute attacker-created code during the all-important DXE phase each time the device boots. By executing code in this early stage, when most of the system initialization is performed, an exploit hijacks all execution flow that follows, allowing it to bypass security defenses such as Secure Boot and hardware-based verified boot mechanisms such as Intel Boot Guard, AMD Hardware-Validated Boot, or ARM TrustZone-based Secure Boot.

Depending on how the UEFI is configured, a simple copy/paste command, executed either by the malicious image or with physical access, is in many cases all that’s required to place the malicious image into what’s known as the ESP, short for EFI System Partition, a region of the hard drive that stores boot loaders, kernel images, and any device drivers, system utilities, or other data files needed before the main OS loads.

There are major benefits to this approach. One is that no executable code ever touches the hard drive, a technique known as fileless malware that hampers detection by antivirus and other types of endpoint protection software. Another benefit: Once the image is in place, it ensures a device remains infected even when an operating system is reinstalled or the main hard drive is replaced.

When UEFI-based system firmware is configured to use protections like Intel Boot Guard correctly with a non-modifiable logo, it’s not possible to drop the malicious image into the ESP. In many of these cases, however, it’s still possible to run a software tool freely available from the IBV or device vendor website that reflashes the firmware from the OS. To pass security checks, the tool installs the same cryptographically signed UEFI firmware already in use, with only the logo image, which doesn’t require a valid digital signature, changed. In many cases, the IBV tool is digitally signed, making it less likely that endpoint protections will intervene.

In Wednesday's presentation, the researchers provided the following image to illustrate how LogoFAIL attacks work.

In the whitepaper accompanying the presentation, the researchers wrote:

As it’s possible to see from the previous picture, a LogoFAIL attack can be divided in three different steps. First, the attacker prepares a malicious logo image and stores it into the ESP or inside an unsigned section of a firmware update, and it restarts the device. During the boot process, vulnerable firmware will load the malicious logo from the ESP and parse it with a vulnerable image parser, thus the attacker can hijack the execution flow by exploiting a vulnerability in the parser itself. By exploiting this threat, the attacker can achieve arbitrary code execution during the DXE phase, which means complete game-over for platform security.

In short, what is exactly the impact of our findings and what makes LogoFAIL so dangerous? As we can see in the previous picture:

LogoFAIL doesn’t require any physical access to the device. Since it can be done entirely from the operating system, it completely breaks any security boundary between the OS and firmware. Modern “below-the-OS” defenses, such as Secure Boot, are also completely ineffective at stopping this threat.

Attacks starting from the firmware level can be leveraged to install a bootkit and subvert any OS-level security mechanism, while remaining completely undetectable by security detection solutions.

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.

Is there a fuzzer in the house?

The researchers found the vulnerabilities by running the UEFI image parsers through a tool known as a fuzzer. Fuzzers are designed to identify programming bugs by executing small chunks of code over and over with small variations in the input each time. Each time there’s a crash, the fuzzer notes the memory address where it occurred and the input that triggered it. Further analysis using other tools and processes enabled researchers to isolate the bugs that allow the execution of arbitrary code or other types of vulnerabilities.

“When the campaign finished, we were overwhelmed by the amount of crashes we found, so much that triaging them manually was quite complicated,” the researchers wrote. In all, they identified 24 unique root causes, 13 of which they believe are exploitable.

The results raise a vexing question: If fuzzers identified so many exploitable vulnerabilities, why hadn’t the developers of the UEFIs (often called IBVs or independent BIOS vendors) and the OEMs selling the devices already used these tools and fixed the underlying bugs? The Binarly researchers continued:

This triaging process gave us a good understanding of the root causes behind these bugs. While they cover a wide range of software security problems, the underlying theme is a lack of validation on attacker-supplied data. For example, the first screenshot shows a bug in the BMP parser of AMI: the pointer called “Image” is initialized by adding to the image starting address (&Header->CharB) the header field “ImageOffset”. As this offset can be set arbitrarily by an attacker, the variable “Image” can be made to point almost anywhere in memory. The second screenshot is taken from the PNG parser of AMI and it doesn’t contain only one bug, but actually two. The first bug is a missing check on the return value of the “EfiLibAllocateZeroPool” function, which returns NULL on failure. The second bug is instead 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 will be used.

The results from our fuzzing campaign unequivocally say that none of these image parsers were ever tested by IBVs or OEMs. We can confidently say this because the fuzzer was able to find some crashes just after running for a few seconds and we found crashes in almost every parser we tested.

Because the image-parser vulnerabilities exploited by LogoFAIL reside in the UEFI, Macs, smartphones, and other devices that rely on alternative boot mechanisms aren’t affected. Interestingly, even when Apple relied on UEFI to boot an earlier generation of Macs that ran Intel CPUs, they still weren’t vulnerable to LogoFAIL. The reason: Apple hardcoded the image files into the UEFI, making it impossible to swap the legitimate one for a malicious lookalike. As a developer of both the hardware and software running Macs, Apple had that ability. The diversity of ecosystems revolving around Windows and Linux platforms requires more flexibility.

Many devices sold by Dell aren't directly exploitable because the image files are protected by Intel Boot Guard, making it impossible to be replaced, even during a physical attack. As a further measure, many Dell devices don't permit logo customization. While those designs effectively close off the LogoFAIL attack surface, Binarly recommends patching the high-severity image parsing vulnerabilities, "as they represent a hazard that could inadvertently turn into a security issue."

A brief history of firmware exploits

LogoFAIL builds off a large corpus of research conducted over more than a decade. Hijacking the boot sequence by exploiting image-parsing bugs in UEFIs was first demonstrated in a 2009 Black Hat presentation by researchers Rafal Wojtczuk and Alexander Tereshkin. Since then, there has been a steady stream of new discoveries provided in both follow-on research and, in a few cases, attacks found in the wild from real-world threat actors.

The first known case of a real-world attack harnessing the power of the UEFI came in 2018 with the discovery of malware dubbed LoJax. A repurposed version of legitimate anti-theft software known as LoJack, LoJax was created by the Kremlin-backed hacking group tracked under names including Sednit, Fancy Bear, and APT 28. The malware was installed remotely using malware tools that can read and overwrite parts of the UEFI firmware’s flash memory.

In 2020, researchers unearthed the second known instance of real-world malware attacking the UEFI. Each time an infected device rebooted, its UEFI checked if a malicious file was present inside the Windows startup folder and, if not, would install it. Researchers from Kaspersky, the security provider that discovered the malware and named it “MosaicRegressor," still don’t know how the UEFI came to be infected. One possibility is that the PCs received a fake UEFI update. Another possibility was gaining brief physical access to a device and using a specially designed USB drive to infect the UEFI.

Since then, a handful of new UEFI bootkits have come to light. They are tracked under names including ESpecter, FinSpy, and MoonBounce. In response to the threats, device makers started introducing measures to better lock down the UEFI boot process.

Key among the defenses is Secure Boot, an industry-wide standard that uses cryptographic signatures to ensure that each piece of software used during startup is trusted by a computer's manufacturer. Secure Boot is designed to create a chain of trust that prevents attackers from replacing the intended bootup firmware with malicious firmware. If a single link in the startup chain isn’t recognized, Secure Boot will prevent the device from starting.

Earlier this year, researchers from security firm ESET discovered the first known instance of UEFI malware that bypasses Secure Boot. The ability of the UEFI bootkit, which was dubbed Black Lotus, to defeat a security protection that had been in place for 12 years was impressive, but it suffered a key limitation—it could be killed by performing a simple reinstallation of the main operating system. LogoFAIL has no such limitation. As long as the malicious image is executed by the UEFI, the machine running the firmware will remain infected. The following image, shown earlier in this article, contrasts the differences between LogoFAIL and Black Lotus.

There’s no indication that LogoFAIL vulnerabilities have been actively exploited in the wild, but there’s also little way one would know, since infections are so hard to spot using traditional tools and methods. One clue of compromise, however, can be provided by examining the image file that’s parsed during bootup. If the cryptographic hash of that file differs from the hash of the file that device manufacturers typically make available for free, the device can be further analyzed to check for signs that it has been exploited.

LogoFAIL vulnerabilities are tracked under the following designations:

• CVE-2023-5058
• CVE-2023-39538
• CVE-2023-39539
• CVE-2023-40238

This list is currently incomplete. Advisories are available from roughly a dozen parties. A non-exhaustive list of companies releasing advisories includes AMI, Insyde, Phoenix, and Lenovo. The complete list wasn’t available at publication time. People who want to know if a specific device is vulnerable should check with the manufacturer.

The best way to prevent LogoFAIL attacks is to install the UEFI security updates that are being released as part of Wednesday’s coordinated disclosure process. Those patches will be distributed by the manufacturer of the device or the motherboard running inside the device. It’s also a good idea, when possible, to configure UEFIs to use multiple layers of defenses. Besides Secure Boot, this includes both Intel Boot Guard and, when available, Intel BIOS Guard. There are similar additional defenses available for devices running AMD or ARM CPUs.