Trusted Apps Sneak a Bug Into the UEFI Boot Process

Source: Ognyan Yosifov via Alamy Stock Photo

A vulnerability in trusted system recovery programs could allow privileged attackers to inject malware directly into the system startup process in Unified Extensible Firmware Interface (UEFI) devices.

Seven real-time recovery products — Howyar SysReturn, Greenware GreenGuard, Radix SmartRecovery, Sanfong EZ-back System, WASAY eRecoveryRX, CES NeoImpact, and SignalComputer HDD King — all make use of “reloader.efi,” the Microsoft-signed Extensible Firmware Interface (EFI) file at issue.

The problem, ESET explains in a new report, is that reloader.efi uses a custom loader that enables the application to load even unsigned binaries during the boot process. In essence, it’s a backdoor for sneaking any kind of file into a system’s startup, past UEFI Secure Boot. The issue has been assigned CVE-2024-7344, and earned a “medium” 6.5 Common Vulnerability Scoring System (CVSS) rating, as it requires administrator privileges to exploit.

Backdoor to the UEFI Boot Process

The standard way to load, prepare, and execute UEFI images in system memory is with the autological LoadImage and StartImage functions. The Microsoft-approved “reloader” application goes its own way, using a custom mechanism that allows it to load any binary, trusted or otherwise, at startup.

“Maybe it’s a lack of secure coding awareness,” Martin Smolár, malware researcher at ESET, guesses of the developers’ motives in implementing the custom loader. “Or maybe it’s because they found it convenient to create such a functionality. Because when a developer makes a change [to a signed program] they need to send it to Microsoft to get it re-signed. This means that they don’t need to every time they create a new update or something like that.”

Reloader.efi loads arbitrary binaries from a specific, encrypted file, “cloak.dat.” When ESET decrypted cloak.dat, it found that it contained an unsigned executable primarily designed for classroom environments. “Its core function is to provide real-time system recovery, ensuring that students from different classes can work in a teacher-predefined computer environment within shared computer labs,” Smolár says, though he adds that the same component might be used in other settings, like public Internet cafes. The larger point is that the unsigned executable is run during the startup process, completely bypassing UEFI Secure Boot checks.

This odd classroom recovery software is perfectly honest, but an attacker could easily swap it out for something worse. If they could just get a hold of administrator privileges on a targeted machine, an attacker could access the EFI system partition (ESP) and substitute their own malicious file in place of cloak.dat. Then all they’d need is a quick system reboot to drop any malicious file they wished into the startup process.

Why UEFI Bugs Are So Bad

UEFI is a kind of sacred space — a bridge between firmware and operating system, allowing a machine to boot up in the first place.

Any malware that invades this space will earn a dogged persistence through reboots, by reserving its own spot in the startup process. Security programs have a harder time detecting malware at such a low level of the system. Even more importantly, by loading first, UEFI malware will simply have a head start over those security checks that it aims to avoid. Malware authors take advantage of this order of operations by designing UEFI bootkits that can hook into security protocols, and undermine critical security mechanisms like UEFI Secure Boot or HVCI (Hypervisor-Protected Code Integrity), Windows’ technology for blocking unsigned code in the kernel.

To ensure that none of this can happen, the UEFI Boot Manager verifies every boot application binary against two lists: “db,” which includes all signed and trusted programs, and “dbx,” including all forbidden programs. But when a vulnerable binary is signed by Microsoft, the matter is moot.

Microsoft maintains a list of requirements for signing UEFI binaries, but the process is a bit obscure, Smolár says. “I don’t know if it involves only running through this list of requirements, or if there are some other activities involved, like manual binary reviews where they look for not necessarily malicious, but insecure behavior,” he says.

Microsoft has previously alluded to UEFI binaries being “approved through manual review.” In response to an inquiry from Dark Reading, a Microsoft spokesperson provided the following clarification:

“Our process is designed to meet the evolving standard for analysis of third-party binary code, while ensuring effective scalability across our vast ecosystem. It begins with vetting and analysis with the partner, understanding the components they are requesting to be signed, and aspects of the design and functionality that may require additional security measures. Submissions are run through automated security analysis and are manually reviewed through a rigorous process. As a result, we may require additional security reviews, investigations with the submitting partner, or other mitigations. We remain committed to evolving our vetting process to better the security of our ecosystem as we operate within this ever-changing threat landscape.”

ESET first discovered CVE-2024-7344 in July 2024. Since then, all vulnerable applications have been fixed, and Microsoft revoked the old, vulnerable binaries in its Jan. 14, 2025, Patch Tuesday update.

About the Author

Nate Nelson is a writer based in New York City. He formerly worked as a reporter at Threatpost, and wrote “Malicious Life,” an award-winning Top 20 tech podcast on Apple and Spotify. Outside of Dark Reading, he also co-hosts “The Industrial Security Podcast.”