Två sårbarheter i GRUB2 som gör att du kan kringgå UEFI Secure Boot-skydd

Två sårbarheter i GRUB2-bootloadern har avslöjats, vilka kan leda till kodkörning vid användning av specialskapade teckensnitt och hantering av vissa Unicode-sekvenser. Sårbarheterna kan användas för att kringgå den verifierade startmekanismen för UEFI Secure Boot.

Identifierade sårbarheter:

• CVE-2022-2601 - Buffertöversvämning i grub_font_construct_glyph()-funktionen vid bearbetning av specialdesignade teckensnitt i pf2-format, orsakad av felaktig beräkning av parametern max_glyph_size och allokering av minnesutrymme, vilket uppenbarligen är mindre än nödvändigt för att placera teckensnitt.
• CVE-2022-3775 — Skrivning utanför gränserna vid rendering av vissa Unicode-sekvenser med ett specialdesignat teckensnitt. Problemet finns i teckensnittsbearbetningskoden och orsakas av bristen på korrekta kontroller av att teckensnittets bredd och höjd matchar storleken på den tillgängliga bitmappen. En angripare kan välja indata på ett sådant sätt att den sista delen av data skrivs bortom den allokerade bufferten. Det noteras att trots komplexiteten i att utnyttja sårbarheten är det inte uteslutet att problemet kan orsaka kodkörning.

Fixen har publicerats som en patch. Statusen för sårbarhetsfixar i distributioner kan bedömas på dessa sidor: Ubuntu, SUSE, RHEL, Fedora, DebianAtt åtgärda GRUB2-problem kräver mer än att bara uppdatera paketet; det kräver också att nya interna digitala signaturer genereras och att installationsprogram, bootloaders, kernelpaket, fwupd-firmware och shim-lagret uppdateras.

I de flesta LinuxDistributioner för verifierad start i UEFI Secure Boot-läge använder ett litet shim-lager, digitalt signerat av Microsoft. Detta lager verifierar GRUB2 med sitt eget certifikat, vilket eliminerar behovet för distributionsutvecklare att meddela Microsoft om varje kärn- och GRUB-uppdatering. Sårbarheter i GRUB2 möjliggör godtycklig kodkörning efter lyckad shim-verifiering, men innan operativsystemet startar. Detta gör det möjligt för angripare att bryta sig in i förtroendekedjan när Secure Boot är aktiverat och få fullständig kontroll över den efterföljande startprocessen, inklusive att starta ett annat operativsystem, modifiera operativsystemkomponenter och kringgå låsningsskydd.

För att blockera sårbarheten utan att återkalla den digitala signaturen kan distributioner använda SBAT-mekanismen (UEFI Secure Boot Advanced Targeting), vars stöd är implementerat för GRUB2, shim och fwupd i de flesta populära distributioner. LinuxSBAT utvecklades i samarbete med Microsoft och innebär att ytterligare metadata läggs till i UEFI-komponenters körbara filer, inklusive information om tillverkare, produkt, komponent och version. Dessa metadata är digitalt signerade och kan inkluderas separat i listorna över tillåtna eller nekade komponenter för UEFI Secure Boot.

SBAT låter dig blockera användningen av digitala signaturer för individuella komponentversionsnummer utan att behöva återkalla nycklar för säker start. Blockering av sårbarheter via SBAT kräver inte användning av en UEFI-certifikatåterkallelselista (dbx), utan utförs på nivån att ersätta den interna nyckeln för att generera signaturer och uppdatera GRUB2, shim och andra startartefakter som tillhandahålls av distributioner. Före introduktionen av SBAT var uppdatering av certifikatspärrlistan (dbx, UEFI Revocation List) en förutsättning för att helt blockera sårbarheten, eftersom en angripare, oavsett vilket operativsystem som används, kunde använda startbara media med en gammal sårbar version av GRUB2, certifierad av en digital signatur för att äventyra UEFI Secure Boot .

Källa: opennet.ru