Linux developers are in the process of patching a high-severity vulnerability that, in certain cases, allows the installation of malware that runs at the firmware level, giving infections access to the deepest parts of a device where they’re hard to detect or remove.
The vulnerability resides in shim, which in the context of Linux is a small component that runs in the firmware early in the boot process before the operating system has started. More specifically, the shim accompanying virtually all Linux distributions plays a crucial role in secure boot, a protection built into most modern computing devices to ensure every link in the boot process comes from a verified, trusted supplier. Successful exploitation of the vulnerability allows attackers to neutralize this mechanism by executing malicious firmware at the earliest stages of the boot process before the Unified Extensible Firmware Interface firmware has loaded and handed off control to the operating system.
The vulnerability, tracked as CVE-2023-40547, is what’s known as a buffer overflow, a coding bug that allows attackers to execute code of their choice. It resides in a part of the shim that processes booting up from a central server on a network using the same HTTP that the Internet is based on. Attackers can exploit the code-execution vulnerability in various scenarios, virtually all following some form of successful compromise of either the targeted device or the server or network the device boots from.
“An attacker would need to be able to coerce a system into booting from HTTP if it’s not already doing so, and either be in a position to run the HTTP server in question or MITM traffic to it,” Matthew Garrett, a security developer and one of the original shim authors, wrote in an online interview. “An attacker (physically present or who has already compromised root on the system) could use this to subvert secure boot (add a new boot entry to a server they control, compromise shim, execute arbitrary code).”
Stated differently, these scenarios include:
- Acquiring the ability to compromise a server or perform an adversary-in-the-middle impersonation of it to target a device that’s already configured to boot using HTTP
- Already having physical access to a device or gaining administrative control by exploiting a separate vulnerability.
While these hurdles are steep, they’re by no means impossible, particularly the ability to compromise or impersonate a server that communicates with devices over HTTP, which is unencrypted and requires no authentication. These particular scenarios could prove useful if an attacker has already gained some level of access inside a network and is looking to take control of connected end-user devices. These scenarios, however, are largely remedied if servers use HTTPS, the variant of HTTP that requires a server to authenticate itself. In that case, the attacker would first have to forge the digital certificate the server uses to prove it’s authorized to provide boot firmware to devices.
The ability to gain physical access to a device is also difficult and is widely regarded as grounds for considering it to be already compromised. And, of course, already obtaining administrative control through exploiting a separate vulnerability in the operating system is hard and allows attackers to achieve all kinds of malicious objectives.
That said, obtaining the ability to execute code during the boot process, before the main operating system starts, constitutes a major escalation of whatever access an attacker already has. It means the attacker can neutralize many forms of endpoint protection designed to detect compromises. As such, the attack allows for the installation of a bootkit, the term for malware that runs prior to the OS. Unlike many bootkits, however, the one created by exploiting CVE-2023-40547 won’t survive the wiping or reformatting of a hard drive.
Garrett explained:
In theory this shouldn’t give an attacker the ability to compromise the firmware itself, but in reality it gives them code execution before ExitBootServices (the handoff between the firmware still running the hardware and the OS taking over) and that means a much larger attack surface against the firmware—the usual assumption is that only trusted code is running before ExitBootServices. I think this would still be called a boot kit—it’s able to modify the OS bootloader and kernel before execution. But it wouldn’t be fully persistent (if you wipe the disk it’d be gone).
Fixing the vulnerability involves more than just excising the buffer overflow from the shim code. It also requires updating the secure boot mechanism to revoke vulnerable bootloader versions. That, in turn, raises some level of risk. Paul Asadoorian, principal security evangelist at Eclypsium and author of blog post that raised awareness of the vulnerability, explained:
Users could run into a situation where a DBX (revocation list) update is being applied to their system that defines the currently installed bootloader as invalid in Secure Boot. In this case, upon reboot, Secure Boot would halt the boot process. As long as the user can get into their BIOS/UEFI settings, this can be remedied by temporarily disabling Secure Boot (if the user has set a BIOS password this would make recovery extremely difficult). The Linux utility fwupd has facilities to update the Secure Boot DBX and will provide warnings to the user if the currently installed bootloader is in the pending DBX update.
Another challenge in updating, Asadoorian said, involves the finite amount of space reserved for storing revocations in a portion of the UEFI known as the DBX. Some lists could contain more than 200 entries that must be appended to the DBX. With many shims capping the space at 32 kilobits, this capacity could be close to running out of space.
