I GRUB2 bootloader 8 sårbarheter. Farligaste (), som har kodnamnet BootHole, kringgå UEFI Secure Boot-mekanismen och installera overifierad skadlig programvara. Det speciella med denna sårbarhet är att det inte räcker med att uppdatera GRUB2 för att eliminera den, eftersom angriparen kan använda startbara media med en gammal sårbar version certifierad av en digital signatur. En angripare kan äventyra verifieringsprocessen inte bara för Linux, utan även för andra operativsystem, inklusive .
Problemet kan bara lösas genom att uppdatera systemet (dbx, UEFI Revocation List), men i det här fallet kommer möjligheten att använda gamla installationsmedia med Linux att gå förlorad. Vissa utrustningstillverkare har redan inkluderat en uppdaterad lista över återkallelsecertifikat i sin firmware; på sådana system kan endast uppdaterade versioner av Linux-distributioner laddas i UEFI Secure Boot-läge.
För att eliminera sårbarheten i distributioner kommer du också 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.
Sårbarhet ett buffertspill som kan utnyttjas för att exekvera godtycklig kod under uppstartsprocessen.
Sårbarheten uppstår vid analys av innehållet i konfigurationsfilen grub.cfg, som vanligtvis finns i ESP (EFI System Partition) och kan redigeras av en angripare med administratörsrättigheter utan att kränka integriteten för de signerade shim- och GRUB2-körbara filerna. Därför att i konfigurationsparserkoden visade hanteraren för fatala analysfel YY_FATAL_ERROR endast en varning, men avslutade inte programmet. Risken för sårbarhet minskar genom behovet av att ha privilegierad åtkomst till systemet, dock kan problemet behövas för att introducera dolda rootkits om du har fysisk åtkomst till utrustningen (om det är möjligt att boota från ditt eget media).
De flesta Linux-distributioner använder en liten , digitalt signerad 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årbarheten gör det möjligt att, genom att ändra innehållet i grub.cfg, uppnå exekvering av din kod i skedet efter framgångsrik shim-verifiering, men innan du laddar operativsystemet, kila in i förtroendekedjan när Secure Boot-läget är aktivt och få full kontroll över den fortsatta startprocessen, inklusive laddning av ett annat operativsystem, modifiering av operativsystemkomponenter och förbikoppling av skydd .
Andra sårbarheter i GRUB2:
- — buffertspill på grund av bristande kontroll av storleken på det tilldelade minnesområdet i grub_malloc;
- - ett heltalsspill i grub_squash_read_symlink, vilket kan leda till att data skrivs bortom den allokerade bufferten;
- - heltalsspill i read_section_from_string, vilket kan leda till skrivning av data bortom den allokerade bufferten;
- - ett heltalsspill i grub_ext2_read_link, vilket kan leda till att data skrivs bortom den allokerade bufferten;
- — låter dig ladda osignerade kärnor under direktstart i Säkert startläge utan ett mellanläggslager;
- — tillgång till ett redan frigjort minnesområde (use-after-free) vid omdefiniering av en funktion under körning;
- — heltalsspill i initrd-storlekshanteraren.
Uppdateringar av snabbkorrigeringspaket har släppts för , , и . För GRUB2 uppsättning plåster.
Källa: opennet.ru