A vulnerability (CVE-2023-40547) has been identified in the Shim layer used by most Linux distributions for verified booting in UEFI Secure Boot mode. This can lead to remote code execution and bypassing the UEFI Secure Boot verification mechanism. An attacker controlling the HTTP server that Shim contacts can return a specially formatted response, leading to controlled writes outside the buffer area to execute code early in the boot process. <\/p>\n
The vulnerability is caused by an error in the HTTP file upload code, which manifests when processing incorrect responses returned by the HTTP server that the shim accesses. The HTTPBoot mode in Shim has been supported since 2016 and allows for network booting using the HTTP protocol to retrieve the file with the bootloader invoked in the next stage. When uploading files via HTTP, Shim allocates a buffer for the incoming data, considering not the actual size of the data but the size indicated in the HTTP header 'Content-Length'. Consequently, by returning a smaller value in the Content-Length header, it is possible to achieve the recording of the request tail into memory beyond the buffer. <\/p>\n
Shim is digitally signed by Microsoft and verifies GRUB2 with its own certificate, allowing distribution developers to avoid signing each kernel and GRUB update with Microsoft. The vulnerability in Shim enables an attacker to infiltrate the trust chain while Secure Boot is active and gain full control over the subsequent boot process, such as loading another OS, modifying operating system components, and bypassing Lockdown protections. <\/p>\n
The vulnerability has been addressed in Shim version 15.8, but full mitigation of the attack through Shim requires the new version to be signed by Microsoft and incorporated into distributions. The status of vulnerability remediation in distributions can be assessed on the following pages: Debian, Ubuntu, SUSE, RHEL, Fedora. The issue is that without revoking the signature of the old version, the fix is pointless, as an attacker could use a bootable medium with the vulnerable Shim version to compromise UEFI Secure Boot. However, revoking the signature would lead to the inability to perform verified booting for distributions that continue to use the old Shim version. <\/p>\n
To block vulnerabilities without revoking the digital signature, distributions can use the SBAT (UEFI Secure Boot Advanced Targeting) mechanism, which is supported for GRUB2, shim, and fwupd in most popular Linux distributions. SBAT was developed in collaboration with Microsoft and involves adding additional metadata to the executable files of UEFI components, including information about the manufacturer, product, component, and version. The specified metadata is digitally signed and can be separately included in lists of allowed or disallowed components for UEFI Secure Boot. <\/p>\n
SBAT allows blocking the use of digital signatures for specific version numbers of components without the need to revoke keys for Secure Boot. Blocking vulnerabilities via SBAT does not require the use of the UEFI revoked certificate list (dbx), but is performed at the internal key replacement level for generating signatures and updating GRUB2, shim, and other boot artifacts provided by distributions. <\/p>\n
In addition to the vulnerability discussed, Shim 15.8 has also fixed several less critical issues exploited locally: <\/p>\n