On February 2, 2024 details about a new vulnerability being tracked as CVE-2023-40547 was released for shim, a critical piece of software used by most Linux distributions in the boot process to support Secure Boot. Discovered and reported by Bill Demirkapi at Microsoft’s Security Response Center, this particular vulnerability stems from HTTP protocol handling, leading to an out-of-bounds write that can lead to complete system compromise.
What is Shim?
Due to legal issues arising from license incompatibilities, open-source projects and other third parties built a small application called a “shim,” that contains the vendor’s certificate and code that verifies and runs the bootloader (typically GRUB2). The vendor’s shim is verified using the Microsoft 3rd Party UEFI CA, and then the shim loads and verifies the GRUB2 bootloader using the vendor certificate embedded inside itself (reference: There’s A Hole In The Boot).
The Vulnerability
Red Hat maintains the shim software used by most Linux distributions. On December 5, 2023 a code commit was issued to fix the out-of-bounds write occurring in the HTTP boot code inside shim. While on the surface this may look like an issue only affecting Red Hat (according to the CPE), this vulnerability impacts all Linux distributions that support Secure Boot. Several distributions have begun the response process, including Debian, Ubuntu, SUSE, and others. The official NVD entry for CVE-2023-40547 shows NVD’s CVSS score as 9.8 (Critical) and Red Hat’s CVSS score as 8.3 (High).
In addition to CVE-2023-40547 there are 5 additional vulnerabilities disclosed in shim recently, all currently scored as medium severity:
- CVE-2023-40546 – Fixes a LogError() invocation (NULL pointer dereference).
- CVE-2023-40548 – Fixes an integer overflow on SBAT section size on 32-bit systems (heap overflow).
- CVE-2023-40549 – Fixes an out-of-bounds read when loading a PE binary.
- CVE-2023-40550 – Fixes an out-of-bounds read when trying to validate the SBAT information.
- CVE-2023-40551 – Fix bounds check for MZ binaries
The Impact & Remediation
There are a few attack paths that can be used to exploit this vulnerability:
- An attacker could perform a MiTM (Man-in-the-Middle) attack and intercept HTTP traffic between the victim and the HTTP server used to serve files to support HTTP boot. The attacker could be located on any network segment between the victim and the legitimate server.
- The vulnerability can also be exploited locally by an attacker with enough privileges to manipulate data in the EFI Variables or on the EFI partition. This can be accomplished with a live Linux USB stick. The boot order can then be changed such that a remote and vulnerable shim is loaded on the system. This shim is then used to execute privileged code from the same remote server, all without ever disabling Secure Boot.
- An attacker on the same network as the victim can manipulate PXE to chain-load a vulnerable shim bootloader.
An attacker exploiting this vulnerability gains control of the system before the kernel is loaded, which means they have privileged access and the ability to circumvent any controls implemented by the kernel and operating system.
As with previous vulnerabilities in software responsible for the boot process, such as Boot Hole, the Secure Boot chain of trust must be updated. This means the UEFI Secure Boot DBX (revocation list) must be updated to include the hashes of the vulnerable shim software. Steps must also be taken to sign (with the Microsoft 3rd Party CA) new patched versions of shim.
This must be done alongside updating to the new shim version containing the patch. The order of operations here is important as users must first update to the latest version of shim, and then apply the DBX update.
One of the best ways to apply a DBX update on Linux systems is to use fwupd. This can be done from the command line, provided fwupd is installed, by issuing the ‘fwupdmgr update’ command, as shown below:
Applying a DBX update on Linux systems using fwupd
Select distributions with the appropriate GNOME add-ons can use the GUI interface to apply the very same updates, as shown below:
Note: In the Firmware Security Realizations – Part 1 – Secure Boot and DBX blog post, we documented a method of manually updating the DBX on Linux systems. This was before the fwupd project supported this functionality, and as such, using fwupd is the recommended method. Fwupd contains functionality that will check to ensure that the software currently installed on your system is not in the DBX, which would cause Secure Boot to halt the boot process.
Detection
Eclypsium detects this and other secure boot vulnerabilities by tracking bootloader versions and integrity. Changes to the bootloader may occur during OS updates, but signed bootloaders are necessary for the UEFI Secure Boot process.
Eclypsium also tracks the DBX revocation list on each system. This helps IT administrators find systems that would boot the vulnerable version of shim and lock down this issue. Even if older DBX versions are used on the device, Eclypsium can identify bootloader changes, including the use of vulnerable bootloaders that would not have booted using the latest DBX.
Resources & References
- NVD Entry for CVE-2023-40547
- shim 15.8 released with 6 CVE fixes
- There’s A Hole In The Boot
- Firmware Security Realizations – Part 1 – Secure Boot And DBX
- A detailed technical description of shim
- CVE-2023-40547 – Avoid incorrectly trusting HTTP headers
The post The Real Shim Shady - How CVE-2023-40547 Impacts Most Linux Systems appeared first on Eclypsium | Supply Chain Security for the Modern Enterprise.