.webp)
When Binarly discovered the LogoFAIL set of vulnerabilities last year (reported on July 7, 2023) and worked with CERT/CC (VU#811862) to notify affected vendors, we didn't anticipate the enormous challenge it would pose for the industry. Coordinating the disclosure process with CERT/CC for a substantial number of impacted entities revealed the unforeseen complexity and magnitude of LogoFail's impact. [Download Full Report]
LogoFAIL affects both x86 and ARM-based ecosystems because the vulnerable code lacks silicon-specific dependencies and can be recompiled for ARM. This makes LogoFAIL a notable example of a cross-silicon vulnerability, though the specifics of exploitation vary by ecosystem.
The assumption was that the fixes would be applied to the reference code, such as EDK and IBVs, and would then be consumed by downstream device vendors and OEMs. However, in reality, the situation is far more complex where LogoFAIL exposed the intricacies and negative effects to the entire firmware supply chain.
After the disclosure, we notified all parties over CERT/CC VINCE about CVEs confusions where the number of vulnerabilities didn’t match the number of assigned CVEs, warning that this really played a negative role in the adoption of the security fixes.
Technically, if you fix a vulnerability, the fix matches the CVE but in reality, not all the security issues related to LogoFAIL can be thoroughly fixed.
The Binarly Transparency Platform detects unfixed devices daily and almost every device still contains a few unfixed vulnerabilities related to LogoFAIL.
In this follow-up research, we dive deeper into the shallow waters of the firmware supply chain confusion and the blind trust in the reference code and firmware developers when we assume everything is fixed so many months after disclosure.
In reality, LogoFAIL is still a concerning issue for the entire firmware ecosystem. The figure below shows how the accumulation of dependencies from multiple layers of the software supply chain disproportionately increases complexity of this vulnerability on the firmware side. When the firmware code is delivered to the device, it consumes all upper supply chain layers with all the applied implications.
Fixing these types of issues requires embedding a certain degree of transparency into all the layers of the software supply chain, specifically when it comes to protecting the foundation of platform security tied to device and firmware security layers.
The sad reality is that IBVs continue to play the “security by obscurity” game. The industry has learned multiple times that obscurity doesn’t benefit security. Still, in this case, the obscurity is related to the business model of IBVs that monopolize the market and dictate the rules of transparency, including the vulnerability disclosure process and details provided to NVD.
NOTE: A few weeks ago at the IEEE Security & Privacy: Tenth LangSec Workshop, the Binarly team received an award for “The hardest to fix parser bug” for the discovery of the LogoFAIL. This award reflects the complexity of the problem, which is still impacting the firmware ecosystem.
Today, Binarly REsearch releases all 30+ LogoFAIL advisories to the public. You can find them on our advisories page ranging from BRLY-2024-001 through BRLY-2024-030.
We are concerned about the number of unfixed devices remaining in the field. Unfortunately, IBVs like AMI and Insyde assign only one CVE to multiple advisories, and vulnerabilities have been shared with them during the disclosure process. The Binarly team raised concerns multiple times regarding the transparency and the need to assign more CVE IDs to the different instances of LogoFAIL vulnerabilities, but our efforts did not change the minds of AMI and Insyde which perpetuated impact to downstream device vendors.
Most firmware security solutions focus on validating the integrity or checking the hashes of the patched components. As we can see, 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.
The issue with validating firmware integrity or checking the hashes of the patched components to compare is that both integrity and hash-based reputation databases are based on the absolute trust of the vendor information regarding fixed vulnerabilities. The Binarly team has proved multiple times that vendors can hide or give incomplete information or sometimes evade delivering fixes to all of the reported problems, which would still not remediate the security risks. LogoFail is no exception, and our study shows that we need to change how we validate the risks associated with high-impact vulnerabilities.
At Binarly, we do not trust information from external resources, including vendor-associated advisories. To cut through the noise and see the truth, everything should be validated and guided by data points associated with code-guided detections.
When Binarly REsearch reported LogoFAIL, we proposed a quick fix for enterprise device vendors: lock the logo image by the device manufacturer. The most immediate and obvious way to fix LogoFAIL is to disable logo customization: if the image parser used by UEFI firmware cannot be reached with untrusted images, then an attacker cannot exploit the vulnerabilities lingering in the parser itself.
We then revisited the original LogoFAIL advisories shared with IBVs and device vendors, downloading the updated firmware for each affected device. Notably, every firmware update specifically mentioned in its changelog that it had been patched against LogoFAIL.
As shown in the previous image, none of the affected vendors decided to remove the logo customization functionality, a decision that would effectively mitigate LogoFAIL. Disabling logo customization should only be treated as a first emergency response not as a long term solution. Confirmed security vulnerabilities must be properly addressed, either by fixing the underlying software bug or by completely removing the offending code.
The Binarly team has been reviewing the fixes through our Binarly Transparency Platform, where only after six months could we see the reference code coming from IBVs is more or less fixed. Only one IBV vendor had properly fixed the issue at the date of the disclosure, and it was Phoenix Technologies.
Insyde and AMI appeared to be completely unprepared for the LogoFAIL disclosure on the Black Hat EU presentation date, despite participating in a five-months-long coordinated disclosure process. As shown in the figure below, the situation slightly changed at the end of January 2024, one month after the disclosure.
Six months after the official disclosure date, we can confirm that the situation with IBVs has improved. However, the major challenge is not to fix the reference code but to deliver these fixes to the downstream vendors.
The lack of CVEs for each particular vulnerability reported for LogoFAIL vulnerabilities plays a really negative role, leading to device vendors and OEMs fixing only the issue related to specific CVE but forgetting about the rest. Legacy solutions that focus on integrity validation or black/whitelisting the hashes of the software components will be unable to show any signals related to the missing fixes and vulnerabilities present in the code. The figure below perfectly exposes this situation, which shows the recent snapshot of LogoFAIL detections on recent firmware images from enterprise device vendors.
.jpeg)
LogoFAIL example shows how the obscurity of the firmware supply chain plays a negative role in ecosystem security. A great example of the value of the transparency of the supply chain was XZ backdoor when, in a few days, by the entire industry effort, it was exposed and terminated to reduce the ecosystem exposure. When on the firmware supply chain, every layer belongs to a different vendor and introduces its obscurity layer of the supply chain. As an industry, we need to seriously rethink our trust in firmware since the available information about vulnerabilities and fixes is often incomplete and misleading.
In modern software ecosystems, the diversity of compilers and binary artifacts created by different runtime environments could lead to significant alert fatigue and heavy false positives when it comes to legacy methods for component identification or vulnerable version detection. When we started Binarly, we knew such approaches didn’t work by design in the modern software ecosystem. That’s the main reason we decided to focus on code-driven intelligence, which exposes known and unknown binary code risks.
Binarly Transparency Platform v2.0 not only identifies the variants of the LogoFAIL vulnerabilities, but it also delivers actionable and data-driven detection insights for security teams and software developers to help reduce the latency in reacting to problems and the costs of fixing them. The figure below shows the detection of one of the variants BRLY-LOGOFAIL-2023-24 of the high-impact LogoFAIL vulnerability. All the variants have been reported but are still heavily exposed on enterprise devices across the industry.
As we can see from the vulnerable code primitive in the figure below, the GIF parser in AMI firmware uses a statically allocated array called g_code_table to decode the GIF image data. However, this array is used without bounds checking, thus allowing the attacker to trigger an overflow of global data. The lack of validation on the output buffer leads to out-of-bound write (CWE-787) operations controllable by the attacker during GIF file processing in AMI firmware.
The Binarly Transparency Platform detects the BRLY-LOGOFAIL-2023-24 vulnerability (same as on the previous figure from IDA) and provide the pseudocode context to help with code-driven explainability about the discovered problem.
The original IBV fix for BRLY-LOGOFAIL-2023-24 is shown in the figure below, but as we can see, these fixes for the GIF image parser vulnerability are still not present on many enterprise devices. The fix itself is straightforward and validates the boundaries for the array index to prevent out-of-bounds write behavior.
The Binary Risk Intelligence technology provides capabilities not only for detecting vulnerabilities but also for validating fixes in the code based on our driven code detection rules. This unique approach allows us to provide confidence regarding not only the presence of vulnerable code patterns but also validate the effectiveness of the fix and its availability.
Want to be the first to hear about Binarly's REsearch? Sign-up for our newsletter "The Binarly Bulletin" by providing your email below.
.svg)
