UEFI Failing: What to Know About LogoFAIL Attacks
- Multiple UEFI vulnerabilities can lead to Linux, Windows, and Mac exploits
- LogoFAIL persists across operating system reinstallations
- It also extends the supply chain risks to the hardware itself
Security researchers, known for their inquisitive and unconventional methods, have recently scrutinized UEFI (Unified Extensible Firmware Interface), revealing significant vulnerabilities called LogoFAIL vulnerabilities. These experts, who investigate systems to uncover unusual ways to exploit them, discovered that UEFI, the modern replacement for traditional BIOS, is susceptible to certain failures – which have wide-ranging impacts.
Specifically, researchers found that the libraries used by various system integrators and vendors in their motherboards’ UEFI are vulnerable. These libraries can be manipulated to perform unforeseen operations through specially crafted images displayed during system boot-up, such as logos and banners. This manipulation effectively circumvents security features like Secure Boot, misleading the subsequent operating system.
So what dangers do LogoFAIL vulnerabilities pose, and what does this mean for you?
UEFI stands for Unified Extensible Firmware Interface, an advanced version of the old BIOS. It is essentially a compact operating system that manages hardware initialization and preliminary system security before transitioning control to the main operating system. UEFI oversees numerous functions, including CPU frequency, power and thermal management, memory timings, and peripheral operations. Some UEFI systems even offer network connectivity for firmware updates without an operating system being required.
Unlike BIOS, UEFI provides a consistent visual experience by displaying an image during boot-up, which remains visible throughout the UEFI initialization and into the operating system’s boot phase. This differs from BIOS, which typically involves screen resolution changes and text mode resets before operating system drivers are activated.
Fuzzing is a testing method employed by developers and IT professionals to evaluate software robustness. It involves sending a vast array of diverse and often random inputs to every possible application input field, option, and parameter. The goal is to ensure the application remains stable under unconventional input types, such as entering letters in numeric fields or inserting UTF16 characters in fields designed for UTF8, thereby exposing potential code weaknesses.
Binarly disclosed this family of vulnerabilities at BlackHat Europe recently, and it got some attention from cybersecurity professionals.
They’re called LogoFAIL vulnerabilities, and they arise from flaws in image parsing libraries embedded in UEFI system firmware. These libraries are used to display logos during the boot process or in BIOS setup.
The specific vulnerabilities identified include heap-based buffer overflow flaws and out-of-bounds reads. These vulnerabilities are triggered when a malicious logo image file is injected into the EFI system partition, leading to the execution of payloads that can hijack the boot process and bypass security mechanisms like Secure Boot and Intel Boot Guard.
It is important to note that, despite the hype, to exploit these vulnerabilities it is necessary to have access to the system in the first place, and in that access, to have privileges to write to the EFI partition and UEFI non-volatile ram (nvram). The keen-eyed reader will realize that, if you already have that level of access, then it’s not necessarily the LogoFAIL exploit itself that is the problem, but rather the persistence that it enables for other malware to abuse. Consider, for example, a ransomware that persists even system reimaging attempts after an infrastructure-wide attack. It would cripple recovery operations.
Adding insult to injury, the vulnerabilities exist across multiple platforms and architectures. It impacts both x86 and ARM-based devices. BIOS vendors like AMI, Phoenix, and others, create firmware that is affected by LogoFAIL. In turn, this makes motherboards using that firmware to also be affected by it – it doesn’t matter if server-grade or consumer-grade hardware, as the same BIOS vendors will provide software for all of them. Vendors like Intel, Dell, Supermicro, Acer, and many others are therefore affected.
Having code running before the operating system has a chance to even start loading and protecting against threats is an especially egregious threat. It doesn’t matter if your antivirus solution detects everything that is loaded if the threat is already running when the antivirus software starts to work.
When you have control over what is started so early in the process, then you can deploy preemptive software that stops operating-system-level protections from starting in the first place – effectively nullifying traditional endpoint security.
In fact, LogoFAIL can lead to attacks against any operating system – Linux, Windows, Mac or even more esoteric ones. It actually survives an operating system reinstall, so it is very resilient to removal attempts.
It’s not the first time that firmware has been considered as a persistent way to target a system, as the hard disk firmware exploit showed some years ago, but this is certainly the least-effort way of achieving this level of resiliency.
A Real-World Threat?
Things are not quite there yet. This may be another close call rather than the end-of-the-world scenario that has been painted all over industry news sites.
Affected vendors will have to release updated UEFI images, so firmware updates are required to effectively patch the impacted libraries that are behind the problem, but doing so will protect the system against this threat.
Assuming everyone patches every system, that is.
The researchers who discovered the problem did so by fuzzing the UEFI code, and they acknowledge that, so far, the risk is theoretical only.
By throwing large amounts of data to the libraries inside UEFI, it was possible to identify multiple new ways to cause those libraries to crash, triggering buffer overflows, out-of-bounds reads, null pointer dereference, and similar problems.
Different vendors will include different libraries with their firmware, supporting multiple image formats – JPEG, BMP, and older PCX and Targa (TGA) formats are supported. This enables hardware vendors to add custom images to their equipment to brand and differentiate it from other vendors.
It turns out that there is hardly any validation of the image data before being parsed for display, so it is relatively easy to create custom images that abuse this lack of checks to trigger the crashes at will, leaving the UEFI in a predictable state, where code can be deployed and tricked into running.
The Software Supply Chain
These findings highlight another dimension of software supply chain risks. Directly targeting hardware adds to the already complex array of threats affecting software supply chains, from developer tools to source code repositories.
The fact that a given workload is potentially affected by vulnerabilities all throughout this large dependency and environment chain is something that we seem to turn a blind eye to – either through a lack of awareness or an inability to effectively prevent it – but which doesn’t make it any more secure.