Svårt att åtgärda sårbarheter i GRUB2 som gör att du kan kringgå UEFI Secure Boot

Information har avslöjats om 8 sårbarheter i GRUB2 bootloader, som låter dig kringgå UEFI Secure Boot-mekanismen och köra overifierad kod, till exempel implementera skadlig programvara som körs på bootloader- eller kärnnivå.

Låt oss komma ihåg att i de flesta Linux-distributioner, för verifierad uppstart i UEFI Secure Boot-läge, används ett litet shim-lager, digitalt signerat av Microsoft. Detta lager verifierar GRUB2 med sitt eget certifikat, vilket tillåter distributionsutvecklare att inte ha varje kärna och GRUB-uppdatering certifierad av Microsoft. Sårbarheter i GRUB2 gör att du kan uppnå exekvering av din kod i skedet efter framgångsrik shim-verifiering, men innan du laddar operativsystemet, kilar in i förtroendekedjan när Secure Boot-läget är aktivt och får full kontroll över den fortsatta uppstartsprocessen, inklusive laddar ett annat operativsystem, ändrar operativsystemets komponenter och kringgår Lockdown-skyddet.

Precis som med förra årets BootHole-sårbarhet räcker det inte med att uppdatera bootloadern för att blockera problemet, eftersom en angripare, oavsett vilket operativsystem som används, kan använda startbara media med en gammal, digitalt signerad, sårbar version av GRUB2 för att äventyra UEFI Secure Boot. Problemet kan bara lösas genom att uppdatera certifikatets återkallelselista (dbx, UEFI Revocation List), men i det här fallet kommer möjligheten att använda gamla installationsmedia med Linux att gå förlorad.

På system med firmware som har en uppdaterad lista för återkallande av certifikat kan endast uppdaterade versioner av Linux-distributioner laddas i UEFI Secure Boot-läge. Distributionerna kommer att behöva uppdatera installationsprogram, bootloaders, kärnpaket, fwupd firmware och shim-lager, vilket genererar nya digitala signaturer för dem. Användare kommer att behöva uppdatera installationsbilder och andra startbara media, samt ladda en certifikatåterkallelselista (dbx) i UEFI-firmware. Innan du uppdaterar dbx till UEFI förblir systemet sårbart oavsett installation av uppdateringar i operativsystemet. Statusen för sårbarheter kan bedömas på dessa sidor: Ubuntu, SUSE, RHEL, Debian.

För att lösa problem som uppstår vid distribution av återkallade certifikat är det planerat att i framtiden använda SBAT-mekanismen (UEFI Secure Boot Advanced Targeting), vars stöd har implementerats för GRUB2, shim och fwupd, och från och med nästa uppdatering kommer att vara används istället för funktionaliteten som tillhandahålls av dbxtool-paketet. SBAT utvecklades tillsammans med Microsoft och går ut på att lägga till ny metadata till de körbara filerna för UEFI-komponenter, vilket inkluderar information om tillverkare, produkt, komponent och version. Den angivna metadatan är certifierad med en digital signatur och kan dessutom inkluderas i listorna över tillåtna eller förbjudna komponenter för UEFI Secure Boot. Således kommer SBAT att tillåta dig att manipulera komponentversionsnummer under återkallelse utan att behöva generera nycklar för säker start och utan att generera nya signaturer för kärnan, shim, grub2 och fwupd.

Identifierade sårbarheter:

  • CVE-2020-14372 - Genom att använda acpi-kommandot i GRUB2 kan en privilegierad användare på det lokala systemet ladda modifierade ACPI-tabeller genom att placera en SSDT (Secondary System Description Table) i /boot/efi-katalogen och ändra inställningarna i grub.cfg. Även om Secure Boot-läget är aktivt, kommer den föreslagna SSDT att exekveras av kärnan och kan användas för att inaktivera LockDown-skydd som blockerar UEFI Secure Boot-bypass-vägar. Som ett resultat kan en angripare ladda sin kärnmodul eller köra kod genom kexec-mekanismen, utan att kontrollera den digitala signaturen.
  • CVE-2020-25632 är en användningsfri minnesåtkomst i implementeringen av kommandot rmmod, som inträffar när ett försök görs att ladda ur valfri modul utan att ta hänsyn till de beroenden som är associerade med den. Sårbarheten utesluter inte skapandet av en exploatering som kan leda till att kodexekvering går förbi säker startverifiering.
  • CVE-2020-25647 En out-of-bounds-skrivning i funktionen grub_usb_device_initialize() som anropas när USB-enheter initialiseras. Problemet kan utnyttjas genom att ansluta en speciellt förberedd USB-enhet som producerar parametrar vars storlek inte motsvarar storleken på bufferten som tilldelats för USB-strukturer. En angripare kan åstadkomma exekvering av kod som inte är verifierad i Secure Boot genom att manipulera USB-enheter.
  • CVE-2020-27749 är ett buffertspill i funktionen grub_parser_split_cmdline() som kan orsakas av att variabler som är större än 2 KB anges på kommandoraden GRUB1. Sårbarheten tillåter körning av kod att kringgå Secure Boot.
  • CVE-2020-27779 – Kommandot cutmem tillåter en angripare att ta bort ett antal adresser från minnet för att kringgå säker start.
  • CVE-2021-3418 – Ändringar av shim_lock skapade ytterligare en vektor för att utnyttja förra årets sårbarhet CVE-2020-15705. Genom att installera certifikatet som används för att signera GRUB2 i dbx, tillät GRUB2 att alla kärnor laddas direkt utan att verifiera signaturen.
  • CVE-2021-20225 - Möjlighet att skriva out-of-bound data när du kör kommandon med ett mycket stort antal alternativ.
  • CVE-2021-20233 - Möjlighet att skriva data utanför ramarna på grund av felaktig buffertstorleksberäkning vid användning av citattecken. Vid beräkningen av storleken antogs det att det krävdes tre tecken för att undkomma ett enskilt citat, när det i själva verket krävdes fyra.

Källa: opennet.ru

Lägg en kommentar