In de driver die de werking van het NTFS-bestandssysteem mogelijk maakt in de GRUB2-bootloader, is een kwetsbaarheid ontdekt (CVE-2023-4692) die het mogelijk maakt om eigen code op het niveau van de bootloader uit te voeren wanneer er verzoeken worden gedaan naar een speciaal opgemaakt NTFS-bestandssysteemafbeelding. Deze kwetsbaarheid kan worden gebruikt om het mechanisme van gecontroleerd opstarten UEFI Secure Boot te omzeilen.
De kwetsbaarheid wordt veroorzaakt door een fout in de code voor het parseren van het NTFS-attribuut "$ATTRIBUTE_LIST" (grub-core/fs/ntfs.c), die kan worden gebruikt om door de gebruiker gecontroleerde informatie te schrijven naar een geheugengebied buiten de toegewezen buffer. Bij het verwerken van een speciaal opgemaakte NTFS-afbeelding leidt een buffer-overloop tot het overschrijven van een deel van het GRUB-geheugen en kan, onder bepaalde omstandigheden, zelfs het geheugen van de UEFI-firmware beschadigen, wat potentieel het uitvoeren van eigen code op het niveau van de bootloader of firmware mogelijk maakt.
Daarnaast is er in de NTFS-driver van GRUB2 ook een andere kwetsbaarheid ontdekt (CVE-2023-4693), die het mogelijk maakt om de inhoud van een willekeurig geheugengebied te lezen bij het parseren van het attribuut "$DATA" in een speciaal opgemaakte NTFS-afbeelding. Onder andere stelt deze kwetsbaarheid in staat om vertrouwelijke gegevens die in het geheugen zijn gecached te extraheren of de waarden van EFI-variabelen te bepalen.
De problemen zijn momenteel alleen opgelost in de vorm van een patch. De status van het oplossen van kwetsbaarheden in distributies kan worden beoordeeld op de volgende pagina's: Debian, Ubuntu, SUSE, RHEL, Fedora. Het is niet voldoende om alleen het pakket van GRUB2 bij te werken; het is ook nodig om nieuwe interne digitale handtekeningen te genereren en de installateurs, bootloaders, kernelpakketten, fwupd-firmware en de shim-laag bij te werken.
In de meeste Linux-distributies wordt een kleine laag shim, digitaal ondertekend door Microsoft, gebruikt voor geverifieerde opstart in UEFI Secure Boot-modus. Deze laag verifieert GRUB2 met een eigen certificaat, waardoor ontwikkelaars van distributies niet elk kernel- en GRUB-update door Microsoft hoeven te laten ondertekenen. Kwetsbaarheden in GRUB2 maken het mogelijk om eigen code uit te voeren na een succesvolle verificatie van shim, maar vĆ³Ć³r het opstarten van het besturingssysteem, door in de vertrouwensketen te infiltreren terwijl Secure Boot actief is, wat zorgt voor volledige controle over het verdere opstartproces, bijvoorbeeld voor het opstarten van een ander besturingssysteem, het wijzigen van besturingssysteemcomponenten en het omzeilen van de Lockdown-beveiliging.
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 dat het noodzakelijk is om de sleutels voor Secure Boot in te trekken. Het blokkeren van kwetsbaarheden via SBAT vereist geen gebruik van de lijst met ingetrokken UEFI-certificaten (dbx), en gebeurt op het niveau van vervanging van de interne sleutel voor de vorming van handtekeningen en de update van GRUB2, shim en andere door de distributies geleverde opstartartefacten. Voor de implementatie van SBAT was het bijwerken van de lijst met ingetrokken certificaten (dbx, UEFI Revocation List) een vereiste voor volledige blokkade van de kwetsbaarheid, aangezien een aanvaller, ongeacht het gebruikte besturingssysteem, gebruik kon maken van de opstartfunctie om UEFI Secure Boot te compromitteren.
Bron: opennet.ru
