A vulnerability in UEFI firmware applications DTBios and BiosFlashShell from DTResearch allows Secure Boot to be bypassed using a specially crafted NVRAM variable. The vulnerability stems from improper handling of a runtime NVRAM variable, enabling an arbitrary write primitive to modify 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. The 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 regardless of UEFI Secure Boot settings. The vulnerability can be exploited in environments where the IhisiParamBuffer NVRAM variable is not locked and remains writable at runtime. To mitigate this vulnerability, affected UEFI modules must be updated via vendor-provided software, and all UEFI-compliant system owners should update their Secure Boot Forbidden Signature Database. 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.
kb.cert.org
kb.cert.org
Create attached notes ...