Normally, Secure Boot prevents the UEFI from running all subsequent files unless they bear a digital signature certifying those files are trusted by the device maker. The exploit bypasses this protection by injecting shell code stashed in a malicious bitmap image displayed by the UEFI in the course of the boot-up process. The injected code installs a cryptographic key that digitally signs a malicious GRUB file together with a backdoored image of the Linux kernel, each of which run during later stages of the boot process on Linux machines.
The silent installation of this key induces the UEFI to treat the malicious GRUB and kernel image as trusted components, and thereby bypass Secure Boot protections. The is a backdoor slipped into the Linux kernel before some other security defenses are loaded.
Diagram illustrating the execution flow of the LogoFAIL exploit Binarly present in the wild.
Credit:
Binarly
In an internet interview, HD Moore, CTO and co-founder at runZero and an authority in firmware-based malware, explained the Binarly report this fashion:
The Binarly paper points to someone using the LogoFAIL bug to configure a UEFI payload that bypasses secure boot (firmware) by tricking the firmware into accepting their self-signed key (which is then stored within the firmware because the MOK variable). The evil code continues to be limited to the user-side of UEFI, however the LogoFAIL exploit does allow them to add their very own signing key to the firmware’s allow list (but doesn’t infect the firmware in any way otherwise).
It’s still effectively a GRUB-based kernel backdoor versus a firmware backdoor, but it surely does abuse a firmware bug (LogoFAIL) to permit installation without user interaction (enrolling, rebooting, then accepting the brand new MOK signing key).
In a traditional secure boot setup, the admin generates a neighborhood key, uses this to sign their updated kernel/GRUB packages, tells the firmware to enroll the important thing they made, then after reboot, the admin has to simply accept this latest key via the console (or remotely via bmc/ipmi/ilo/drac/etc bios console).
On this setup, the attacker can replace the known-good GRUB + kernel with a backdoored version by enrolling their very own signing key without user interaction via the LogoFAIL exploit, but it surely’s still effectively a GRUB-based bootkit, and doesn’t get hardcoded into the BIOS firmware or anything.
Machines vulnerable to the exploit include some models sold by Acer, HP, Fujitsu, and Lenovo once they ship with a UEFI developed by manufacturer Insyde and run Linux. Evidence present in the exploit code indicates the exploit could also be tailored for specific hardware configurations of such machines. Insyde issued a patch earlier this 12 months that forestalls the exploit from working. Unpatched devices remain vulnerable. Devices from these manufacturers that use non-Insyde UEFIs aren’t affected.
