.webp)
The 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.
History frequently repeats itself, and vulnerability research is no exception. 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. Today, the UEFI system firmware contains BMP, GIF, JPEG, PCX, and TGA parsers, significantly increasing the attack surface compared to previous research that has been done in this area.
The most famous attack was presented at Black Hat USA in 2009 by Rafal Wojtczuk and Alexander Tereshkin with the exploitation of a BMP parser bug in the UEFI reference code.
Slide from the original Wojtczuk/Tereshkin presentation "Attacking Intel BIOS"
Since then, we haven’t seen any public documentation of attack surfaces related to graphic image parsers embedded into the UEFI system firmware until a member of our research team had an 'a-ha' moment when thinking of supply chain security problems from our previous work "OpenSSL Usage in UEFI Firmware Exposes Weakness in SBOMs".
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?
We dive deeper into this wormhole and are shocked by multiple high-impact discoveries that can be used by threat actors to deliver a malicious payload and bypass Secure Boot, Intel Boot Guard, and other security technologies by design. More importantly, it can open doors for attackers to bypass modern endpoint security solutions and should be considered much more powerful than the recent BlackLotus bootkit.
The full technical details regarding LogoFAIL vulnerabilities are under embargo until December 6th. Binarly researchers will present "LogoFAIL: Security Implications of Image Parsing During System Boot" at Black Hat Europe.
LogoFAIL is a newly discovered set of 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 IBVs (Independent BIOS vendor) reverence code, impacting not a single vendor but the entire ecosystem across this reference code and device vendors where it is used (See "The Firmware Supply-Chain Security is Broken: Can we fix it?").
One of the most important discoveries is that LogoFAIL is not silicon-specific and can impact x86 and ARM-based devices. LogoFAIL is UEFI and IBV-specific because of the specifics of vulnerable image parsers that have been used. That shows a much broader impact from the perspective of the discoveries that will be presented on Dec 6th.
The impact on the entire UEFI ecosystem is illustrated in the figure below.
Originally, we discovered LogoFAIL on Lenovo devices with Insyde, AMI, and Phoenix reference codes on board and reported these vulnerabilities under advisory BRLY-2023-006.
We have been heavily focused on reporting vulnerabilities mainly discovered by the Binarly Transparency Platform product but the work on LogoFAIL was different and originally initiated as a small research project just for fun. After demonstrating a massive number of interesting attack surfaces from image-parsing firmware components, the project grew into a massive industry-wide disclosure. Initial vulnerabilities were found by fuzzing the potentially vulnerable components after we did a preliminary static analysis of the concerning code flows in IDA with the help of efiXplorer plugin to bring UEFI context.
After initial fuzzing, we received so many crashes that triaging them manually was quite complicated. We decided to automate triaging with Binarly's internal program analysis framework, which empowers our products and supports instrumentation with emulation.
Later, we found more vulnerabilities in Insyde code and reported them with the BRLY-2022-018 advisory. After the realization that the impact goes way beyond Lenovo devices, we reported LogoFAIL-related security issues to the CERT/CC VINCE system. Based on previous experience, this coordination is very useful for the industry-wide response to cross-vendor issues.
The vulnerabilities allow attackers to store malicious logo images either on the EFI System Partition (ESP) or inside unsigned sections of a firmware update. When these images are parsed during boot, the vulnerability can be triggered and an attacker-controlled payload can arbitrarily be executed to hijack the execution flow and bypass security features like Secure Boot, including hardware-based Verified Boot mechanisms (like Intel Boot Guard, AMD Hardware-Validated Boot or ARM TrustZone-based Secure Boot).
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.
The full technical details regarding LogoFAIL vulnerabilities are under embargo until December 6th, when it will be presented "LogoFAIL: Security Implications of Image Parsing During System Boot" at Black Hat Europe.
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.
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.
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.
We can see from the figure above that any compromised signed UEFI component can break secure boot integrity and bypass it without being detected by platform integrity or Secure Boot related mitigations. Existing device security measurements can effectively detect other threats from the comparison table.
During our presentation at Black Hat Europe on December 6th, Binarly REsearch team will demonstrate new heap exploitation techniques to trigger LogoFAIL vulnerability that leads to arbitrary code execution.
Hundreds of consumer and enterprise-grade devices from various vendors, including Intel, Acer, and Lenovo, are potentially vulnerable. The exact list of affected devices is still being determined but it’s crucial to note that all three major IBVs are impacted -- AMI, Insyde, and Phoenix due to multiple security issues related to image parsers they are shipping as a part of their firmware.
Based on this reference code impact, we estimate LogoFAIL impacts almost any device powered by these vendors in one way or another. Also, it’s not limited to specific hardware and can be successfully exploited on x86 or ARM-based devices.
The types -- and sheer volume -- of security vulnerabilities discovered by Binarly show pure product security maturity and code quality in general on IBVs reference code. Most of these companies grew up in the early 90s. They never change their mindset, being more proactive than reactive and fixing only known problems without addressing complete attack surfaces or implementing effective mitigations.
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.
Our unique binary code analysis technology identifies vulnerable components not based on integrity or simple version checking to scope the problems. All Binarly detection works on the binary code and shows the problem proven to be present in the analyzed firmware, dramatically reducing the false positives and making an actionable incident response possible.
Are you interested in learning more about Binarly Transparency Platform or other solutions? Don't hesitate to contact us at [email protected].
.svg)
