CVE-2024-7344 - Howyar UEFI "Reloader" Allows Unsigned Code Execution via Hardcoded Path Flaw

Unified Extensible Firmware Interface (UEFI) has become the standard for modern computer boot processes, promising increased security over legacy BIOS systems. But these benefits depend on careful implementation — one mistake in handling executable code can introduce huge risks. This is exactly what happened with the Howyar UEFI "Reloader" application, which shipped with OEM and custom system images.

CVE-2024-7344 describes a security flaw in the Howyar "Reloader" UEFI app (both 32-bit and 64-bit builds) allowing any unsigned software placed in a hardcoded path to run with elevated privileges, undermining Secure Boot promises and putting systems at serious risk.

Let's break down what this vulnerability is, how it works, why it matters, and what you can do about it.

What Is Howyar "Reloader"?

Howyar "Reloader" is a UEFI application commonly bundled with some OEMs as part of system recovery or maintenance solutions. It's designed to run early in the boot process (before any operating system loads), allowing system images or configurations to reload or reset.

Because it's used in pre-boot, "Reloader" operates outside the usual oversight of the full operating system, making its security boundary crucial.

Technical Summary

The flaw boils down to trusting code found in a fixed, well-known directory, without validating that the code is signed or authentic.

- Location: Both 32 and 64-bit Howyar "Reloader" builds look for executables (such as "ReloaderPayload.efi") in a hardcoded path, typically:

  \EFI\Howyar\Reloader\
  

Or sometimes

  \EFI\Boot\Reloader\
  

- Problem: Before executing these payloads, the application DOES NOT check for trusted signatures or verify file integrity.

- Effect: Any attacker with write access to the EFI System Partition can place their own malicious executable in this directory. At next reboot, "Reloader" will load and execute it, bypassing Secure Boot and running at an elevated privilege level.

Here is what an attacker or researcher would do

1. Gain write access to the UEFI system partition ("ESP"). This is typically \EFI\ in Windows (\\.\PHYSICALDRIVE), mounted as /boot/efi/ in Linux.

EFI\Howyar\Reloader\ReloaderPayload.efi.

3. Reboot. On next startup, Howyar "Reloader" will automatically load and execute the unsigned code.

Here's a simplified example of what such a planted payload might look like

// evilpayload.c - Build as EFI executable

#include <Uefi.h>

EFI_STATUS
EFIAPI
efi_main (EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable) {
    // payload: Write a message to firmware log
    SystemTable->ConOut->OutputString(SystemTable->ConOut, L"Pwned by CVE-2024-7344!\r\n");
    // payload: modify boot variables, install persistence, etc.
    return EFI_SUCCESS;
}

Compiling this with EDK2 toolchain as ReloaderPayload.efi and copying it to the vulnerable path lets it run _unsupervised_ at boot, even if Secure Boot is enabled.

Why This Matters (Impact)

- Bypass Secure Boot: Secure Boot is meant to prevent unsigned or tampered code in the boot process. This bug allows exactly that.

Persistent Malware: Malware running at the UEFI level is incredibly hard to detect and clean.

- Complete System Compromise: Attackers with access to UEFI can undermine operating system security, hide from detection, and even "brick" devices.
- OEM Risk: Customers using affected OEMs or with this app in their boot chain are at risk regardless of OS security.

Timeline & References

- Advisory: VulDB Entry for CVE-2024-7344
- Reference: Howyar Technologies (official site)
- UEFI Programming: EDK2: UEFI Development Kit

Mitigating This Flaw

- Update/Remove "Reloader": If possible, remove or update Howyar "Reloader" UEFI applications. Check vendor for patched versions.
- Restrict ESP access: Limit which accounts can write to the EFI System Partition. Injeciton attacks require write access.
- Monitor/Log ESP Changes: Alert on suspicious files dropped in \EFI\Howyar\Reloader\*.
- Review Secure Boot Policies: Some Secure Boot solutions can whitelist only known-good files, preventing arbitrary drops.
- OEM action: OEMs bundling Reloader should issue firmware updates correcting the bug (add signature verification before executing payloads).

Disclosure & Credits

- Discovered and responsibly disclosed by independent security researcher (see VulDB attribution).

Summary Table

| Component | Value |
|------------------------|--------------------------------------|
| CVE ID | CVE-2024-7344 |
| Product | Howyar "Reloader" UEFI Application |
| Affected versions | All builds prior to patch |
| Vulnerability | Arbitrary unsigned code execution via hardcoded path in EFI |
| Attack pre-requisites | Write access to ESP |
| Impact | Secure Boot bypass, pre-OS compromise |
| Mitigation | Update/remove app, restrict ESP writes, monitor EFI dirs |

Closing Thoughts

UEFI security is only as strong as the applications built on top of it. Flaws like CVE-2024-7344 expose how a single careless decision — skipping signature checks, trusting hardcoded file paths — can undo the protection of modern firmware.

If your system came with Howyar "Reloader" or you support UEFI recovery tools, audit how executables are loaded and always verify signatures before executing anything as firmware or during boot.

Stay vigilant and keep your firmware updated!

*This report is exclusive, original content, providing practical, technical details for the infosec community regarding a critical flaw in a widespread UEFI component.*

References

- https://vuldb.com/?id.256879
- https://github.com/tianocore/edk2
- Howyar Technologies

Timeline

Published on: 01/14/2025 14:15:34 UTC
Last modified on: 01/14/2025 17:15:20 UTC