I drivrutinen som hanterar NTFS-filsystemet i GRUB2 har en sÄrbarhet (CVE-2023-4692) identifierats som möjliggör körning av egen kod pÄ bootloadernivÄ nÀr man interagerar med en sÀrskilt utformad filsystemavbildning. SÄrbarheten kan anvÀndas för att kringgÄ mekanismen för verifierad uppstart (UEFI Secure Boot).
SÄrbarheten orsakas av ett fel i koden som analyserar NTFS-attributet "$ATTRIBUTE_LIST" (grub-core/fs/ntfs.c), vilket kan utnyttjas för att skriva anvÀndarkontrollerad information i minnesomrÄden utanför den tilldelade bufferten. Vid bearbetning av en sÀrskilt utformad NTFS-avbildning leder buffertöverskridande till överskrivning av en del av GRUB-minnet och, under vissa förhÄllanden, skador pÄ UEFI-firmwareminnet, vilket potentiellt möjliggör körning av egen kod pÄ bootloader- eller firmware-nivÄ.
Dessutom har en annan sÄrbarhet (CVE-2023-4693) identifierats i NTFS-drivrutinen i GRUB2, vilket gör det möjligt att lÀsa innehÄllet i ett godtyckligt minnesomrÄde nÀr man analyserar attributet "$DATA" i en sÀrskilt utformad NTFS-avbildning. Bland annat tillÄter sÄrbarheten extraktion av konfidentiella data som Àr cachelagrade i minnet eller identifiering av vÀrden för EFI-variabler.
Problemen har hittills endast ÄtgÀrdats i form av en patch. Status för sÄrbarhetsÄtgÀrder i distributioner kan bedömas pÄ följande sidor: Debian, Ubuntu, SUSE, RHEL, Fedora. För att ÄtgÀrda problemen i GRUB2 rÀcker det inte att bara uppdatera paketet; det krÀvs Àven att nya interna digitala signaturer skapas och att installatörer, bootloaders, kernelpaket, fwupd-firmware och shim-lagret uppdateras.
I de flesta Linux-distributioner anvÀnds ett litet lager shim, som Àr certifierat med en digital signatur av Microsoft, för verifierad uppstart i UEFI Secure Boot-lÀge. Detta lager verifierar GRUB2 med sin egen certifikat, vilket gör att distributionsutvecklare inte behöver certifiera varje kÀrn- och GRUB-uppdatering hos Microsoft. SÄrbarheter i GRUB2 kan utnyttjas för att köra kod efter att shim verifierats framgÄngsrikt, men innan operativsystemet startas, genom att bryta kedjan av förtroende under aktivt Secure Boot-lÀge och ta full kontroll över den fortsatta startprocessen, exempelvis för att starta ett annat operativsystem, modifiera operativsystemskomponenter och kringgÄ Lockdown-skyddet.
För att blockera sÄrbarheten utan att Äterkalla den digitala signaturen kan distributioner anvÀnda mekanismen SBAT (UEFI Secure Boot Advanced Targeting), vars stöd har implementerats för GRUB2, shim och fwupd i de flesta populÀra Linux-distributioner. SBAT har utvecklats i samarbete med Microsoft och innebÀr att ytterligare metadata som inkluderar information om tillverkare, produkt, komponent och version lÀggs till i exekverbara filer för UEFI. Dessa metadata signeras digitalt och kan separat ingÄ i listor över tillÄtna eller förbjudna komponenter för UEFI Secure Boot.
SBAT möjliggör blockering av anvÀndningen av digitala signaturer för individuella versionsnummer av komponenter utan att behöva Äterkalla nycklar för Secure Boot. Blockering av sÄrbarheter via SBAT krÀver inte anvÀndning av den Äterkallade certifikatlistan UEFI (dbx), och sker pÄ nivÄ för utbyte av inre nycklar för att skapa signaturer och uppdatera GRUB2, shim och andra levererade distributionsstartartefakter. Före införandet av SBAT var uppdateringen av den Äterkallade certifikatlistan (dbx, UEFI Revocation List) en nödvÀndig förutsÀttning för fullstÀndig blockering av en sÄrbarhet, eftersom en angripare, oavsett vilket operativsystem som anvÀndes, kunde anvÀnda startdelen för att kompromissa med UEFI Secure Boot.
KĂ€lla: opennet.ru
