Brother
Professional
- Messages
- 2,590
- Reaction score
- 481
- Points
- 83
The Shim layer, used in most Linux distributions for verified booting in UEFI Secure Boot mode, has a vulnerability (CVE-2023-40547) that can lead to remote code execution and bypass of the UEFI Secure Boot verified boot mechanism. An attacker in control of the HTTP server that Shim accesses can return a specially crafted response that results in a controlled write to an out-of-bounds buffer to allow code execution early in the load phase.
The vulnerability is caused by an error in the file download code over HTTP, which manifests itself when processing incorrect responses returned by the HTTP server accessed by shim. The HTTPBoot mode in Shim has been supported since 2016 and allows you to organize a download over the network using the HTTP protocol to retrieve a file with a loader called in the next step. Shim, when downloading files over HTTP, allocates a buffer for the received data, taking into account not the actual size of the data, but the size specified in the HTTP "Content-Lenght" header. Accordingly, by returning a smaller value in the Content-Lenght header, you can ensure that the tail of the request is written to memory outside the buffer boundary.
Shim is digitally signed by Microsoft and verifies GRUB2 with its own certificate, which allows distribution developers to avoid having every kernel and GRUB update certified by Microsoft. The vulnerability in Shim makes it possible to wedge into the chain of trust when Secure Boot mode is active and gain full control over the further boot process, for example, to load another OS, modify operating system components and bypass Lockdown protection.
The vulnerability is fixed in the release of Shim 15.8, but to completely block an attack via Shim, the new version must be certified by Microsoft and implemented in distribution kits. The status of fixing the vulnerability in distributions can be assessed on these pages: Debian, Ubuntu, SUSE, RHEL, Fedora. The problem is that without revoking the signature of the old version, the fix is pointless, since an attacker could use bootable media with a vulnerable release of Shim to compromise UEFI Secure Boot. But revoking the signature will make it impossible for distributions that continue to use the old Shim release to be verified to boot.
To block the vulnerability 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 jointly with Microsoft and involves adding additional metadata to the executable files of UEFI components, which includes information about the manufacturer, product, component and version. The specified metadata is certified with a digital signature and can be separately included in the lists of allowed or prohibited components for UEFI Secure Boot.
SBAT allows you to block the use of digital signatures for individual component version numbers without having to revoke keys for Secure Boot. Blocking vulnerabilities via SBAT does not require the use of a UEFI certificate revocation list (dbx), but is performed at the level of replacing the internal key to generate signatures and update GRUB2, shim and other boot artifacts supplied by distributions.
In addition to the vulnerability discussed above, Shim 15.8 also fixes several less dangerous problems that are exploited locally:
• CVE-2023-40548 - Integer overflow in the verify_sbat_section function leads to a buffer overflow on 32-bit systems.
• CVE-2023-40546 An out-of-buffer read in error messages via the LogError() function.
• CVE-2023-40549 - An out-of-buffer read during processing in the verify_buffer_authenticode() function of a specially crafted PE-formatted file.
• CVE-2023-40550 - An out-of-buffer read in the verify_buffer_sbat() function.
• CVE-2023-40551 - Out-of-bounds memory read when parsing MZ files.
The vulnerability is caused by an error in the file download code over HTTP, which manifests itself when processing incorrect responses returned by the HTTP server accessed by shim. The HTTPBoot mode in Shim has been supported since 2016 and allows you to organize a download over the network using the HTTP protocol to retrieve a file with a loader called in the next step. Shim, when downloading files over HTTP, allocates a buffer for the received data, taking into account not the actual size of the data, but the size specified in the HTTP "Content-Lenght" header. Accordingly, by returning a smaller value in the Content-Lenght header, you can ensure that the tail of the request is written to memory outside the buffer boundary.
Shim is digitally signed by Microsoft and verifies GRUB2 with its own certificate, which allows distribution developers to avoid having every kernel and GRUB update certified by Microsoft. The vulnerability in Shim makes it possible to wedge into the chain of trust when Secure Boot mode is active and gain full control over the further boot process, for example, to load another OS, modify operating system components and bypass Lockdown protection.
The vulnerability is fixed in the release of Shim 15.8, but to completely block an attack via Shim, the new version must be certified by Microsoft and implemented in distribution kits. The status of fixing the vulnerability in distributions can be assessed on these pages: Debian, Ubuntu, SUSE, RHEL, Fedora. The problem is that without revoking the signature of the old version, the fix is pointless, since an attacker could use bootable media with a vulnerable release of Shim to compromise UEFI Secure Boot. But revoking the signature will make it impossible for distributions that continue to use the old Shim release to be verified to boot.
To block the vulnerability 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 jointly with Microsoft and involves adding additional metadata to the executable files of UEFI components, which includes information about the manufacturer, product, component and version. The specified metadata is certified with a digital signature and can be separately included in the lists of allowed or prohibited components for UEFI Secure Boot.
SBAT allows you to block the use of digital signatures for individual component version numbers without having to revoke keys for Secure Boot. Blocking vulnerabilities via SBAT does not require the use of a UEFI certificate revocation list (dbx), but is performed at the level of replacing the internal key to generate signatures and update GRUB2, shim and other boot artifacts supplied by distributions.
In addition to the vulnerability discussed above, Shim 15.8 also fixes several less dangerous problems that are exploited locally:
• CVE-2023-40548 - Integer overflow in the verify_sbat_section function leads to a buffer overflow on 32-bit systems.
• CVE-2023-40546 An out-of-buffer read in error messages via the LogError() function.
• CVE-2023-40549 - An out-of-buffer read during processing in the verify_buffer_authenticode() function of a specially crafted PE-formatted file.
• CVE-2023-40550 - An out-of-buffer read in the verify_buffer_sbat() function.
• CVE-2023-40551 - Out-of-bounds memory read when parsing MZ files.
