I Shim-lagret, som anv\u00e4nds i de flesta Linux-distributioner f\u00f6r verifierad boot i UEFI Secure Boot-l\u00e4ge, har en s\u00e5rbarhet identifierats (CVE-2023-40547) som kan leda till fj\u00e4rrk\u00f6rning av kod och kringg\u00e5 UEFI Secure Boot-verifieringsmekanismen. En angripare som kontrollerar HTTP-servern som Shim kontaktar kan returnera ett specialutformat svar, vilket leder till kontrollerad skrivning utanf\u00f6r bufferten och m\u00f6jligg\u00f6r kodutf\u00f6rande tidigt i boot-processen. <\/p>\n
S\u00e5rbarheten orsakas av ett fel i koden f\u00f6r filuppladdning via HTTP, som visar sig vid hantering av felaktiga svar som returneras av HTTP-servern som shim g\u00f6r anrop till. HTTPBoot-l\u00e4get i Shim har st\u00f6d sedan 2016 och m\u00f6jligg\u00f6r n\u00e4tverksboot, vilket anv\u00e4nder HTTP-protokollet f\u00f6r att h\u00e4mta en fil med en bootloader som kallas i n\u00e4sta steg. N\u00e4r Shim laddar upp filer via HTTP allokerar det en buffert f\u00f6r mottagna data, baserat p\u00e5 storleken angiven i HTTP-rubriken \"Content-Length\" snarare \u00e4n den faktiska datastorleken. D\u00e4rmed, genom att returnera ett mindre v\u00e4rde i Content-Length-rubriken, kan man \u00e5stadkomma att man skriver bort en del av beg\u00e4ran i minnet utanf\u00f6r bufferten. <\/p>\n
Shim \u00e4r signerad med en digital signatur fr\u00e5n Microsoft och verifierar GRUB2 med sitt eget certifikat, vilket g\u00f6r att distributionsutvecklare inte beh\u00f6ver signera varje k\u00e4rn- och GRUB-uppdatering med Microsoft. S\u00e5rbarheten i Shim m\u00f6jligg\u00f6r en inbrytning i f\u00f6rtroendekedjan n\u00e4r Secure Boot-l\u00e4get \u00e4r aktivt, vilket ger fullst\u00e4ndig kontroll \u00f6ver den vidare boot-processen, t.ex. f\u00f6r att ladda ett annat operativsystem, modifiera komponenter i operativsystemet och kringg\u00e5 Lockdown-skyddet. <\/p>\n
S\u00e5rbarheten \u00e4r \u00e5tg\u00e4rdad i Shim-version 15.8, men f\u00f6r att helt blockera angreppet via Shim kr\u00e4vs att den nya versionen signeras av Microsoft och implementeras i distributionerna. Status f\u00f6r \u00e5tg\u00e4rdande av s\u00e5rbarheten i distributionerna kan bed\u00f6mas p\u00e5 f\u00f6ljande sidor: Debian, Ubuntu, SUSE, RHEL, Fedora. Problemet \u00e4r att utan \u00e5terkallande av signaturen f\u00f6r den gamla versionen \u00e4r \u00e5tg\u00e4rden meningsl\u00f6s, eftersom en angripare kan anv\u00e4nda en boot-enhet med en s\u00e5rbar version av Shim f\u00f6r att kompromettera UEFI Secure Boot. Men \u00e5terkallande av signaturen skulle leda till of\u00f6rm\u00e5ga att verifierat starta distributioner som forts\u00e4tter att anv\u00e4nda den gamla versionen av Shim. <\/p>\n
F\u00f6r att blockera s\u00e5rbarheten utan att \u00e5terkalla den digitala signaturen kan distributioner anv\u00e4nda mekanismen SBAT (UEFI Secure Boot Advanced Targeting), vars st\u00f6d har implementerats f\u00f6r GRUB2, shim och fwupd i de flesta popul\u00e4ra Linux-distributioner. SBAT har utvecklats i samarbete med Microsoft och inneb\u00e4r att ytterligare metadata som inkluderar information om tillverkare, produkt, komponent och version l\u00e4ggs till i exekverbara filer f\u00f6r UEFI. Dessa metadata signeras digitalt och kan separat ing\u00e5 i listor \u00f6ver till\u00e5tna eller f\u00f6rbjudna komponenter f\u00f6r UEFI Secure Boot. <\/p>\n
SBAT g\u00f6r det m\u00f6jligt att blockera anv\u00e4ndningen av digitala signaturer f\u00f6r specifika versionsnummer av komponenter utan att beh\u00f6va \u00e5terkalla nycklar f\u00f6r Secure Boot. Att blockera s\u00e5rbarheter via SBAT kr\u00e4ver inte anv\u00e4ndning av listan \u00f6ver \u00e5terkallade UEFI-certifikat (dbx), utan g\u00f6rs p\u00e5 niv\u00e5 av att ers\u00e4tta den interna nyckeln f\u00f6r att skapa signaturer och uppdatera GRUB2, shim och andra levererade distributionsbootartefakter. <\/p>\n
F\u00f6rutom den n\u00e4mnda s\u00e5rbarheten i Shim 15.8 har flera mindre farliga problem \u00e5tg\u00e4rdats som utnyttjas lokalt: <\/p>\n