{"id":99320,"date":"2021-03-03T16:22:39","date_gmt":"2021-03-03T14:22:39","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/trudnoustranimye-uyazvimosti-v-grub2-pozvolyayushhie-obojti-uefi-secure-boot"},"modified":"2021-03-03T16:22:39","modified_gmt":"2021-03-03T14:22:39","slug":"trudnoustranimye-uyazvimosti-v-grub2-pozvolyayushhie-obojti-uefi-secure-boot","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/news\/trudnoustranimye-uyazvimosti-v-grub2-pozvolyayushhie-obojti-uefi-secure-boot","title":{"rendered":"Oplossingen voor hardnekkige kwetsbaarheden in GRUB2, waardoor UEFI Secure Boot kan worden omzeild","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
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. <\/p>\n
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\u00f3\u00f3r 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. <\/p>\n
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. <\/p>\n
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\u00efnstalleerd. De status van de verhelpen van kwetsbaarheden kan worden beoordeeld op de volgende pagina's: Ubuntu, SUSE, RHEL, Debian. <\/p>\n
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\u00efmplementeerd 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. <\/p>\n
Ge\u00efdentificeerde kwetsbaarheden: <\/p>\n
\n
CVE-2020-14372 \u2014 met behulp van de acpi-opdracht in GRUB2 kan een geprivilegieerde lokale gebruiker gemodificeerde ACPI-tabellen laden door de SSDT (Secondary System Description Table) in de map \/boot\/efi te plaatsen en de instellingen in grub.cfg te wijzigen. Ondanks de activatie van de Secure Boot-modus, zal de aangeboden SSDT door de kernel worden uitgevoerd en kan deze worden gebruikt om de LockDown-beveiliging die de omzeilingspaden voor UEFI Secure Boot blokkeert, uit te schakelen. Als gevolg hiervan kan de aanvaller zijn eigen kernelmodule of code starten via het kexec-mechanisme zonder digitale handtekeningcontroles.\n
CVE-2020-25632 \u2014 een use-after-free toegang tot een reeds vrijgegeven geheugenruimte in de implementatie van de rmmod-opdracht, die zich manifesteert bij de poging om elke module te ontladen zonder rekening te houden met de bijbehorende afhankelijkheden. De kwetsbaarheid sluit de creatie van een exploit niet uit, die kan leiden tot het uitvoeren van code om de Secure Boot-verificatie heen.\n
CVE-2020-25647 \u2014 een buffer overflow in de functie grub_usb_device_initialize(), die wordt aangeroepen bij de initiatie van USB-apparaten. Het probleem kan worden ge\u00ebxploiteerd door een speciaal voorbereide USB-apparaat aan te sluiten dat parameters opgeeft waarvan de grootte niet overeenkomt met de buffer grootte die is toegewezen voor USB-structuren. De aanvaller kan code uitvoeren die niet is geverifieerd in Secure Boot door manipulaties met USB-apparaten.\n
CVE-2020-27749 \u2014 een buffer overflow in de functie grub_parser_split_cmdline(), die kan worden opgeroepen door variabelen van meer dan 1 KB op de GRUB2-opdrachtregel op te geven. De kwetsbaarheid staat het uitvoeren van code toe om Secure Boot heen.\n
CVE-2020-27779 \u2014 de cutmem-opdracht biedt de aanvaller de mogelijkheid om een reeks adressen uit het geheugen te verwijderen om Secure Boot te omzeilen.\n
CVE-2021-3418 \u2014 wijzigingen in shim_lock hebben een extra vector gecre\u00eberd voor de exploitatie van de kwetsbaarheid CVE-2020-15705 van vorig jaar. Bij het installeren van een certificaat in dbx dat wordt gebruikt voor de handtekening van GRUB2, stond GRUB2 toe dat elke kernel rechtstreeks zonder handtekeningverificatie werd geladen.\n
CVE-2021-20225 \u2014 de mogelijkheid van buffer overflows bij het uitvoeren van opdrachten met een zeer groot aantal opties.\n
CVE-2021-20233 \u2014 de mogelijkheid van het overschrijden van de buffer van gegevens door incorrecte berekening van de buffer grootte bij het gebruik van aanhalen. Bij de berekening werd aangenomen dat het escapen van een enkele aanhalingstekens drie tekens vereist, terwijl in werkelijkheid vier nodig zijn. <\/ul>\n