SBAT mõiste ja Windowsi värskendamisega seotud probleemide analüüs, mis mõjutas Linuxi käivitamist

Matthew Garrett, tuntud Linuxi tuuma arendaja, kes on saanud avatud lähtekoodiga tarkvara fondilt preemia oma panuse eest vabasi tarkvara arengusse, rääkis SBAT (Secure Boot Advanced Targeting) mehhanismi olemusest, mis on loodud haavatavuste blokeerimiseks alglaadijates ilma digitaalse allkirja tühistamiseta, samuti selle rollist hiljutises Windowsi värskenduse intsidentsis, mis tõi kaasa teatud Linuxi distributsioonide käivitamise peatamise, kui need olid paigaldatud koos Windowsiga UEFI Secure Booti aktiveeritud süsteemidesse. Lühidalt öeldes on süüdi nii Microsoft, kes ei testinud värskendust täielikult ja rakendas seda süsteemidele, millele see ei pidanud sobima, kui ka mõningate Linuxi distributsioonide arendajad, kes ei uuendanud GRUBi alglaadijat ja SBAT-i põlvkonna numbrit, kui GRUBis avastati haavatavused.

Allpool on Garrett'i märkme tõlge:

Kui töötati välja UEFI Secure Boot spetsifikatsiooni, olid kõik osalised, ütleme, natuke naiivsed. Secure Booti peamine turvamudel on, et kogu kood, mis käivitatakse privileeetsetes keskkondades tuuma tasemel, peab olema enne täitmist kontrollitud - püsivara kontrollib alglaadijat, alglaadija kontrollib tuuma, tuum kontrollib igasugust täiendavat koodi, mis laaditakse täitmise ajal, ja nüüd on meil usaldusväärne keskkond, kus saame kehtestada iga teise soovitud turvapoliitika. Ilmselgelt võivad inimesed eksida, kuid spetsifikatsioonis oli ette nähtud viis allkirjastatud komponente, mis on osutunud usaldusväärseteks, tühistamiseks: lihtsalt lisage vale koodi hash muutujasse ja siis keelduda laadimast midagi, millel on see hash, isegi kui see on allkirjastatud usaldusväärse võtmega.

Kahjuks selgus, et probleem on ulatuses. Iga Linuxi distributsioon, mis töötab Secure Boot ökosüsteemis, genereerib oma enda käivitusfailid, ja igal neist on oma hash. Kui sellise käivitusfaili lähtekoodist avastatakse haavatavus, tuleb tagasi kutsuda suur hulk erinevaid käivitusfaile. Ja mälumaht muutujale, mis sisaldab kõiki neid hase, on piiratud. Lihtsalt ei piisa ruumist, et iga kord, kui selgub, et GRUB-il (käivituslaadur, mis kirjutati algselt ajal, mil turvaloomine ei olnud praktikas, ja millel on mitu eraldi pildifailide parserit, samuti fondide parser) on veel üks mehhanism ründaja jaoks, et sundida seda käivitama suvalist koodi, on vajalik teine lahendus.

Selle lahenduseks sai SBAT. SBATi üldine kontseptsioon on üsna lihtne. Iga oluline komponent käivitusprotsessis kuulutab välja turvageneratsiooni, mis lisatakse allkirjastatud binaarfailile. Kui haavatavus avastatakse ja kõrvaldatakse, suurendatakse seda generatsiooni. Siis saab välja anda värskenduse, mis määrab miinimumgeneratsiooni – käivituskomponendid vaatavad järgmist elementi ahelas, võrdlevad selle nime ja generatsiooni numbrit sellega, mis on salvestatud firmware muutuja juurde, ja otsustavad, kas seda käivitada või mitte, tuginedes sellele. Selle asemel, et tagasi kutsuda suurt hulka eraldi hase, saab välja anda ühe värskenduse, mis lihtsalt ütleb: "Iga versioon GRUB-ist, mille turvageneratsioon on alla selle numbri, loetakse usaldamatuks."

Kusjuures, miks see äkki aktuaalseks sai? SBAT töötati välja koos Linuxi kogukonna ja Microsoftiga, ning Microsoft otsustas välja anda Windowsi värskenduse, mis käsitles süsteemidele GRUB-i versioone, mille turvageneratsioon on allpool määratud taset, mitte usaldama. See tehti sellepärast, et need GRUB-i versioonid sisaldasid reaalset turvaaukude, mis lubasid kurjategijatel rikkuvalt Windowsi turvaloomise protsessi, ja me nägime tõelisi näiteid pahavarast, mis soovis seda teha (Black Lotus kasutas Windowsi käivituslaadurit, kuid haavatavus GRUB-is oli sama tõhus). Kui vaadata seda puhtalt turvalisuse seisukohalt, on see täiesti põhjendatud soov.

Mis sellest tegelikult räägib see sõnum "Midagi läks tõeliselt valesti" ja selle pärast, et see uuendus ei laadinud alla. Selle kuvab shim, mitte mõni Microsofti kood. Shim arvestab SBAT uuendusi ja et mitte rikkuda turvaprintsiipe, mis kehtivad teiste süsteemide laadijate puhul, ja kuigi Microsoft on välja andnud SBAT uuenduse, lükkab Linuxi laadija seetõttu tagasi vanemate GRUB versioonide käivitamise. Kõik toimib nagu peab.

Probleem, millega inimesed silmitsi seisavad, on see, et mitmed Linuxi distributsioonid ei ole välja andnud GRUB versiooni, kus on uusim turvageneratsioon, ning seetõttu peetakse neid GRUB versioone ebaturvalisteks (tuleb märkida, et GRUB allkirjastavad endi distributsioonid, mitte Microsoft, seega ei ole siin väljastpoolt tulnud viivitust). Microsofti plaanitult pidi Windows Update rakendama SBAT uuendust ainult süsteemidele, mis töötavad ainult Windowsiga, ja kõik topeltbooteerimisseaded jääksid rünnakute suhtes haavatavaks, kuni installitud distributsioon ei uuenda GRUB-i ja ei uuenda SBAT generaatorit. Kahjuks, nagu on nüüd selge, ei töötanud see nii nagu oli plaanitud, ja vähemalt mõned topeltbooteerimisseadmed rakendasid uuenduse, kuid selle distributsiooni Shim keeldus selle distributsiooni GRUB-i laadimast.

Mis on lõppkokkuvõte? Microsoft (ilmselgetel põhjustel) ei soovinud, et Windowsi saaks rünnata haavatava GRUB versiooni abil, mida saaks petta, et see täidaks käsu suvalise koodi käivitamiseks, ning seejärel seadistada bootkit Windowsi tuuma algusesse laadimise ajal. Microsoft saavutas selle, avaldades Windowsi uuenduse, mis uuendas SBAT muutujat, märkides, et haavatavad GRUB versioonid ei tohiks nende süsteemides käivituda. Distributsiooni poolt pakutav Shim laadija esimeses etapis luges selle muutuja, luges SBAT jaotise paigaldatud GRUB-i kopeerimisest, mõistis, et need on konfliktis ja keeldus GRUB-i laadimast, kuvades sõnumi "Midagi läks tõeliselt valesti". See uuendus ei pidanud kehtima topeltbooteerimisseadmete jaoks, kuid siiski rakendati seda.

Kokkuvõttes:

1) Microsoft rakendas uuendust süsteemidele, millele see ei pidanud rakenduma

2) Teatud Linuxi distributsioonid ei uuendanud GRUB laadijat ja SBAT turvageneratsiooni, kui GRUB-is tuvastati haavatavused.

Mõned kasutajad ei saa oma süsteeme käivitada. Usun, et siin on palju süüdlasi. Microsoft peaks tegema rohkem teste, et veenduda, et kahekordse käivitamise seadistused on õigesti määratletud. Samuti peaksid jaotised, mis toimetavad sertifitseeritud boot'lid, veenduma, et nad uuendavad neid ja teevad turvageneratsiooni, et see vastaks nõuetele. Vastasel juhul pakuvad nad ründevektori, mida saab kasutada teiste operatsioonisüsteemide häkkimiseks, ja see on teatud mõttes ühiskondliku kokkuleppe rikkumine kogu selle asja ümber.

Kahjuks on peamiselt lõppkasutajad need, kes kannatavad, kui süsteem keeldub ootamatult laadimast OS-i, mida nad soovivad käivitada. Sedasi ei peaks kunagi juhtuma. Ma ei arva, et lõppkasutajatelt küsima, kas nad soovivad süsteemi turvakäivitamise uuendusi, tooks head tulemust. Kuigi ma kalduksin arvama, et UEFI turvakäivitamine ei too enamusele lõppkasutajatest kasu, on see siiski asi, mida te ei taha avastada selliste juhtumite järel. Seetõttu kaastunde pärast, et see on vaikimisi aktiveeritud, toetangi selle vaikimisi lubamist ja jagan Microsofti valikut, välja arvatud ebaõnnestunud katse vältida uuendusi kahekordse käivitamise süsteemidel.

Igal juhul olin tugevalt seotud selle mehhanismi rakendamisega Linuxis 2012. aastal ning kirjutasin esimese prototüübi Shim (mis on tänapäeval palju parem käivitaja, mida toetab laiem inimgrupp ja mida ma pole juba mitu aastat puudutanud). Nii et kui soovite kedagi süüdistada, siis palun ärge kartke mind süüdistada. See ei oleks pidanud juhtuma, ja kui te ei ole Microsoft või Linuxi jaotus, siis see ei ole teie süü. Vabandan.

Allikas: opennet.ru