Details have been revealed about two vulnerabilities in the GRUB2 bootloader that could 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 verified boot mechanism.
Geïdentificeerde kwetsbaarheden:
- CVE-2022-2601 — a buffer overflow in the grub_font_construct_glyph() function when processing specially crafted fonts in pf2 format, arising from an incorrect calculation of the max_glyph_size parameter and allocating a memory area smaller than necessary to fit the glyphs.
- CVE-2022-3775 — out-of-bounds write when rendering certain Unicode sequences with a specially crafted font. The issue exists in the font processing code and is caused by a lack of proper checks for glyph width and height against the available bitmap size. An attacker can supply input in such a way as to cause a write of data beyond the allocated buffer. It is noted that despite the complexity of exploiting the vulnerability, triggering code execution cannot be ruled out.
A fix has been published in the form of a patch. The status of vulnerability remediation in various distributions can be assessed on the following pages: Ubuntu, SUSE, RHEL, Fedora, Debian. Simply updating the package is not sufficient to address the issues in GRUB2; it will also be necessary to generate new internal digital signatures and update the installers, bootloaders, kernel packages, fwupd firmware, and the shim layer.
In most Linux distributions, a small shim layer, certified by a digital signature from Microsoft, is used for verified boot in UEFI Secure Boot mode. This layer verifies GRUB2 with its own certificate, allowing distribution developers not to certify every kernel and GRUB update with Microsoft. Vulnerabilities in GRUB2 allow achieving code execution at the point after successful verification of the shim but before the operating system is loaded, inserting into the trust chain during active Secure Boot mode and gaining full control over the further boot process, including booting another OS, modifying operating system components, and bypassing Lockdown protection.
Om de kwetsbaarheid te blokkeren zonder de digitale handtekening in te trekken, kunnen distributies het SBAT-mechanisme (UEFI Secure Boot Advanced Targeting) gebruiken, dat wordt ondersteund voor GRUB2, shim en fwupd in de meeste populaire Linux-distributies. SBAT is in samenwerking met Microsoft ontwikkeld en houdt in dat aanvullende metadata, die informatie bevat over de fabrikant, het product, de component en de versie, worden toegevoegd aan de uitvoerbare bestanden van UEFI-componenten. Deze metadata worden digitaal ondertekend en kunnen afzonderlijk worden opgenomen in lijsten van goedgekeurde of geblokkeerde componenten voor UEFI Secure Boot.
SBAT maakt het mogelijk om het gebruik van digitale handtekeningen voor specifieke versienummers van componenten te blokkeren zonder sleutelintrekking voor Secure Boot. Het blokkeren van kwetsbaarheden via SBAT vereist geen gebruik van de lijst met ingetrokken UEFI-certificaten (dbx), maar vindt plaats op het niveau van het vervangen van de interne sleutel voor het genereren van handtekeningen en het updaten van GRUB2, shim en andere opstartartefacten geleverd door de distributies. Voor de implementatie van SBAT was het bijwerken van de lijst met ingetrokken certificaten (dbx, UEFI Revocation List) een verplicht voorwaarde voor volledige blokkering van de kwetsbaarheid, omdat een aanvaller, ongeacht het gebruikte besturingssysteem, een opstartmedium met een oude kwetsbare versie van GRUB2, ondertekend met digitale handtekening, kon gebruiken om UEFI Secure Boot te compromitteren.
Bron: opennet.ru
