Vendor-Signed UEFI Apps Open Secure Boot to BYOVD Bypass

Eleven vendor-signed UEFI applications from Acer, AMD, ASUS, GIGABYTE, Toshiba, and others ship with a built-in bypass of Secure Boot. ESET researchers found that these binaries expose functions like mm, dmpstore, and setvar without proper access control, letting an attacker with admin or physical access run arbitrary code during the pre-boot phase.

The Vulnerability: Signed but Not Safe

Secure Boot relies on a chain of trust: every UEFI driver or application must carry a valid signature from a certificate in the authorized database (DB). The affected binaries are legitimately signed by their vendors. That signature is the problem. Once the system trusts the vendor certificate, an attacker can load the signed vulnerable binary and use its memory manipulation (mm), NVRAM variable storage (dmpstore), or driver loading capabilities to bypass Secure Boot entirely. This is a classic "Bring Your Own Vulnerable Driver" (BYOVD) attack, moved from the OS kernel into firmware.

ESET identified specific vulnerable combinations of vendor, application, and Authenticode hash. For example, an Acer-signed GRUB2 module (hash 71DCE405964C67779DB92DBC01F683D6E29075AB) and multiple UEFI shell binaries from Acer, AMD, ASUS, ECS, Getac, GIGABYTE, Toshiba, and Uniwill. The full table in the CERT advisory lists SHA1 and SHA256 hashes for each impacted binary.

Impact: Pre-Boot Persistence That EDR Cannot See

Code executed in the UEFI boot phase runs before the OS kernel, before endpoint detection and response (EDR) agents initialize. Malicious payloads loaded at this stage can install persistent bootkits, modify firmware variables, or load unsigned kernel components that survive OS reinstalls. Standard security tools have zero visibility into this environment. An attacker who hits one of these signed binaries gains a foothold that evades all software-based detection.

Only systems where the affected vendor's certificate resides in the UEFI DB are vulnerable. That covers many enterprise and consumer devices from major OEMs. Administrative privileges or physical access is required, but once obtained, the bypass is trivial to execute.

Fix: Revoke the Binaries in DBX

The mitigation is not a firmware update that patches the vulnerable binaries themselves. Instead, vendors will push updates to the UEFI Forbidden Signature Database (DBX), adding the affected Authenticode hashes to a revocation list. Once the DBX is updated, these binaries cannot execute, even if signed. Administrators should apply the latest firmware and DBX updates from their hardware vendor immediately.

CERT/CC coordinated disclosure with impacted vendors, and the advisory points to Microsoft's OEM Secure Boot documentation for implementation guidance. ESET's full research, including CVE-2024-7344, provides deeper technical detail on the attack surface.

If your vendor has not shipped a DBX update yet, make them prioritize it. This is not a theoretical attack - the signed binaries are already in the wild, and the exploit path is well-documented.

Source: VU#457458: Vendor-signed UEFI applications found vulnerable to Secure Boot bypass
Domain: kb.cert.org