Matthew Garrett, den kendte Linux-kernudvikler, som engang modtog en pris fra Free Software Foundation for sit bidrag til udviklingen af gratis software, fortalte om essensen af SBAT (Secure Boot Advanced Targeting) mekanismen, der er skabt til at blokere sårbarheder i bootloaderen uden at tilbagekalde den digitale underskrift, samt dens rolle i det nylige incident med en opdatering til Windows, som førte til, at nogle Linux-distributioner, der var installeret parallelt med Windows på systemer med aktiveret UEFI Secure Boot, ikke længere kunne starte. Kort sagt, både Microsoft, som ikke fuldt ud testede opdateringen og anvendte den på systemer, den ikke burde anvendes på, samt udviklerne af nogle Linux-distributioner, som ikke opdaterede GRUB bootloaderen og SBAT generationen, da der blev opdaget sårbarheder i GRUB, bærer skylden.
Herunder er oversættelsen af Garretts notat:
Da specifikationen for UEFI Secure Boot blev udviklet, var alle deltagere, lad os sige, lidt naiv. Den grundlæggende sikkerhedsmodel for Secure Boot er, at al kode, der kører i en privilegeret miljø på kerne-niveau, skal verificeres før eksekvering — firmwaren verificerer bootloaderen, bootloaderen verificerer kernen, kernen verificerer al anden kode, der indlæses ved kørsel, og nu har vi et betroet miljø til at håndhæve enhver anden sikkerhedspolitik, vi ønsker. Det er åbenlyst, at mennesker kan fejle, men i specifikationen var der en måde at tilbagekalde underskrevne komponenter, der viste sig at være usikre: tilføj blot hash’en af den kompromitterede kode til en variabel, og nægt derefter at indlæse noget med denne hash, selvom det er underskrevet med en betroet nøgle.
Desværre viste det sig, at problemet er i skalaen. Hver Linux-distribution, der kører i Secure Boot-økosystemet, genererer sine egne binære boot-filer, og hver af dem har sin egen hash. Hvis der opdages en sårbarhed i kildeteksten til en sådan boot-fil, skal et stort antal forskellige binære filer tilbagekaldes. Og hukommelsen til at gemme variablen, der indeholder alle disse hashes, er begrænset. Der er ganske enkelt ikke plads til at tilføje et nyt sæt hashes hver gang det viser sig, at GRUB (bootloader, der oprindeligt blev skrevet i en tid, hvor sikker boot ikke blev praktiseret, og som har flere separate parsere til img-billeder samt en font-parser) har en mekanisme til, at en angriber kan få den til at udføre vilkårlig kode, så der var brug for en anden løsning.
Denne løsning blev SBAT. Den overordnede koncept for SBAT er ret enkel. Hver vigtig komponent i opstartskæden erklærer en sikkerhedsgeneration, som bliver inkluderet i den signeret binære fil. Når en sårbarhed opdages og udbedres, øges denne generation. Herefter kan der udgives en opdatering, der definerer den minimale generation — opstarts komponenterne vil se på den næste element i kæden, sammenligne dets navn og generationsnummer med dem, der er gemt i firmware-variablen, og beslutte, om de skal udføre det eller ej, baseret på dette. I stedet for at tilbagekalde et stort antal separate hashes kan der udgives én opdatering, der simpelthen siger: «Enhver version af GRUB med en sikkerhedsgeneration under dette nummer betragtes som uudtalt.»
Hvorfor er dette blevet aktuelt? SBAT blev udviklet i samarbejde mellem Linux-samfundet og Microsoft, og Microsoft besluttede at udgive en opdatering til Windows, der fortalte systemerne ikke at stole på versioner af GRUB med en sikkerhedsgeneration under et bestemt niveau. Dette blev gjort, fordi disse versioner af GRUB havde reelle sikkerhedssårbarheder, der tillod angribere at bryde den sikre boot kæde i Windows, og vi har set reelle eksempler på malware, der ønskede at gøre dette (Black Lotus udnyttede en sårbarhed i Windows-bootloaderen, men sårbarheden i GRUB var lige så effektiv). Set udelukkende fra et sikkerhedsmæssigt synspunkt er dette et fuldt lovligt ønske.
Når det kommer til meddelelsen "Noget gik helt galt" og den manglende indlæsning som følge af denne opdatering, er den genereret af shim, ikke af en kode fra Microsoft. Shim tager højde for SBAT-opdateringer, og for ikke at bryde sikkerhedsprincipperne, der er vedtaget af andre bootloadere i systemet. Selvom Microsoft har udgivet en SBAT-opdatering, nægter Linux-bootloaderen derfor at starte ældre versioner af GRUB. Alt fungerer, som det skal.
Problemet, som folk er stødt på, er, at flere Linux-distributioner ikke har udgivet versioner af GRUB med det nyere sikkerhedsgeneration, og derfor betragtes disse versioner af GRUB som usikre (det er værd at bemærke, at GRUB signeres af distributionerne selv, ikke af Microsoft, så der er ingen ekstern forsinkelse her). Tanken bag Microsoft var, at Windows Update skulle anvende SBAT-opdateringen kun på systemer, der udelukkende kører Windows, og at dobbeltboot-installationer ville forblive sårbare over for angreb, indtil den installerede distribution opdaterede GRUB og opdaterede SBAT-generationen. Desværre, som det nu er åbenlyst, fungerede det ikke som tilsigtet, og i det mindste nogle dobbeltboot-systemer anvendte opdateringen, mens denne distributions Shim nægtede at indlæse denne distributions GRUB.
Hvad er konklusionen? Microsoft (af åbenlyse grunde) ønskede ikke, at Windows skulle være sårbart over for angreb ved hjælp af en usikker version af GRUB, der kunne narres til at udføre vilkårlig kode og derefter indføre en bootkit i Windows-kernen under opstart. Microsoft gjorde dette ved at udgive en Windows-opdatering, som opdaterede SBAT-variablet, og angav, at sårbare versioner af GRUB ikke måtte indlæses på disse systemer. Den leverede bootloader fra distributionens Shim læste denne variabel, læste SBAT-sektionen fra den installerede GRUB-kopi, forstod, at de var i konflikt, og nægtede at indlæse grub med meddelelsen "Noget gik helt galt". Denne opdatering skulle ikke have været anvendt på dobbeltboot-systemer, men blev det alligevel.
Generelt:
1) Microsoft anvendte opdateringen på systemer, den ikke skulle anvendes på.
2) Nogle Linux-distributioner opdaterede ikke GRUB-bootloaderen og SBAT-sikkerhedsgenerationen, da der blev opdaget sårbarheder i GRUB.
Som nogle mennesker ikke kan starte deres systemer. Jeg mener, at der er mange skyldige her. Microsoft burde have gennemført flere tests for at sikre, at dual-boot installationer kan identificeres korrekt. Men også distributioner, der leverer signerede bootloadere, skal sørge for at opdatere dem og opdatere sikkerhedsgenerationen for at leve op til dette, fordi ellers giver de en angrebsvinkel, der kan bruges til at hacke andre operativsystemer, og det er en slags brud på den sociale kontrakt omkring dette.
Desværre bliver de primært berørte her slutbrugere, der står over for, at systemet pludselig nægter at starte den OS, de ønsker at indlæse. Dette bør aldrig ske. Jeg mener ikke, at en undersøgelse blandt slutbrugerne om, hvorvidt de ønsker opdateringer af sikkerhedsboot, vil føre til et godt resultat, og selvom jeg svagt hælder til, at sikker boot UEFI ikke er noget, der gavner de fleste slutbrugere, er det også noget, man ikke ønsker at opdage efter sådanne hændelser, så jeg sympatiserer med det, at det er aktiveret som standard, derfor støtter jeg, at det er aktiveret som standard, og jeg deler Microsofts valg, undtagen den mislykkede forsøg på at undgå opdatering på systemer med dual-boot.
Uanset hvad, var jeg stærkt involveret i implementeringen af denne mekanisme for Linux i 2012 og skrev den første prototype af Shim (som nu er en meget bedre bootloader, der understøttes af et bredere udvalg af mennesker, og som jeg ikke har rørt ved i flere år), så hvis du vil bebrejde én person, så tøv ikke med at bebrejde mig. Dette skulle ikke have været sket, og hvis du ikke er Microsoft eller en Linux distribution, er det ikke din skyld. Jeg undskylder.
Kilde: opennet.ru
