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.
The vulnerability is caused by an error in the HTTP file loading code, which manifests when handling incorrect responses returned by the HTTP server that Shim contacts. The HTTPBoot mode in Shim has been supported since 2016 and allows booting over the network using the HTTP protocol to retrieve the loader file invoked at the next stage. When loading files over HTTP, Shim allocates a buffer for incoming data based not on the actual size of the data but on the size specified in the HTTP header 'Content-Length'. Therefore, by returning a smaller value in the Content-Length header, it is possible to achieve a write of the request tail into memory outside the buffer.
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.
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.
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.
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.
In addition to the vulnerability discussed, Shim 15.8 has also fixed several less critical issues exploited locally:
- CVE-2023-40548 — integer overflow in the verify_sbat_section function, leading to a buffer overflow on 32-bit systems.
- CVE-2023-40546 — reading out of buffer memory when outputting error messages via the LogError() function.
- CVE-2023-40549 — reading out of buffer memory when processing a specially crafted PE file in the verify_buffer_authenticode() function.
- CVE-2023-40550 — reading out of buffer memory in the verify_buffer_sbat() function.
- CVE-2023-40551 — reading out of buffer memory while parsing MZ format files.
Source: opennet.ru
