If exploited, these flaws can allow attackers to gain unauthorized access to sensitive information or generally cause problems
Details of two vulnerabilities in the GRUB2 boot loader have been disclosed that pcould lead to code execution when using specially designed fonts and handling certain Unicode sequences.
It is mentioned that the vulnerabilities detected aree can be used to bypass the UEFI Secure Boot verified boot mechanism. Vulnerabilities in GRUB2 allow code to be executed at the stage after the successful shim verification, but before the operating system is loaded, breaking the chain of trust with Secure Boot mode active and gaining full control over the post-boot process, e.g. For example, to start another operating system, modify operating system components, and bypass lock protection.
Regarding the identified vulnerabilities, the following is mentioned:
- CVE-2022-2601: a buffer overflow in the grub_font_construct_glyph() function when processing specially crafted fonts in pf2 format, which occurs due to incorrect calculation of the max_glyph_size parameter and allocation of a memory area that is obviously smaller than needed to place glyphs.
- CVE-2022-3775: Out of bounds writing when rendering some Unicode strings in a custom font. The problem is present in the font handling code and is caused by a lack of proper controls to ensure that the glyph width and height match the available bitmap size. An attacker can harvest input in such a way as to cause a queue of data to be written out of the allocated buffer. It is noted that despite the complexity of exploiting the vulnerability, exposing the problem to code execution is not excluded.
Full mitigation against all CVEs will require fixes updated with the latest SBAT (Secure Boot Advanced Targeting) and data provided by distributions and vendors.
This time the UEFI revocation list (dbx) will not be used and the revocation of the broken ones
artifacts will be made only with SBAT. For information on how to apply the
latest SBAT revocations, see mokutil(1). Vendor fixes can explicitly allow booting of older known boot artifacts.GRUB2, shim, and other boot artifacts from all affected vendors will be updated. it will be available when the embargo is lifted or some time after.
Mention is made that most linux distributions use a small patch 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 to not certify every kernel and GRUB update with Microsoft.
To block the vulnerability without revoking the digital signature, distributions can use the SBAT mechanism (UEFI Secure Boot Advanced Targeting), which is supported by GRUB2, shim, and fwupd on most popular Linux distributions.
SBAT was developed in collaboration with Microsoft and involves adding additional metadata to the UEFI component executable files, including manufacturer, product, component, and version information. The specified metadata is digitally signed and can be included in separate allowed or prohibited component lists for UEFI Secure Boot.
SBAT allows blocking the use of a digital signature for individual component version numbers without the need to revoke keys for Secure Boot. Blocking vulnerabilities via SBAT does not require the use of a UEFI CRL (dbx), but rather is done at the internal key replacement level to generate signatures and update GRUB2, shim, and other boot artifacts provided by distributions.
Prior to the introduction of SBAT, updating the certificate revocation list (dbx, UEFI Revocation List) was a prerequisite to completely block the vulnerability, since an attacker, regardless of the operating system used, could use bootable media. with a vulnerable older version of GRUB2 certified by a digital signature to compromise UEFI Secure Boot.
Finally It is worth mentioning that the fix has been released as a patch., to fix problems in GRUB2, it is not enough to update the package, you will also need to create new internal digital signatures and update the installers, bootloaders, kernel packages, fwupd-firmware and shim-layer.
Vulnerability remediation status in distributions can be assessed on these pages: Ubuntu, SUSE, RHEL, Fedora y debian
You can check more about it in the following link