Matthew Garrett, tuntud Linuxi tuumikaarendaja, kes on saanud avatud lähtekoodiga tarkvara fondilt auhinna oma panuse eest, rääkis SBAT (Secure Boot Advanced Targeting) mehhanismi olemusest, mille eesmärk on takistada haavatavusi buutimisprotsessis ilma digitaalse allkirja tühistamiseta, samuti selle rollist hiljutises Windowsi uuenduse intsidendis, mis viis mitmete Linuxi distributsioonide lõpetamiseni, kui need olid paigaldatud koos Windowsiga UEFI Secure Boot'iga süsteemides. Lühidalt öeldes on süüdi nii Microsoft, kes ei testinud uut versiooni põhjalikult ja rakendas seda süsteemidele, kuhu see ei pidanud minema, kui ka mitmete Linuxi distributsioonide arendajad, kes ei uuendanud GRUB'i buutijat ja SBAT'i versiooninumbrit, kui GRUB'is avastati haavatavused.
Allpool on Garrett'i märkme tõlge:
Liikudes UEFI Secure Boot spetsiifikatsiooni arendamise suunas, olid kõik selles osalejad, ütleme, veidi naiivsed. Secure Booti põhiturvamudel seisneb selles, et kogu kood, mis käivitatakse privileegitud keskkonnas tuumatasemel, peab olema enne täitmist kontrollitud — püsivara kontrollib laadijat, laadija kontrollib tuuma, tuum kontrollib kõiki täiendavaid käitusaja koodi osi, ja nüüd on meil usaldusväärne keskkond, et rakendada kõiki soovitud turvapoliitikaid. Ilmselgelt võivad inimesed eksida, kuid spetsiifikatsioonis oli ette nähtud viis tagasivõtmiseks usaldusväärsuse kaotanud allkirjastatud komponente: lihtsalt lisage usaldusväärse koodi rikutud hüüdnimi muutuja, ja seejärel keelduge laadimast midagi selle hüüdnimega, isegi kui see on usaldusväärse võtmega allkirjastatud.
Kahjuks selgus, et probleem on ulatuslik. Iga Linuxi distributsioon, mis töötab Secure Boot ökosüsteemis, genereerib omaenda laadimisfailide binaarfailid ja igaühel neist on oma hash. Kui sellise laadimisprogrammi lähtekoodist avastatakse turvaviga, tuleb tagasi kutsuda suur hulk erinevaid binaarfailide versioone. Kuid mälu, mis on ette nähtud muutujale, mis sisaldab kõiki neid hashe, on piiratud. Lihtsalt ei jätku ruumi igakord, kui selgub, et GRUB'il (laadimisprogramm, mis kirjutati algselt ajal, mil buude kaitsmine ei olnud veel praktikas, ja millel on mitu eraldi img-piltide parsijat ning ka fondide parsija) on veel üks mehhanism ründajale, et sundida seda täitma käske, seetõttu oli vajalik teine lahendus.
Selle lahenduse nimi on SBAT. SBAT’i üldine kontseptsioon on üsna lihtne. Iga oluline komponent laadimistööl nõuab turvageneratsiooni, mis on lisatud allkirjastatud binaarfaili. Kui haavatavus tuvastatakse ja kõrvaldatakse, suureneb see generatsioon. Siis saab välja anda uuenduse, mis määratleb minimaalset generatsiooni — laadimiskomponendid vaatavad järgmise elemendi poole ahelas, võrdlevad selle nime ja generatsiooninumbrit nende nimedega, mis on salvestatud firware muutuja, ning otsustavad, kas seda teostada või mitte. Selle asemel, et tühistada suures koguses üksikuid hash'e, saab välja anda ühe uuenduse, mis lihtsalt ütleb: "Kumbki GRUB'i versioon, mille turvageneratsioon on alla selle numbri, loetakse usaldamatuks."
Miks see siis äkki aktuaalseks muutus? SBAT töötati välja koostöös Linuxi ja Microsofti kogukonnaga, ning Microsoft otsustas vabastada Windowsi värskenduse, mis käskis süsteemidel mitte usaldada GRUB versioone, mille turvageneraator oli madalamal tasemel. See tehti selle tõttu, et need GRUB versioonid omasid reaalseid turvaauke, mis võimaldasid kurjategijatel rikkuda Windowsi turvakihti, ja oleme näinud reaalseid näiteid pahavara, mis soovis seda teha (Black Lotus kasutas Windowsi laadija haavatavust, kuid GRUB-i haavatavus oli sama efektiivne). Kui sellele puhtalt turvalisuse aspektist vaadata, on see täiesti mõistetav soov.
Nüüd, mis puutub sõnumisse „Midagi läks täiesti valesti” ja käivitusprobleemidesse, mis tekivad selle värskenduse tõttu. Selle genereerib shim, mitte mingi Microsofti kood. Shim arvestab SBAT värskendusi, ja et mitte rikkuda turvapõhimõtteid, mida teised laadijad süsteemis järgivad, ja kuigi Microsoft vabastas SBAT värskenduse, tõrjub Linuxi laadija vanade GRUB versioonide käivitamise. Kõik töötab nagu peab.
Inimene on silmitsi seisnud probleemiga, et mitmed Linuxi distributsioonid ei ole välja andnud uuematele turvageneratsioonidele vastavaid GRUB versioone, seetõttu peetakse neid GRUB versioone ebaturvalisteks (tähelepanuväärne on, et GRUB allkirjastavad ise distributsioonid, mitte Microsoft, mistõttu ei ole siin mingit väljastpoolt tulnud mahajäämust). Microsofti kavatsus oli, et Windows Update rakendab SBAT uuendust ainult süsteemidele, mis töötavad ainuüksi Windowsiga, ning kõik topeltbuutimise seadistused jääksid ründamistele avatud seni, kuni installitud distributsioon uuendab GRUB-i ja SBAT-i põlvkonda. Kahjuks, nagu nüüdsel ajal on selge, ei töötanud see nii, nagu oli plaanitud, ja vähemalt mõnede topeltbuutimise seadistustega süsteemide puhul rakendati uuendus, samas kui selle distributsiooni Shim keeldus selle distributsiooni GRUB-i laadimisest.
Mis on peamine järeldus? Microsoft (mõistlikel põhjustel) ei soovinud, et Windowsi oleks võimalik rünnata haavatava GRUB-i versiooniga, mida saaks petta, et käivitada juhuslik kood ja seejärel sisestada Windowsi tuumasse bootkit käivitamise ajal. Microsoft tegi seda, vabastades Windowsi värskenduse, mis uuendas SBAT muutujat, märkides, et haavatavad GRUB-i versioonid ei tohi nende süsteemidel käivituda. Shim‘i poolt pakutav esmane laadija luges selle muutuja, luges GRUB-i installitud koopia SBAT jagu, mõistis, et need on konfliktis, ning keeldus grub-i käivitamast, kuvades sõnumi „Midagi on päris valesti.“ Seda uuendust ei tohi rakendada kahekordse käivitamise süsteemidel, kuid see siiski rakendati.
Üldiselt:
1) Microsoft rakendas värskenduse süsteemidele, kellele see ei pidanud kehtima
2) Mõned Linuxi distributsioonid ei uuendanud GRUB laadijat ja SBAT turvaseadet, kui GRUB-is avastati haavatavusi.
Mõned inimesed ei saa oma süsteeme käivitada. Arvan, et siin on palju süüdlasi. Microsoft peaks tegema rohkem teste, et veenduda, et kahekordse käivitamise seadistusi saab õigesti tuvastada. Kuid ka jaotused, mis tarnivad allkirjastatud alglaadijat, peavad veenduma, et nad uuendavad neid ja ajakohastavad turvageneratsiooni, et need vastaksid, kuna vastasel juhul pakuvad nad rünnakuvektori, mida saab kasutada teiste operatsioonisüsteemide rikkumiseks, ja see on omamoodi avaliku lepingu rikkumine kõigi nende suhtes.
Kahjuks on siin peamiselt kannatajateks lõppkasutajad, kes seisavad silmitsi olukorraga, kus süsteem keeldub ootamatult laadimast soovitud operatsioonisüsteemi. Seda ei tohiks kunagi juhtuda. Ma ei arva, et lõppkasutajate küsitlus selle kohta, kas nad soovivad turvalise käivitamise süsteemuuendusi, toob head tulemust ning kuigi ma olen häguselt kaldunud arvama, et UEFI turvaline käivitamine ei ole midagi, mis looks kasu enamikule lõppkasutajatest, on see ka asi, mille avastamine pärast selliseid sündmusi ei oleks soovitav. Seetõttu kaastundan, et see on vaikimisi lubatud, ning toetan selle vaikimisi lubamist, jagades Microsofti valikuid, välja arvatud ebaõnnestunud katse vältida uuendust kahekordse käivitamise süsteemides.
Igal juhul oli mul 2012. aastal Linuxi jaoks selle mehhanismi elluviimisega palju tegemist ja ma kirjutasin esimese Shim prototüübi (mis on nüüd oluliselt parem laadija, mida toetab laiem inimeste ring ja mida ma ei ole juba mitu aastat puudutanud), nii et kui soovite kedagi süüdistada, siis palun ärge kartke mind süüdistada. See on asi, mida ei oleks pidanud juhtuma, ja kui te ei ole Microsoft või Linuxi distributsioon, pole see teie süü. Vabandust.
Allikas: opennet.ru
