Software Engineering Institute

Overview

UEFI firmware applications DTBios and BiosFlashShell from DTResearch contain a vulnerability that allows Secure Boot to be bypassed using a specially crafted NVRAM variable. The vulnerability stems from improper handling of a runtime NVRAM variable that enables an arbitrary write primitive, capable of modifying critical firmware structures, including the global Security2 Architectural Protocol used for Secure Boot verification.. Because the affected applications are signed by the Microsoft UEFI Certificate Authority, this vulnerability can be exploited on any UEFI-compliant system, allowing unsigned code to run during the boot process.

Description

Unified Extensible Firmware Interface (UEFI) defines a modern firmware architecture that facilitates interaction between a computer’s hardware and its operating system during early boot. When a UEFI-compliant system starts, UEFI applications and drivers are executed to initialize the system and hand off control to the operating system (OS) loader. These UEFI applications must be signed and verified for execution under Secure Boot. These signatures can originate from the OEM or from entries in the system’s signature database (DB), which commonly includes the Microsoft UEFI Certificate Authority (CA).

UEFI defines extensible NVRAM variables that store configuration, device customization, and runtime context shared across UEFI applications and the operating system. A vulnerability was identified in a Microsoft-signed UEFI application that uses the NVRAM variable IhisiParamBuffer as a pointer for memory operations, including overwriting the critical global security parameter gSecurity2 . This allows bypassing Security2 Architectural Protocol-based verification , enabling the execution of any unsigned UEFI binaries irresepective of UEFI Secure Boot settings.

In some implementations, IhisiParamBuffer is locked early during boot, preventing modification at runtime. However, as Binarly observed, the vulnerability can be exploited in environments where the IhisiParamBuffer NVRAM variable is not locked and remains writable at runtime. In such cases, attackers can bring and execute the vulnerable UEFI application even on systems with Secure Boot enabled—using a Bring Your Own Vulnerable Driver (BYOVD) approach. Initially the vulnerability was reported on DTResearch's Dtbios application version 71.22 for 64-bit architecture, however Microsoft has further identified that this vulnerability is present in both DtBios and BiosFlashShell on multiple versions. A total of 14 hashes have been added to the Forbidden Signature Database (DBX or Revocation List) to address these various binaries.

To mitigate this vulnerability, affected UEFI modules must be updated via vendor-provided software. Additionally, all UEFI-compliant system owners should update their Secure Boot Forbidden Signature Database (DBX or Revocation List), which is available via OEM updates, Microsoft, or the Linux Vendor Firmware Service (LVFS).

Impact

An attacker with the ability to modify the IhisiParamBuffer NVRAM variable can use it to perform arbitrary memory writes, enabling a Secure Boot bypass during early boot. This allows unsigned or malicious code to run before the OS loads, potentially installing persistent malware or kernel rootkits that survive reboots and OS reinstallations. Because this attack occurs before OS-level security tools initialize, it can evade detection by endpoint detection and response (EDR) systems. In some cases, it can even entirely disable EDR systems by modifying low-level interfaces before they load.

Solution

Apply a Patch

Multiple vendors have released software updates to address this vulnerability and prevent potential exploitation. Please refer to the Vendor Information section for applicable updates. Microsoft has also indicated they will release an updated DBX (Revocation List) file to prevent vulnerable components from being executed under Secure Boot. Windows Users can further use Check-UEFISecureBootVariables PowerShell scripts to verify whether the latest DBX updates can be applied. For Linux users, LVFS has released a blog article to detail revocation list updates through the Linux tools provided by the fwupd project.

Recommendations for Enterprises and Developers

Changes to the DBX (Forbidden Signature Database) may cause system boot failures if not carefully managed. Vendors should thoroughly test updates to ensure system stability. In some cases, it may be necessary to update the DB (Signature Database) before updating the DBX, as described in Microsoft’s KB5025885. Enterprises and cloud providers managing broad deployments of systems should prioritize these updates and confirm DBX revocation is enforced, particularly in virtualized environments, to block unauthorized UEFI binaries during early boot phases.

Acknowledgements

Thanks to Binarly REsearch team for the responsible disclosure of this vulnerability to CERT/CC. Thanks also to Microsoft and various vendors for their collaboration and timely response. This document was written by Vijay Sarvepalli.

Vendor Information

References

• https://www.binarly.io/advisories/brly-dva-2025-001
• https://uefi.org/specs/UEFI/2.10/32_Secure_Boot_and_Driver_Signing.html
• https://techcommunity.microsoft.com/blog/windows-itpro-blog/revoking-vulnerable-windows-boot-managers/4121735
• https://kb.cert.org/vuls/id/529659
• https://insights.sei.cmu.edu/blog/uefi-5-recommendations-for-securing-restoring-trust/