Analyserar kärnan i SBAT och problem med att uppdatera till Windows som påverkade Linux-bootningen

Matthew Garrett, en välkänd Linux-kärnutvecklare som en gång fick ett pris från Open Source Foundation för sitt bidrag till utvecklingen av fri programvara, berättade om kärnan i mekanismen SBAT (Secure Boot Advanced Targeting), som skapades för att blockera sårbarheter i bootloadern utan att återkalla den digitala signaturen, samt om dess roll i den senaste incidenten med en uppdatering för Windows, som ledde till att vissa Linux-distributioner som installerats parallellt med Windows på system med aktiverat UEFI Secure Boot slutade ladda. Kort sagt, så var både Microsoft, som inte testade uppdateringen ordentligt och tillämpade den på system där den inte skulle tillämpas, och utvecklarna av vissa Linux-distributioner som inte uppdaterade GRUB-bootloadern och SBAT-generationsnumret när sårbarheter upptäcktes i GRUB, skyldiga.

Nedanför finns en översättning av Garretts anteckning:

När specifikationen för UEFI Secure Boot utvecklades var alla deltagare, låt oss säga, lite naiva. Huvudmodellen för säkerhet i Secure Boot är att all kod som körs i en privilegierad miljö på kärnnivå måste verifieras innan den körs – firmware verifierar bootloadern, bootloadern verifierar kärnan, kärnan verifierar all ytterligare kod som laddas vid körning, och nu har vi en betrodd miljö för att påtvinga vilken annan säkerhetspolicy vi vill. Det är uppenbart att människor kan göra misstag, men i specifikationen fanns det en mekanism för att återkalla signerade komponenter som visat sig vara opålitliga: lägg bara till häschen av den opålitliga koden i en variabel och vägra att ladda något med det häschen, även om det är signerad med en betrodd nyckel.

Tyvärr, som det visade sig, handlar problemet om skala. Varje Linux-distribution som körs i Secure Boot-ekosystemet genererar sina egna binära boot-filer, och varje sådant fil har sin egen hash. Om en sårbarhet upptäckts i källkoden för en sådan boot-fil måste ett stort antal olika binära filer återkallas. Och minnesmängden för att lagra variabeln som innehåller alla dessa hash är begränsad. Det kommer helt enkelt inte att finnas tillräckligt med utrymme för att lägga till en ny uppsättning hashar varje gång det viserar sig att GRUB (boot-loadern som ursprungligen skrevs under en tid när det inte fanns några säkerhetsåtgärder, och som har flera separata parser för img-bilder, samt en parser för teckensnitt) har ytterligare en mekanism för en angripare att få den att utföra godtycklig kod, så ett annat lösning behövdes.

Denna lösning blev SBAT. Den övergripande idén bakom SBAT är ganska enkel. Varje viktig komponent i boot-kedjan deklarerar en säkerhetsgeneration som inkluderas i den signerade binära filen. När en sårbarhet upptäckts och åtgärdats, ökas denna generation. Då kan en uppdatering släppas som definierar den minimi generationen - boot-komponenterna kommer att titta på nästa element i kedjan, jämföra dess namn och generationsnummer med de som lagras i firmware-variabeln och avgöra om de ska utföra den eller inte baserat på detta. Istället för att återkalla ett stort antal separata hashar kan en enda uppdatering släppas som helt enkelt säger: "Alla versioner av GRUB med säkerhetsgeneration under det här numret betraktas som osäkra."

Varför har detta plötsligt blivit aktuellt? SBAT utvecklades i samarbete mellan Linux-communityt och Microsoft, och Microsoft beslutade att släppa en uppdatering för Windows som instruerade systemen att inte lita på versioner av GRUB med säkerhetsgeneration under en viss nivå. Detta gjordes eftersom dessa versioner av GRUB hade verkliga säkerhetsproblem som gjorde det möjligt för angripare att bryta mot den säkra boot-kedjan för Windows, och vi har sett verkliga exempel på skadlig kod som ville göra just det (Black Lotus utnyttjade en sårbarhet i Windows boot-loader, men sårbarheten i GRUB var lika effektiv). Sett ur ett rent säkerhetsperspektiv är detta en helt legitim önskan.

Nu handlar det om meddelandet «Något gick helt fel» och omöjligheten att starta på grund av den här uppdateringen. Det kommer från shim och inte från någon kod från Microsoft. Shim tar hänsyn till SBAT-uppdateringar, och för att inte bryta mot säkerhetsprinciperna som antagits av andra laddare i systemet, och även om Microsoft har släppt en SBAT-uppdatering, vägrar Linux-laddaren att starta gamla versioner av GRUB. Allt fungerar som det ska.

Problemet som människor har stött på är att flera Linux-distributioner inte har släppt versioner av GRUB med det nyare säkerhetsgenerationen, och därför betraktas dessa versioner av GRUB som osäkra (det är värt att notera att GRUB signeras av distributionerna själva, inte Microsoft, så det finns ingen extern fördröjning här). Microsofts avsikt var att Windows Update-uppdateringen endast skulle tillämpas på system som bara kör Windows, och att alla dualboot-installationer skulle förbli sårbara för attacker tills den installerade distributionen uppdaterade GRUB och säkerhetsgenerationen SBAT. Tyvärr, som nu är uppenbart, fungerade det inte som avsett, och åtminstone vissa dualboot-system tillämpade uppdateringen, medan denna distributionens Shim vägrade att starta den distributionens GRUB.

Vad är slutsatsen? Microsoft (av uppenbara skäl) ville inte att Windows skulle kunna attackeras med en sårbar version av GRUB, som skulle kunna luras till att köra godtycklig kod och sedan införa en bootkit i Windows-kärnan under uppstart. Microsoft gjorde detta genom att släppa en Windows-uppdatering som uppdaterade SBAT-variabeln till att ange att sårbara versioner av GRUB inte får laddas på dessa system. Den första stegets loader som tillhandahålls av distributionen läste denna variabel, läste SBAT-partitionen från den installerade versionen av GRUB, förstod att de var i konflikt och vägrade att ladda grub med meddelandet «Något gick helt fel». Denna uppdatering skulle inte ha tillämpats på system med dualboot, men tillämpades ändå.

I stort:

1) Microsoft tillämpade uppdateringen på system som den inte skulle ha tillämpats på

2) Vissa Linux-distributioner har inte uppdaterat GRUB-laddaren och säkerhetsgenerationen SBAT när sårbarheter upptäcktes i GRUB.

Som resultat har vissa personer problem med att ladda sina system. Jag tror att det finns många skyldiga här. Microsoft borde ha genomfört fler tester för att säkerställa att dual-boot-installationer kan identifieras korrekt. Men även distributioner som levererar signerade laddare måste se till att de uppdaterar dem och uppdaterar säkerhetsgenerationerna så att de stämmer överens, för annars erbjuder de en attackvektor som kan användas för att hacka andra operativsystem, och det är ett slags brott mot det sociala kontraktet kring allt detta.

Tyvärr drabbas här främst slutkonsumenter, som står inför att systemet plötsligt vägrar att ladda det operativsystem de vill använda. Detta får aldrig ske. Jag tror inte att en undersökning bland slutkonsumenter om de vill ha uppdateringar för säker systemstart skulle ge ett bra resultat, och även om jag har en vag känsla av att UEFI säker systemstart inte är något som ger fördelar för de flesta slutkonsumenter, är det också något man inte vill upptäcka efter sådana incidenter. Därför sympatiserar jag med att det är aktiverat som standard, så jag stödjer dess standardaktivering och delar Microsofts val, bortsett från det misslyckade försöket att undvika uppdateringar på system med dual-boot.

I vilket fall som helst var jag djupt involverad i implementeringen av denna mekanism för Linux 2012 och skrev den första prototypen av Shim (som nu är en betydligt bättre bootloader som stöds av en bredare grupp människor, och som jag inte har rört på flera år), så om du vill anklaga någon, var vänlig och tveka inte att anklaga mig. Det här är något som inte skulle ha hänt, och om du inte är Microsoft eller en Linux-distribution, så är det inte ditt fel. Jag ber om ursäkt.

Källa: opennet.ru