From Trust to Trouble: The Supply Chain Implications of a Broken DBX

Last week, researchers at ESET publicly documented CVE-2024-7344, a vulnerability that allows bypassing UEFI Secure Boot, a problem affecting the majority of UEFI-based systems and shines a spotlight on critical weaknesses in the system that’s supposed to protect how our computers start up.

In short, ESET researchers found a vulnerable UEFI application in-the-wild, developed by Howyar Technologies and signed with Microsoft’s third-party UEFI certificate. This is the same certificate used to sign the Linux first-stage bootloader shim and frequently found installed in devices. The signed application allows attackers to load and execute unsigned code, thus breaking the chain-of-trust that Secure Boot is designed to maintain. The use of third-party signed components in the UEFI ecosystem poses a similar problem to the BYOVD (Bring Your Own Vulnerable Driver) problem. The sheer diversity of those trusted components makes it difficult to maintain control of their trustworthiness.

UEFI Secure Boot was designed to handle this problem.  It contains a mechanism to block the execution of UEFI applications that are found to be vulnerable. This mechanism, known as the UEFI revocation list, is implemented through the dbx database, which contains a list of certificates, signatures and Authenticode hashes associated with known vulnerable drivers and bootloaders. For example, the infamous BlackLotus bootkit exploited Baton Drop (CVE-2022-21894), a vulnerability in the Windows UEFI bootloader, to bypass Secure Boot. In response, any bootloader vulnerable to Baton Drop was added to the UEFI revocation list, essentially mitigating this security issue. While dbx has its own sets of problems, it’s the only way to stop UEFI firmware from running vulnerable bootloaders.

In the last year, Binarly REsearch discovered PKfail, showing weak spots in trusting Secure Boot, specifically through the prism of the dbx security concept.

The aftermath of ESET’s findings were also similar: the Authenticode hashes of the vulnerable applications were added to the revocation list and distributed by Microsoft through an update.

In this blog we present a retrospective view on how updates to dbx were handled, both for this new CVE and in the past. We noticed several shortcomings around how these dbx updates are published and distributed across the ecosystem, effectively leaving users vulnerable to Secure Boot bypasses. The primary issue is that different parts of the ecosystem rely on different revocation lists: Microsoft releases dbx updates directly through the operating system, device vendors follow the list published on the UEFI Forum website, while Linux users receive updates via LVFS. When these lists are not kept synchronized, security vulnerabilities are inevitable.

In particular, we found that the once-“official” source of updates for dbx – the UEFI Forum website – has been distributing an outdated version of the dbx for the last six months. This version didn’t include any of the hashes related to CVE-2024-28924 (another Secure Boot bypass based on a module developed by SecurStar), leaving any system using this list open to Secure Boot bypasses.  

This is a summary timeline of events discussed in this blog post:

• 2023-05-09: Microsoft and the UEFI Forum publish an updated dbx to stop Black Lotus (dbx “version 371”)
• 2023-05-09: LVFS begins distributing the updated dbx to protect impacted users  
• 2024-07-17: Microsoft publishes the DBX2024 update packages, with modules related to CVE-2024-28924 (SecureStar) 
• 2025-01-06: Microsoft updates dbx CSV file with hashes of modules related to CVE-2024-7344 (Howyar)
• 2025-01-14: Microsoft releases security bulletin with CVE-2024-7344, CERT/CC releases VU#529659
• 2025-01-16: ESET publicly disclose CVE-2024-7344
• 2025-01-17: The UEFI forum website (incorrectly) reports it is distributing dbx files to protect against CVE-2024-7344   
• 2025-01-17: Microsoft releases signed dbx updates for CVE-2024-7344 which are eventually (correctly) distributed on the UEFI Forum website.

Broken Trust: Examining the UEFI Forum’s Revocation List

Ideally, the revocation of an application that can be leveraged to bypass Secure Boot should be publicly documented and included in a central repository of known vulnerable applications. This approach would provide the entire UEFI ecosystem with a single authoritative source of truth.  This source of truth used to be the list published on the UEFI Forum website. 

When we started working on this REsearch (on Friday, January 17, 2025), the UEFI forum webpage stated that “The x86 and x64 files were updated January 14, 2025” to address ESET’s findings.  However, we discovered that this didn’t match with reality. The x86 and x64 binary dbx files, as well as the informational CSV file, contained no references to the vulnerable applications identified by ESET.

Not only that, a closer examination on the contents of the CSV file and the binary files containing the dbx data revealed more discrepancies:

1. The CSV file was missing some entries that were present in the binary files. 
2. The CSV file included some entries that were missing in the binary files.

The first discrepancy is primarily a “documentation” issue, making it harder to trace a specific hash to its associated security issue or CVE. However, the second discrepancy could instead represent a security issue, as the dbx binary file is what’s finally installed and used by UEFI firmware to determine whether a module should be executed. Fortunately, this was not the case, as we confirmed that one hash (“5C39F0E5..”) was included in the CSV by mistake, while the other three (e.g., “7EAC80A..”) are related to unsigned modules, raising questions about why they were included in the CSV in the first place.  

The situation eventually revolved on Saturday, January 18, 2025. Around 7:00pm UTC we noticed that the files on the UEFI Forum website were updated to reflect the disclosure of CVE-2024-7344. 

This is not the first time that the UEFI Forum has made an error regarding the revocation list. In 2023, ESET discovered that in 2022 the UEFI Forum mistakenly added the SHA256 hashes of two vulnerable drivers, instead of their Authenticode hash – which is what is computed to verify an image during boot. This oversight left the doors wide open for known Secure Boot bypasses for more than a year.

These discrepancies add unnecessary confusion to an issue that is already complex and not always well understood within the ecosystem, yet remains crucial for ensuring computer systems are booted securely.

A Divergence in UEFI Revocation Lists

Going back to the recently discovered CVE-2024-7344, references to ESET’s findings were firstly added in a second, parallel revocation list maintained by Microsoft. Ideally, this list should have always been aligned with the “official” UEFI Forum list, but in reality we found that they diverged: before Saturday 18th, Microsoft’s revocation list contained 643 entries, while the official UEFI Forum binaries included only 596 entries. The following table shows some of the differences between the Microsoft CSV information and the UEFI Forum “version 371” list. 

‍

The lists diverged in July 2024. On this date, Microsoft published the DBX2024 update packages, with hashes related to CVE-2024-28924 (SecurStar) and to CVE-2024-23593 (LenovoBT.efi), but the UEFI Forum never picked up this update.

To investigate this divergence further, we searched online for any of the modules from Table 1, as they could potentially be used to bypass Secure Boot on devices that rely solely on the UEFI Forum list.  We confirmed that at least one of these modules is a UEFI shell signed with the Microsoft UEFI CA certificate, that enables the execution of untrusted code even with Secure Boot enabled. These vulnerable modules are cross-platform and they could be leveraged to attack any operating system, since they run before the OS is even started. 

The divergence between lists meant that any downstream user in the ecosystem that relied on the UEFI Forum list did not actually revoke modules that were publicly known to be vulnerable. For example, LVFS represents the source of truth for the Linux ecosystem, as most Linux devices receive dbx updates through LVFS. However, since the latest version of dbx available on LVFS was version 371, Linux systems remained vulnerable to publicly-known Secure Boot bypasses from at least July 2024 to January 2025. 

As of January 21, 2025, we confirm that the contents of the revocation list shared by Microsoft and on the UEFI Forum website and on LVFS, all match. This means that downstream users of these lists are protected against known threats, however, given all the above confusion, we suggest double-checking that the downloaded dbx corresponds to the most updated version.

Microsoft's revocation information also contains several inconsistencies. First, the DBX2024 update packages included the revocation information of CVE-2024-28924 and CVE-2024-23593 in the CSV file but not in the binary dbx. Additionally, the current version of the CSV – now converted to JSON – and dbx files contains mismatched architecture information. Some entries report one architecture in the CSV but have their signatures included in the dbx update for a different architecture. For example, the entry shown in this screenshot is included as part of the x86 revocation list in the JSON, but the hash is only included as part of the dbx update for ARM.

In total, we identified 61 instances of inconsistencies, which are all related to some of the earliest revocations from 2018. While they do not pose a security risk, they represent another example of how the revocation process must be improved.

UEFI Ecosystem vs. DBX

Updates to the dbx generally come from the operating system. For example, Microsoft’s KEK certificate is installed by default on most devices—99% of the firmware analysed in this experiment have it—allowing Microsoft to sign and deliver dbx updates. However, UEFI firmware images themselves should ideally contain the most up-to-date version of dbx. This is the only way to ensure that end-users are protected from Secure Boot bypasses, even in the absence of OS-level updates.    

To understand whether device vendors ship firmware images containing outdated dbx databases, we analyzed more than 5,000 recently released firmware images. This dataset, containing firmware from nearly all major device vendors, provides a representative view of the UEFI ecosystem. All firmware was uploaded to the Binarly Transparency Platform, which automatically identifies missing hashes and outdated dbx contained in the uploaded firmware.

The results from this scan revealed that almost 60% of firmware contains an outdated dbx database. In many cases, firmware images were missing hundreds of hashes. The end result doesn’t change, since even a single missing hash is enough to leave end-users vulnerable to exploits targeting Secure Boot.

Lifting the Embargo

On January 6th, 2025, Microsoft updated the public GitHub repository microsoft/secureboot_objects with information regarding Howyar Technologies' Reloader.efi file. This update potentially alerted any attackers monitoring the repository to a possible Secure Boot bypass. However, the public disclosure and the dbx update were not released until a week later on January 17, giving attackers a window of opportunity to act. When lifting an embargo on impactful vulnerabilities such as the one reported by ESET, it’s crucial to ensure that all resources are updated simultaneously, so that impacted systems can be quickly protected.

Conclusions

The UEFI Secure Boot process is a strong yet-delicate security feature and the dbx plays an important role in maintaining the trust: missing even a single hash in this database can completely undermine Secure Boot. Given the discrepancies we found between different revocation lists and their textual and binary content, we recommend bringing more transparency around the revocation process. This can be achieved by publicly documenting, in a standardized format, the binaries included and the specific security reasons for their inclusion. 

Different players in the UEFI industry rely on various sources for their dbx updates: Microsoft releases dbx updates directly through the operating system, device vendors follow the list published on the UEFI Forum website, and Linux users receive updates via LVFS. This fragmentation, with multiple unsynchronized sources, creates a lack of consensus across the ecosystem on what should be trusted and what should be revoked, which could lead to the security issues discussed in the blog. 

For these reasons, we strongly urge the UEFI ecosystem to establish a single, authoritative source of truth for these revocation lists. Such a unified approach would allow the ecosystem to periodically check for updates and ensure that end users are protected from firmware-level threats.

‍

‍