Details have been revealed about two vulnerabilities in the GRUB2 bootloader that can lead to code execution when using specially crafted fonts and processing certain Unicode sequences. The vulnerabilities can be exploited to bypass the UEFI Secure Boot verification mechanism.
Identified vulnerabilities:
- CVE-2022-2601 — a buffer overflow in the function grub_font_construct_glyph() when processing specially crafted pf2 format fonts, caused by an incorrect calculation of the max_glyph_size parameter and allocating a memory area that is deliberately smaller than necessary to accommodate the glyphs.
- CVE-2022-3775 — out-of-bounds write when rendering certain Unicode sequences with a specially crafted font. The problem exists in the font processing code and is triggered by a lack of proper checks between the glyph’s width and height and the size of the existing bitmap. An attacker can craft input in such a way that it triggers a write of data beyond the allocated buffer. It is noted that although the exploitation of the vulnerability is complex, achieving code execution cannot be ruled out.
A fix has been published as a patch. The status of vulnerabilities in distributions can be assessed on the following pages: Ubuntu, SUSE, RHEL, Fedora, Debian. Simply updating the GRUB2 package is insufficient; new internal digital signatures will also need to be generated, along with updates to installers, bootloaders, kernel packages, fwupd firmware, and shim layers.
In most Linux distributions, a small shim layer, digitally signed by Microsoft, is used for verified boot in UEFI Secure Boot mode. This shim verifies GRUB2 with its own certificate, allowing distribution developers to avoid signing each kernel and GRUB update with Microsoft. Vulnerabilities in GRUB2 can enable code execution after the successful verification of the shim but before the operating system boots, intruding into the trust chain during active Secure Boot mode and gaining full control of the boot process, including the ability to load another OS, modify OS components, and bypass Lockdown protection.
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 individual version numbers of components without the need for revoking keys for Secure Boot. Blocking vulnerabilities through SBAT does not require using the UEFI revocation list (dbx) and is performed at the level of replacing the internal key for forming signatures and updating GRUB2, shim, and other boot artifacts supplied by distributions. Prior to the implementation of SBAT, updating the revocation list of certificates (dbx, UEFI Revocation List) was a prerequisite for fully blocking vulnerabilities, as an attacker, regardless of the operating system used, could compromise UEFI Secure Boot using a boot medium with an old vulnerable version of GRUB2, certified with a digital signature.
Source: opennet.ru
