Informatie onthuld over 8 kwetsbaarheden in de GRUB2-bootloader, die het mogelijk maken om het UEFI Secure Boot-mechanisme te omzeilen en niet-gecertificeerde code uit te voeren, zoals het injecteren van malware die op bootloader- of kernel-niveau werkt.
Ter herinnering: in de meeste Linux-distributies wordt voor geverifieerde opstartingen in de UEFI Secure Boot-modus een kleine laag shim gebruikt, die is gecertificeerd door een digitale handtekening van Microsoft. Deze laag verifieert GRUB2 met zijn eigen certificaat, waardoor ontwikkelaars van distributies niet elk kern- en GRUB-update bij Microsoft hoeven te certificeren. Kwetsbaarheden in GRUB2 maken het mogelijk om code uit te voeren na een succesvolle verificatie van de shim, maar vóór het opstarten van het besturingssysteem, zich invoegend in de keten van vertrouwen tijdens een actieve Secure Boot-modus en volledige controle te verkrijgen over het verdere opstartproces, inclusief het opstarten van een ander besturingssysteem, het modificeren van componenten van het besturingssysteem en het omzeilen van de Lockdown-beveiliging.
Net als bij de kwetsbaarheid BootHole van vorig jaar is het niet voldoende om de bootloader bij te werken om het probleem te verhelpen, aangezien een aanvaller, ongeacht het gebruikte besturingssysteem, een opstartmedium met een oude kwetsbare versie van GRUB2, gecertificeerd met een digitale handtekening, kan gebruiken om de UEFI Secure Boot te compromitteren. Het probleem kan alleen worden opgelost door de lijst met ingetrokken certificaten (dbx, UEFI Revocation List) bij te werken, maar in dat geval gaat de mogelijkheid verloren om oude installatiemediums met Linux te gebruiken.
Op systemen met firmware waarin de lijst met ingetrokken certificaten is bijgewerkt, kan in de UEFI Secure Boot-modus alleen een bijgewerkte versie van Linux-distributies worden opgestart. Distributies zullen hun installateurs, bootloaders, kernpakketten, fwupd-firmware en shim-laag moeten bijwerken, en voor hen nieuwe digitale handtekeningen moeten genereren. Gebruikers moeten hun installatietools en andere opstartmedia bijwerken, evenals de lijst met ingetrokken certificaten (dbx) in de UEFI-firmware uploaden. Totdat dbx in de UEFI is bijgewerkt, blijft het systeem kwetsbaar, ongeacht of updates in het besturingssysteem zijn geïnstalleerd. De status van de verhelpen van kwetsbaarheden kan worden beoordeeld op de volgende pagina's: Ubuntu, SUSE, RHEL, Debian.
Om problemen met ingetrokken certificaten in de toekomst aan te pakken, is het de bedoeling om het SBAT-mechanisme (UEFI Secure Boot Advanced Targeting) in te schakelen, waarvan de ondersteuning is geïmplementeerd voor GRUB2, shim en fwupd, en dat vanaf de volgende updates zal worden gebruikt in plaats van de functionaliteit die door het dbxtool-pakket wordt aangeboden. SBAT is ontwikkeld in samenwerking met Microsoft en houdt in dat nieuwe metadata aan de uitvoerbare bestanden van UEFI-componenten worden toegevoegd, die informatie bevatten over de fabrikant, het product, de component en de versie. Deze metadata worden digitaal ondertekend en kunnen bovendien worden opgenomen in lijsten met toegestane of verboden componenten voor UEFI Secure Boot. Op deze manier maakt SBAT het mogelijk om bij intrekking de versienummers van componenten te manipuleren zonder dat er nieuwe sleutels voor Secure Boot hoeven te worden gegenereerd en zonder dat er nieuwe handtekeningen voor de kernel, shim, grub2 en fwupd hoeven te worden aangemaakt.
Geïdentificeerde kwetsbaarheden:
- CVE-2020-14372 — Met behulp van het commando acpi in GRUB2 kan een bevoegde lokale gebruiker gemodificeerde ACPI-tabellen laden door de SSDT (Secondary System Description Table) in de map /boot/efi te plaatsen en instellingen in grub.cfg te wijzigen. Ondanks de actieve Secure Boot-modus zal de voorgestelde SSDT door de kernel worden uitgevoerd en kan deze worden gebruikt om de LockDown-bescherming uit te schakelen, die doorgangen voor UEFI Secure Boot blokkeert. Hierdoor kan de aanvaller zijn eigen kernelmodule laden of code uitvoeren via het kexec-mechanisme, zonder digitale handtekening te verifiëren.
- CVE-2020-25632 — Toegang tot al vrijgegeven geheugen (use-after-free) in de implementatie van het commando rmmod, dat zich manifesteert bij het proberen een module uit te laden zonder rekening te houden met de bijbehorende afhankelijkheden. Deze kwetsbaarheid sluit de creatie van een exploit niet uit, die kan leiden tot het uitvoeren van code zonder verificatie door Secure Boot.
- CVE-2020-25647 — Schrijven buiten de buffer in de functie grub_usb_device_initialize(), die wordt aangeroepen bij het initialiseren van USB-apparaten. Het probleem kan worden misbruikt door een speciaal voorbereid USB-apparaat aan te sluiten dat parameters presenteert waarvan de afmetingen niet overeenkomen met de buffermaat die is toegewezen voor USB-structuren. De aanvaller kan ervoor zorgen dat niet-geverifieerde code in Secure Boot wordt uitgevoerd door te manipuleren met USB-apparaten.
- CVE-2020-27749 — een bufferoverloop in de functie grub_parser_split_cmdline(), die kan worden veroorzaakt door het opgeven van meer dan 1 KB aan variabelen in de GRUB2-opdrachtregel. Deze kwetsbaarheid maakt het mogelijk om code uit te voeren, ongeacht Secure Boot.
- CVE-2020-27779 — het cutmem-commando biedt een aanvaller de mogelijkheid om een bereik van adressen uit het geheugen te verwijderen, om zo Secure Boot te omzeilen.
- CVE-2021-3418 — wijzigingen in shim_lock hebben een extra vector gecreëerd voor de exploitatie van de kwetsbaarheid CVE-2020-15705 van vorig jaar. Bij het installeren van een certificaat in dbx, dat wordt gebruikt voor het ondertekenen van GRUB2, stond GRUB2 toe dat een kernel rechtstreeks werd geladen zonder handhaving van de handtekening.
- CVE-2021-20225 — de mogelijkheid om buiten de buffer te schrijven bij het uitvoeren van commando's met een zeer groot aantal opties.
- CVE-2021-20233 — de mogelijkheid om buiten de buffer te schrijven als gevolg van een onjuiste berekening van de buffergrootte bij het gebruik van aanhalingstekens. Bij het berekenen van de grootte werd verondersteld dat het escapen van een enkele aanhalingstekens drie tekens vereist, terwijl dat in werkelijkheid vier is.
Bron: opennet.ru
