{"id":104320,"date":"2022-06-08T15:36:43","date_gmt":"2022-06-08T13:36:43","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/uyazvimosti-v-grub2-pozvolyayushhie-obojti-uefi-secure-boot"},"modified":"2022-06-08T15:36:43","modified_gmt":"2022-06-08T13:36:43","slug":"uyazvimosti-v-grub2-pozvolyayushhie-obojti-uefi-secure-boot","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sv\/blog\/news\/uyazvimosti-v-grub2-pozvolyayushhie-obojti-uefi-secure-boot","title":{"rendered":"S\u00e5rbarheter i GRUB2 som g\u00f6r att man kan kringg\u00e5 UEFI Secure Boot","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

I GRUB2-startaren har sju s\u00e5rbarheter \u00e5tg\u00e4rdats som g\u00f6r det m\u00f6jligt att kringg\u00e5 mekanismen UEFI Secure Boot och k\u00f6ra icke verifierad kod, till exempel genom att inf\u00f6ra skadlig programvara som fungerar p\u00e5 startar- eller k\u00e4rnniv\u00e5. Dessutom har en s\u00e5rbarhet noterats i shim-lagret som ocks\u00e5 g\u00f6r det m\u00f6jligt att kringg\u00e5 UEFI Secure Boot. Gruppen av s\u00e5rbarheter fick kodnamnet Boothole 3, i likhet med liknande problem som tidigare har identifierats i startaren. <\/p>\n

F\u00f6r att \u00e5tg\u00e4rda problemen i GRUB2 och shim kommer distributioner att kunna anv\u00e4nda mekanismen SBAT (UEFI Secure Boot Advanced Targeting), vars st\u00f6d har implementerats f\u00f6r GRUB2, shim och fwupd. SBAT har utvecklats tillsammans med Microsoft och inneb\u00e4r att det l\u00e4ggs till metadata i de exekverbara filerna f\u00f6r UEFI-komponenter, som inneh\u00e5ller information om tillverkare, produkt, komponent och version. Denna metadata signeras digitalt och kan separat inkluderas i listor \u00f6ver till\u00e5tna eller f\u00f6rbjudna komponenter f\u00f6r UEFI Secure Boot. <\/p>\n

I de flesta Linux-distributioner anv\u00e4nds ett litet shim-lager, signerat av Microsoft, f\u00f6r verifierad boot i UEFI Secure Boot-l\u00e4get. Detta lager verifierar GRUB2 med sin egen certifikat, vilket g\u00f6r att distributionsutvecklare inte beh\u00f6ver signera varje k\u00e4rn- och GRUB-uppdatering i Microsoft. S\u00e5rbarheter i GRUB2 g\u00f6r det m\u00f6jligt att k\u00f6ra egen kod efter att shim har verifierats framg\u00e5ngsrikt, men f\u00f6re operativsystemets laddning, vilket inneb\u00e4r att man kan tr\u00e4nga in i f\u00f6rtroendekedjan i aktivt l\u00e4ge Secure Boot och f\u00e5 full kontroll \u00f6ver den fortsatta bootprocessen, inklusive laddning av ett annat OS, modifiering av operativsystemets komponenter och kringg\u00e5 skyddet Lockdown. <\/p>\n

F\u00f6r att \u00e5tg\u00e4rda problemen i startaren kommer distributionerna att beh\u00f6va skapa nya interna digitala signaturer och uppdatera installationsprogram, startare, kernelpaket, fwupd-firmware och shim-lager. Innan SBAT implementerades var det obligatoriskt att uppdatera listan \u00f6ver \u00e5terkallade certifikat (dbx, UEFI Revocation List) f\u00f6r att fullst\u00e4ndigt blockera s\u00e5rbarheten, eftersom en angripare, oavsett vilket operativsystem som anv\u00e4ndes, kunde anv\u00e4nda ett startmedium med en gammal s\u00e5rbar version av GRUB2, signerat med digital signatur, f\u00f6r att kompromettera UEFI Secure Boot. <\/p>\n

Ist\u00e4llet f\u00f6r att \u00e5terkalla signaturen m\u00f6jligg\u00f6r SBAT att blockera anv\u00e4ndningen f\u00f6r specifika versionsnummer av komponenter utan att beh\u00f6va \u00e5terkalla nycklar f\u00f6r Secure Boot. Att blockera s\u00e5rbarheter via SBAT kr\u00e4ver ingen anv\u00e4ndning av listan \u00f6ver \u00e5terkallade UEFI-certifikat (dbx), utan g\u00f6rs p\u00e5 niv\u00e5n av att ers\u00e4tta den interna nyckeln f\u00f6r att skapa signaturer och uppdatera GRUB2, shim och andra levererade distributionsboot-artefakter. F\u00f6r n\u00e4rvarande har st\u00f6d f\u00f6r SBAT redan lagts till i de flesta popul\u00e4ra Linux-distributioner. <\/p>\n

Uppt\u00e4ckta s\u00e5rbarheter: <\/p>\n