# Vulnerability in Secure Boot: How a File Survived Microsoft’s Internal Review and Endangered Devices
For more than seven months—and possibly longer—a significant vulnerability within the Secure Boot framework, an essential element of contemporary device security, rendered Windows systems vulnerable to firmware attacks. This defect, designated CVE-2024-7344, underscores the difficulties in sustaining strong security within a progressively intricate digital landscape. Although Microsoft has recently remedied the issue, concerns linger regarding the wider ramifications, including potential weaknesses in Linux systems.
## What is Secure Boot?
Introduced in 2012, Secure Boot is a security standard intended to safeguard devices from firmware-level threats. It operates by establishing a “chain of trust” throughout the boot sequence, guaranteeing that every component loaded—from firmware to the operating system bootloader—is digitally signed and authenticated. This mechanism is part of the Unified Extensible Firmware Interface (UEFI), which serves as the modern substitute for the traditional BIOS system.
The primary objective of Secure Boot is to obstruct harmful code, such as bootkits, from executing during the early phases of a device’s boot process. Bootkits pose significant risks because they function at a low level, circumventing standard operating system protections and persisting even after a device has been reformatted.
## The Vulnerability: A Signed Yet Dangerous UEFI Application
The vulnerability at hand was uncovered by Martin Smolár, a researcher from the cybersecurity company ESET. Smolár pinpointed a questionable UEFI application labeled `reloader.efi` embedded within SysReturn, a real-time recovery software created by Howyar Technologies. This application was digitally signed and had successfully navigated Microsoft’s internal evaluation for third-party UEFI applications.
Nevertheless, `reloader.efi` managed to evade Secure Boot’s essential checks by utilizing a custom Portable Executable (PE) loader rather than the standard UEFI functions `LoadImage` and `StartImage`. This custom loader failed to execute the required digital signature validations, effectively compromising the Secure Boot framework.
Further scrutiny uncovered that this vulnerable application was not exclusive to SysReturn. It was also found in recovery solutions from six additional vendors, such as Greenware GreenGuard, Radix SmartRecovery, and WASAY eRecoveryRX. The complete roster of impacted software versions is as follows:
– **Howyar SysReturn**: Prior to version 10.2.023_20240919
– **Greenware GreenGuard**: Prior to version 10.2.023-20240927
– **Radix SmartRecovery**: Prior to version 11.2.023-20240927
– **Sanfong EZ-back System**: Prior to version 10.3.024-20241127
– **WASAY eRecoveryRX**: Prior to version 8.4.022-20241127
– **CES NeoImpact**: Prior to version 10.1.024-20241127
– **SignalComputer HDD King**: Prior to version 10.3.021-20241127
## The Implications of the Vulnerability
The risk posed by this vulnerability extended beyond devices operating the affected recovery software. Malicious actors who had already obtained administrative access on a Windows device could deploy `reloader.efi` themselves. Given that the application was digitally signed, it could facilitate the loading of harmful firmware during the boot sequence, effectively circumventing Secure Boot defenses.
Once deployed, such malicious firmware could provide attackers with enduring control over the device, enabling them to avoid detection and preserve access even after the operating system has been reinstalled. This type of assault is particularly alarming for enterprises, governmental bodies, and other organizations that depend on Secure Boot to safeguard sensitive systems.
## Microsoft’s Response and Industry Concerns
Microsoft responded to the vulnerability on October 10, 2023, by revoking the digital signature for `reloader.efi` and updating Windows to mitigate the threat. However, the lag in delivering a fix—over a year after the vulnerability was reported to the CERT Coordination Center—has raised concerns regarding the company’s timeliness in response.
This is not the inaugural instance of Microsoft’s code-signing procedures being scrutinized. In 2022, the security firm Eclypsium discovered three software drivers signed by Microsoft that could be exploited to bypass Secure Boot. These incidents underscore the hurdles involved in ensuring the integrity of third-party UEFI applications.
In a blog post, Smolár stressed the necessity for enhanced transparency in Microsoft’s UEFI code-signing protocol. He proposed that Microsoft utilize its upcoming rollout of new UEFI certificates as a chance to improve visibility into third-party applications that receive digital signatures. This would empower the security community to more effectively identify and report unsafe applications.
## The Status of Linux Systems
Although the vulnerability predominantly impacted Windows devices, the situation regarding Linux systems remains ambiguous. Secure Boot is similarly utilized in Linux distributions, including Red Hat, Suse, and Ubuntu, to defend against firmware-level threats. However, as of now, these vendors have not confirmed whether
