Information har avslöjats om två sårbarheter i GRUB2 bootloader, som kan leda till kodexekvering när man använder specialdesignade typsnitt och bearbetar vissa Unicode-sekvenser. Sårbarheter kan användas för att kringgå den UEFI Secure Boot-verifierade startmekanismen.
Identifierade sårbarheter:
- CVE-2022-2601 - Ett buffertspill i funktionen grub_font_construct_glyph() vid bearbetning av specialdesignade typsnitt i formatet pf2, vilket uppstår på grund av en felaktig beräkning av parametern max_glyph_size och allokeringen av ett minnesområde som uppenbarligen är mindre än nödvändigt för att rymma glyferna.
- CVE-2022-3775 En out-of-bound-skrivning inträffar när vissa Unicode-sekvenser renderas i ett speciellt formaterat teckensnitt. Problemet ligger i teckensnittsbearbetningskoden och orsakas av brist på korrekta kontroller för att säkerställa att bredden och höjden på glyfen matchar storleken på den tillgängliga bitmappen. En angripare kan skapa inmatningen på ett sådant sätt att den orsakar att datasvansen skrivs till utsidan av den allokerade bufferten. Det noteras att trots komplexiteten i att utnyttja sårbarheten, är det inte uteslutet att föra problemet till kodexekvering.
Korrigeringen har publicerats som en patch. Statusen för att eliminera sårbarheter i distributioner kan bedömas på dessa sidor: Ubuntu, SUSE, RHEL, Fedora, Debian. För att fixa problem i GRUB2 räcker det inte att bara uppdatera paketet, du kommer också att behöva generera nya interna digitala signaturer och uppdatera installationsprogram, bootloaders, kärnpaket, fwupd firmware och shim-lager.
De flesta Linux-distributioner använder ett litet shim-lager digitalt signerat av Microsoft för verifierad uppstart i UEFI Secure Boot-läge. 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.
För att blockera sårbarheten utan att återkalla den digitala signaturen kan distributioner använda SBAT-mekanismen (UEFI Secure Boot Advanced Targeting), som stöds för GRUB2, shim och fwupd i de flesta populära Linux-distributioner. SBAT utvecklades tillsammans med Microsoft och går ut på att lägga till ytterligare 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 inkluderas separat i listorna över tillåtna eller förbjudna 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