Two vulnerabilities have been disclosed in the GRUB2 bootloader that could lead to code execution when using specially designed fonts and handling certain Unicode sequences. Vulnerabilities can be used to bypass the UEFI Secure Boot verified boot mechanism.
Identified vulnerabilities:
- CVE-2022-2601 - A buffer overflow in the grub_font_construct_glyph() function when processing specially designed fonts in pf2 format, which occurs due to the incorrect calculation of the max_glyph_size parameter and the allocation of a memory area that is obviously smaller than necessary for placing glyphs.
- CVE-2022-3775 - Write out of bounds when rendering certain Unicode sequences in custom font. The problem is present in the font handling code and is caused by a lack of proper checks to ensure that the width and height of the glyph match the size of the available bitmap. An attacker can pick up the input in such a way as to cause a tail of data to be written to the end of the allocated buffer. It is noted that despite the complexity of exploiting the vulnerability, bringing the problem to code execution is not excluded.
The fix has been posted as a patch. The status of fixing vulnerabilities in distributions can be assessed on these pages: Ubuntu, SUSE, RHEL, Fedora, Debian. To fix problems in GRUB2, it is not enough just to update the package, you will also need to create new internal digital signatures and update installers, bootloaders, kernel packages, fwupd firmware and shim layer.
Most Linux distributions use a small shim layer, digitally signed by Microsoft, for verified boot in UEFI Secure Boot mode. This layer verifies GRUB2 with its own certificate, which allows distribution developers not to certify every kernel and GRUB update with Microsoft. Vulnerabilities in GRUB2 allow you to achieve the execution of your code at the stage after successful verification of shim, but before loading the operating system, wedging into the chain of trust with the Secure Boot mode active and gaining full control over the further boot process, including booting another OS, modifying operating system components system and bypass lockdown protection.
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 in collaboration with Microsoft and involves adding additional metadata to the UEFI component executable files, which includes information about the manufacturer, product, component, and version. The specified metadata is digitally signed 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 a digital signature for individual component version numbers without the need to revoke keys for Secure Boot. Blocking vulnerabilities through SBAT does not require the use of a UEFI CRL (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. Prior to the introduction of SBAT, updating the list of revoked certificates (dbx, UEFI Revocation List) was a prerequisite for completely blocking the vulnerability, since an attacker, regardless of the operating system used, could use boot media with an old vulnerable version of GRUB2 certified by a digital signature to compromise UEFI Secure Boot .
Source: opennet.ru