Matthew Garrett, známy vývojár jadra Linux, ktorý v minulosti získal od Nadácie otvoreného zdroja ocenenie za prínos k rozvoju slobodného softvéru, hovoril o podstate mechanizmu SBAT (Secure Boot Advanced Targeting), vytvoreného na blokovanie zraniteľností v bootloaderi bez odvolania digitálneho podpisu, ako aj o jeho úlohe v nedávnom incidente s aktualizáciou pre Windows, ktorá viedla k ukončeniu bootovania niektorých distribúcií Linuxu nainštalovaných vedľa Windows na systémoch s aktivovaným UEFI Secure Boot. Stručne povedané, za to môžu ako spoločnosť Microsoft, ktorá aktualizáciu plne netestovala a aplikovala ju na systémy, kde nemala byť aplikovaná, tak aj vývojári niektorých distribúcií Linuxu, ktorí neaktualizovali bootloader GRUB a číslo generácie SBAT, keď v GRUB boli objavené zraniteľnosti.
Následne je preklad poznámky Garretta:
Keď sa vypracovávala špecifikácia UEFI Secure Boot, všetci účastníci boli, povedzme, trochu naivní. Hlavný model bezpečnosti Secure Boot spočíva v tom, že celý kód, ktorý sa spúšťa v privilegovanej prostredí na úrovni jadra, musí byť pred vykonaním overený — firmware overuje bootloader, bootloader overuje jadro, jadro overuje akýkoľvek dodatočne načítaný kód jadra počas vykonávania a teraz máme dôveryhodné prostredie na vynútenie akejkoľvek inej bezpečnostnej politiky, ktorú chceme. Je zrejmé, že ľudia môžu urobiť chyby, ale v špecifikácii bol predpokladaný spôsob odvolania podpísaných komponentov, ktoré sa ukázali ako nedôveryhodné: jednoducho pridajte hash nedôveryhodného kódu do premennej a potom odmietnite načítať čokoľvek s týmto hashom, aj keď je to podpísané dôveryhodným kľúčom.
Bohužiaľ, ako sa ukázalo, problém je v rozsahu. Každá distribúcia Linuxu, ktorá funguje v ekosystéme Secure Boot, generuje vlastné binárne súbory bootloadera, a každý z nich má svoj vlastný hash. Ak sa v zdrojovom kóde takého bootloadera nájde zraniteľnosť, je potrebné odvolať veľké množstvo rôznych binárnych súborov. A objem pamäte na uchovanie premennej, ktorá obsahuje všetky tieto hashe, je obmedzený. Prosto nebude dostatok miesta na pridávanie nového súboru hashov zakaždým, keď sa zistí, že GRUB (bootloader, ktorý bol pôvodne napísaný v dobách, keď sa ešte nepraktizovala ochrana bootu a má niekoľko oddelených parserov img-obrazov, ako aj parser písma) má ďalší mechanizmus pre útočníka, aby ho prinútil vykonať ľubovoľný kód, preto bolo potrebné iné riešenie.
Týmto riešením sa stal SBAT. Celková koncepcia SBAT je dosť jednoduchá. Každá dôležitá súčásť v reťazci bootovania deklaruje bezpečnostnú generáciu, ktorá je zahrnutá v podpísanom binárnom súbore. Keď sa zraniteľnosť nájde a odstráni, táto generácia sa zvýši. Následne je možné vydať aktualizáciu, ktorá určuje minimálnu generáciu — komponenty bootovania sa budú pozerať na nasledujúcu položku v reťazci, porovnávať jej názov a číslo generácie s tými, ktoré sú uložené v premennej firmvéru, a rozhodovať, či ju spustiť alebo nie na základe toho. Namiesto odvolávania veľkého množstva jednotlivých hashov je možné vydať jednu aktualizáciu, ktorá jednoducho hovorí: „Akákoľvek verzia GRUB s bezpečnostnou generáciou nižšou ako toto číslo sa považuje za nedôveryhodnú.
Prečo sa to vlastne stalo aktuálnym? SBAT bol vyvinutý spoločne komunitou Linuxu a Microsoftom, pričom Microsoft sa rozhodol vydať aktualizáciu pre Windows, ktorá hovorila systémom, aby nedôverovali verziám GRUB s bezpečnostnou generáciou nižšou ako určitá úroveň. Urobilo sa to preto, že tieto verzie GRUB mali skutočné bezpečnostné zraniteľnosti, ktoré umožňovali útočníkom narušiť reťazec bezpečného bootovania Windows, a videli sme skutočné príklady malvéru, ktorý sa snažil to urobiť (Black Lotus využil zraniteľnosť v bootloaderi Windows, ale zraniteľnosť v GRUB bola rovnako účinná). Ak sa na to pozrieme čisto z pohľadu bezpečnosti, je to úplne legitímna požiadavka.
Pokiaľ ide o hlásenie „Niečo sa pokazilo“ a nemožnosť načítať v dôsledku tejto aktualizácie, je to správa z programu shim, a nie z nejakého kódu od Microsoftu. Shim zohľadňuje aktualizácie SBAT a aby sa nedodávali žiadne narušenia bezpečnostných zásad, ktoré prijali ostatné bootloadery v systéme. Aj keď Microsoft vydal aktualizáciu SBAT, to je bootloader Linuxu, ktorý nakoniec odmieta spustiť staršie verzie GRUB. Všetko funguje tak, ako má.
Problém, s ktorým sa ľudia stretli, spočíva v tom, že niekoľko distribúcií Linuxu nevydalo verzie GRUB s novšou generáciou zabezpečenia, a preto sú tieto verzie GRUB považované za nebezpečné (je potrebné poznamenať, že GRUB je podpísaný samotnými distribúciami, a nie Microsoftom, takže tu nie je žiadne vonkajšie zdržanie). Podľa Microsoftu mala aktualizácia Windows Update aplikovať aktualizáciu SBAT iba na systémy, ktoré fungujú iba s Windowsom, a akékoľvek inštalácie s dvojitým zavedením by zostali zraniteľné voči útokom, pokiaľ nainštalovaná distribúcia neaktualizuje GRUB a nezmení generáciu SBAT. Bohužiaľ, ako je teraz zrejmé, toto nefungovalo tak, ako sa zamýšľalo, a aspoň niektoré systémy s dvojitým zavedením použili aktualizáciu, ale Shim tejto distribúcie odmietol načítať GRUB tejto distribúcie.
Aký je záver? Microsoft (z pochopiteľných dôvodov) nechcel, aby bol Windows zraniteľný prostredníctvom zraniteľnej verzie GRUB, ktorú by bolo možné podvodom presvedčiť, aby vykonala ľubovoľný kód, a potom by mohla integrovať bootkit do jadra Windows počas bootovania. Microsoft to dosiahol vydaním aktualizácie Windows, ktorá aktualizovala premennú SBAT, uvádzajúcu, že zraniteľné verzie GRUB by sa nemali na týchto systémoch spúšťať. Bootloader prvého štádia poskytnutý distribúciou Shim túto premennú prečítal, prečítal sekciu SBAT z nainštalovanej verzie GRUB, pochopil, že sú v konflikte, a odmietol načítať grub so správou „Niečo sa pokazilo“. Táto aktualizácia sa nemala aplikovať na systémy s dvojitým zavedením, ale aj tak sa aplikovala.
Celkovo:
1) Microsoft použil aktualizáciu na systémy, na ktoré sa nemala aplikovať
2) Niektoré distribúcie Linuxu neaktualizovali bootloader GRUB a generáciu zabezpečenia SBAT, keď boli v GRUB zistené zraniteľnosti.
V dôsledku toho niektorí ľudia nemôžu načítať svoje systémy. Myslím si, že tu je mnoho vinníkov. Microsoft by mal vykonať viac testov, aby sa uistil, že inštalácie s dual boot môžu byť presne identifikované. Distribúcie, ktoré dodávajú podpísané bootovacie súbory, by sa mali tiež uistiť, že ich aktualizujú a obohacujú o bezpečnostné opravy, aby zodpovedali, pretože inak poskytujú vektor útoku, ktorý môže byť použitý na napadnutie iných operačných systémov, a to je akési porušenie verejnej dohody okolo toho všetkého.
Žiaľ, obeťami sú tu predovšetkým koncoví používatelia, ktorí sa stretávajú s tým, že systém náhle odmieta načítať ten operačný systém, ktorý chcú načítať. K tomu by nikdy nemalo dôjsť. Nemyslím si, že prieskum koncových používateľov ohľadom toho, či chcú aktualizácie zabezpečenej spúšťania, prinesie dobrý výsledok, a hoci sa jemne prikláňam k názoru, že zabezpečené spúšťanie UEFI nie je niečo, čo prináša prospech väčšine koncových používateľov, je to i tak niečo, čo by ste nechceli objaviť po takýchto incidentoch, takže súcitim s tým, že je to zapnuté predvolene, a preto podporujem jeho predvolené zapnutie a delím sa o voľbu Microsoftu, okrem neúspešného pokusu vyhnúť sa aktualizáciám na systémoch s dual boot.
V každom prípade som bol silne zapojený do implementácie tohto mechanizmu pre Linux v roku 2012 a napísal som prvý prototyp Shim (ktorý je teraz výrazne lepší bootloader, podporovaný širším okruhom ľudí, a ktorého som sa nedotkol už niekoľko rokov), takže ak chcete obviniť niekoho konkrétneho, pokojne ma obviňte. To je niečo, čo sa nemalo stať, a ak nie ste Microsoft alebo distribúcia Linux, nie je to vaša vina. Ospravedlňujem sa.
Zdroj: opennet.ru
