Moeilijk op te lossen kwetsbaarheden in GRUB2 waarmee u UEFI Secure Boot kunt omzeilen

Er is informatie vrijgegeven over 8 kwetsbaarheden in de GRUB2-bootloader, waarmee je het UEFI Secure Boot-mechanisme kunt omzeilen en niet-geverifieerde code kunt uitvoeren, bijvoorbeeld door malware te implementeren die op bootloader- of kernelniveau draait.

Laten we niet vergeten dat in de meeste Linux-distributies voor geverifieerd opstarten in de UEFI Secure Boot-modus een kleine shim-laag wordt gebruikt, digitaal ondertekend door Microsoft. Deze laag verifieert GRUB2 met zijn eigen certificaat, waardoor distributieontwikkelaars niet elke kernel- en GRUB-update door Microsoft kunnen laten certificeren. Kwetsbaarheden in GRUB2 stellen je in staat om de uitvoering van je code te bewerkstelligen in de fase na succesvolle shim-verificatie, maar voordat het besturingssysteem wordt geladen, waardoor je in de vertrouwensketen terechtkomt wanneer de Secure Boot-modus actief is en volledige controle krijgt over het verdere opstartproces, inclusief een ander besturingssysteem laden, de componenten van het besturingssysteem wijzigen en de Lockdown-beveiliging omzeilen.

Net als bij de BootHole-kwetsbaarheid van vorig jaar is het updaten van de bootloader niet voldoende om het probleem te blokkeren, omdat een aanvaller, ongeacht het gebruikte besturingssysteem, opstartbare media met een oude, digitaal ondertekende, kwetsbare versie van GRUB2 kan gebruiken om UEFI Secure Boot in gevaar te brengen. Het probleem kan alleen worden opgelost door de certificaatintrekkingslijst (dbx, UEFI Revocation List) bij te werken, maar in dit geval gaat de mogelijkheid om oude installatiemedia met Linux te gebruiken verloren.

Op systemen met firmware die een bijgewerkte certificaatintrekkingslijst heeft, kunnen alleen bijgewerkte builds van Linux-distributies worden geladen in de UEFI Secure Boot-modus. Distributies zullen installatieprogramma's, bootloaders, kernelpakketten, fwupd-firmware en shim-laag moeten bijwerken, waardoor er nieuwe digitale handtekeningen voor worden gegenereerd. Gebruikers moeten installatie-images en andere opstartbare media bijwerken, en een certificaatintrekkingslijst (dbx) in de UEFI-firmware laden. Voordat dbx naar UEFI wordt bijgewerkt, blijft het systeem kwetsbaar, ongeacht de installatie van updates in het besturingssysteem. De status van kwetsbaarheden kan worden beoordeeld op deze pagina’s: Ubuntu, SUSE, RHEL, Debian.

Om problemen op te lossen die zich voordoen bij het distribueren van ingetrokken certificaten, is het de bedoeling om in de toekomst het SBAT-mechanisme (UEFI Secure Boot Advanced Targeting) te gebruiken, waarvoor ondersteuning is geïmplementeerd voor GRUB2, shim en fwupd, en vanaf de volgende updates zal dit zijn gebruikt in plaats van de functionaliteit die door het dbxtool-pakket wordt geboden. SBAT is samen met Microsoft ontwikkeld en omvat het toevoegen van nieuwe metadata aan de uitvoerbare bestanden van UEFI-componenten, waaronder informatie over de fabrikant, het product, het onderdeel en de versie. De opgegeven metadata zijn gecertificeerd met een digitale handtekening en kunnen bovendien worden opgenomen in de lijsten met toegestane of verboden componenten voor UEFI Secure Boot. Met SBAT kunt u dus versienummers van componenten manipuleren tijdens de intrekking zonder dat u sleutels voor Secure Boot opnieuw hoeft te genereren en zonder nieuwe handtekeningen voor de kernel, shim, grub2 en fwupd te genereren.

Geïdentificeerde kwetsbaarheden:

  • CVE-2020-14372 – Met behulp van de opdracht acpi in GRUB2 kan een bevoorrechte gebruiker op het lokale systeem gewijzigde ACPI-tabellen laden door een SSDT (Secondary System Description Table) in de map /boot/efi te plaatsen en de instellingen in grub.cfg te wijzigen. Hoewel de Secure Boot-modus actief is, wordt de voorgestelde SSDT door de kernel uitgevoerd en kan deze worden gebruikt om de LockDown-beveiliging uit te schakelen die UEFI Secure Boot-bypasspaden blokkeert. Als gevolg hiervan kan een aanvaller zijn kernelmodule laden of code uitvoeren via het kexec-mechanisme, zonder de digitale handtekening te controleren.
  • CVE-2020-25632 is een 'use-after-free' geheugentoegang bij de implementatie van de opdracht rmmod, die optreedt wanneer wordt geprobeerd een module te ontladen zonder rekening te houden met de bijbehorende afhankelijkheden. Het beveiligingslek sluit de creatie van een exploit niet uit die ertoe zou kunnen leiden dat code wordt uitgevoerd waarbij de Secure Boot-verificatie wordt omzeild.
  • CVE-2020-25647 Een schrijffout buiten het bereik in de functie grub_usb_device_initialize() die wordt aangeroepen bij het initialiseren van USB-apparaten. Het probleem kan worden uitgebuit door een speciaal geprepareerd USB-apparaat aan te sluiten dat parameters produceert waarvan de grootte niet overeenkomt met de grootte van de buffer die is toegewezen aan USB-structuren. Een aanvaller kan code uitvoeren die niet is geverifieerd in Secure Boot door USB-apparaten te manipuleren.
  • CVE-2020-27749 is een bufferoverflow in de grub_parser_split_cmdline() functie, die kan worden veroorzaakt door het opgeven van variabelen groter dan 2 KB op de GRUB1-opdrachtregel. Door het beveiligingslek kan code-uitvoering Secure Boot omzeilen.
  • CVE-2020-27779 – Met de opdracht cutmem kan een aanvaller een reeks adressen uit het geheugen verwijderen om Secure Boot te omzeilen.
  • CVE-2021-3418 - Wijzigingen in shim_lock creëerden een extra vector om de kwetsbaarheid CVE-2020-15705 van vorig jaar te misbruiken. Door het certificaat te installeren dat werd gebruikt om GRUB2 in dbx te ondertekenen, stond GRUB2 toe dat elke kernel rechtstreeks werd geladen zonder de handtekening te verifiëren.
  • CVE-2021-20225 - Mogelijkheid om gegevens buiten het bereik te schrijven bij het uitvoeren van opdrachten met een zeer groot aantal opties.
  • CVE-2021-20233 - Mogelijkheid om gegevens buiten het bereik te schrijven vanwege een onjuiste berekening van de buffergrootte bij het gebruik van aanhalingstekens. Bij het berekenen van de grootte werd ervan uitgegaan dat er drie tekens nodig waren om aan een enkel aanhalingsteken te ontsnappen, terwijl er in werkelijkheid vier nodig waren.

Bron: opennet.ru

Voeg een reactie