Matthew Garrett, a Linux kernel neves fejlesztője, aki valaha a Szabad Szoftver Alapítványtól díjat kapott a szabad szoftverek fejlesztéséhez való hozzájárulásért, beszélt a SBAT (Secure Boot Advanced Targeting) mechanizmus lényegéről, amelyet a betöltőprogramok sérülékenységeinek blokkolására hoztak létre anélkül, hogy visszavonnák a digitális aláírást, valamint a Windows legutóbbi frissítésével kapcsolatos eseményről, amely a Linux egyes disztribúcióinak indításának leállításához vezetett, amelyeket párhuzamosan telepítettek Windowszal UEFI Secure Boot engedélyezett rendszereken. Röviden, mind a Microsoft, amely nem tesztelte teljesen a frissítést, és alkalmazta azt olyan rendszereken, amelyekre azt nem szánták, mind pedig néhány Linux disztribúció fejlesztői, akik nem frissítették a GRUB betöltőprogramot és a SBAT generációs számát, amikor a GRUB-ban sérülékenységeket fedeztek fel, felelős a problémáért.
Alább olvasható Garrett megjegyzésének fordítása:
Amikor az UEFI Secure Boot specifikációnak a fejlesztését végezték, a résztvevők, mondhatni, kissé naivak voltak. A Secure Boot biztonsági modellje lényege, hogy minden kódot, amely a kernel szintű privilegizált környezetben fut, végrehajtás előtt ellenőrizni kell — a firmware ellenőrzi a betöltőprogramot, a betöltőprogram ellenőrzi a kernelt, a kernel pedig bármely további, futás közben betöltött kernel kódot ellenőriz. Így most már van egy megbízható környezetünk, ahol bármilyen más biztonsági politikát érvényesíthetünk, amit csak akarunk. Nyilvánvaló, hogy az emberek hibázhatnak, de a specifikációban volt mód a megbízhatatlan aláírt komponensek visszavonására: egyszerűen hozzá kell adni a megbízhatatlan kód hashét egy változóhoz, majd nem szabad semmit betölteni ezzel a hash-el, még akkor sem, ha azt megbízható kulccsal írták alá.
Sajnos, ahogy kiderült, a probléma a méretben rejlik. Minden Linux disztribúció, amely a Secure Boot ökoszisztémában működik, saját betöltőbináris fájljait generálja, és mindegyiknek megvan a saját hash értéke. Ha a betöltő forráskódjában sebezhetőséget találnak, akkor számos különböző bináris fájl visszavonására van szükség. Az összes ezen hash-eket tartalmazó változó tárolására szánt memória mennyisége pedig korlátozott. Egyszerűen nem elég a hely új hash-sorozatok hozzáadásához, amikor kiderül, hogy a GRUB (a betöltő, amelyet eredetileg azon időkben írtak, amikor még nem volt gyakorlat a betöltési védelem, és több különálló img-fájl elemzője, valamint betűtípus elemzője is volt) újabb mechanizmust kínál a támadóknak, hogy lehetővé tegyék számára tetszőleges kód végrehajtását, ezért más megoldásra volt szükség.
Ez a megoldás a SBAT lett. A SBAT általános koncepciója meglehetősen egyszerű. Minden fontos alkotóelem a betöltési láncban bejelenti a biztonsági generációt, amely be van építve az aláírt bináris fájlba. Amikor egy sebezhetőséget felfedeznek és megoldanak, ez a generáció növekszik. Ezután ki lehet adni egy frissítést, amely meghatározza a minimális generációt — a betöltőelemzők a lánc következő elemére néznek, és összehasonlítják annak nevét és generációs számát a firmware-ben tárolt adatokkal, majd ennek alapján döntik el, hogy végrehajtják-e vagy sem. Ahelyett, hogy sok különálló hash-t vonnának vissza, ki lehet adni egy frissítést, amely egyszerűen kimondja: „Bármely GRUB verzió, amelynek biztonsági generációja alacsonyabb ennél a számnál, megbízhatatlannak tekintendő.”
Miért lett ez hirtelen aktuális? A SBAT-ot a Linux közösség és a Microsoft közösen fejlesztette ki, és a Microsoft úgy döntött, hogy kiad egy frissítést a Windows számára, amely azt mondta a rendszereknek, hogy ne bízzanak a GRUB verziókban, amelyek biztonsági generációja egy adott szint alatt van. Ezt azért tették, mert ezek a GRUB verziók valós biztonsági sebezhetőségekkel rendelkeztek, amelyek lehetővé tették a támadók számára, hogy megsértsék a Windows biztonságos indítási láncát, és láttunk tényleges példákat arra, hogy a rosszindulatú szoftverek ezt meg akarták tenni (a Black Lotus kihasználta a Windows betöltő sebezhetőségét, de a GRUB sebezhetősége is ugyanolyan hatékony volt). Ha ezt tisztán biztonsági szempontból nézzük, teljesen ésszerű kívánság.
Amit a "Valami teljesen rosszul ment" üzenetről és a frissítés következtében fellépő betöltési problémáról tudni érdemes. Ezt a shim adja ki, nem pedig valamilyen Microsoft kód. A shim figyelembe veszi az SBAT frissítéseket, és hogy ne sértse meg a rendszerben más bootloaderek által elfogadott biztonsági elveket, bár a Microsoft kiadott egy SBAT frissítést, a Linux bootloader a régi GRUB verziók indítását emiatt megtagadja. Minden úgy működik, ahogy kell.
A probléma, amellyel az emberek szembesültek, az az, hogy számos Linux disztribúció nem bocsátott ki olyan GRUB verziókat, amelyek a legújabb biztonsági generációval rendelkeznek, ezért ezek a GRUB verziók nem biztonságosnak számítanak (meg kell jegyezni, hogy a GRUB-ot maguk a disztribúciók írják alá, nem pedig a Microsoft, így itt nincs semmiféle külső késedelem). A Microsoft szándéka szerint a Windows Update frissítésnek csak azokra a rendszerekre kellett volna vonatkoznia, amelyek csak Windows-t futtatnak, míg a kettős indítással rendelkező telepítések sebezhetők maradnak a támadásokkal szemben, amíg az adott disztribúció nem frissíti a GRUB-ot és nem frissíti az SBAT generációt. Sajnos, ahogy most már egyértelmű, ez nem úgy működött, ahogy tervezték, és legalábbis néhány kettős indítású rendszer alkalmazta a frissítést, míg ennek a disztribúciónak a Shimje megtagadta a GRUB betöltését.
Mi a végeredmény? A Microsoft (érthető okokból) nem akarta, hogy a Windows-t egy sebezhető GRUB verzióval lehessen támadni, amelyet úgy lehetne becsapni, hogy végrehajtson tetszőleges kódot, majd betöltsön egy bootkitet a Windows kernelbe a rendszer indításakor. A Microsoft ezt úgy valósította meg, hogy kiadott egy Windows frissítést, amely frissítette az SBAT változót, amely megadta, hogy a sebezhető GRUB verziókat nem szabad betölteni ezeken a rendszereken. Az első szintű bootloader, amelyet a disztribúció biztosított, ezt a változót olvasta ki, olvasta a GRUB telepített példányából a SBAT szekciót, megértette, hogy konfliktusban állnak, és megtagadta a grub betöltését az "Valami teljesen rosszul ment" üzenettel. Ezt a frissítést nem szabadott volna alkalmazni a kettős indítású rendszerekre, de mégis alkalmazták.
Összességében:
1) A Microsoft frissítést alkalmazott olyan rendszereken, amelyekre nem kellett volna;
2) Néhány Linux disztribúció nem frissítette a GRUB bootloadert és az SBAT biztonsági generációt, amikor a GRUB-ban sebezhetőségeket fedeztek fel.
Ennek következtében egyes emberek nem tudják betölteni a rendszereiket. Úgy gondolom, hogy itt sok mindennek van szerepe. A Microsoftnak több tesztet kellett volna végeznie annak biztosítása érdekében, hogy a kettős indítással rendelkező telepítések pontosan azonosíthatók legyenek. De azoknak az disztribúcióknak is, amelyek aláírt betöltőket szolgáltatnak, biztosítaniuk kell, hogy frissítik azokat, és frissítik a biztonsági generációt, hogy megfeleljenek, mert különben támadási vektort biztosítanak, amelyet más operációs rendszerek feltörésére lehet használni, és ez egyfajta közszolgáltatási szerződés megsértése körül is van.
Sajnos itt főleg a végfelhasználók válnak áldozatokká, akik szembesülnek azzal, hogy a rendszer hirtelen megtagadja azt az operációs rendszert, amit el akarnak indítani. Ennek soha nem kellett volna megtörténnie. Nem hiszem, hogy a végfelhasználók megkérdezése arról, hogy akarnak-e biztonságos rendszerindító frissítéseket, jó eredményhez vezetne, és bár homályosan hajlok arra, hogy a UEFI biztonságos indítása nem olyan dolog, ami a legtöbb végfelhasználónak hasznot hoz, ez egy olyan dolog, amelyet nem akar felfedezni az ilyen incidensek után, ezért szimpatikus, hogy alapértelmezés szerint be van kapcsolva, tehát támogatom az alapértelmezett engedélyezését, és osztom a Microsoft döntését, kivéve a kettős indítással rendelkező rendszereken végrehajtott frissítések elkerülésének sikertelen kísérletét.
Mindenesetre 2012-ben nagy részt vettem ennek a mechanizmusnak a megvalósításában Linux számára, és írtam meg az első Shim prototípust (ami most már jelentősen jobb betöltő, szélesebb felhasználói jövővel, amelyhez évek óta nem nyúltam hozzá), így ha valakit szeretnél megbüntetni, kérlek, ne habozz engem megvádolni. Ez olyan dolog, ami nem szabadott volna megtörténnie, és ha nem Microsoft vagy Linux disztribúció, akkor nem a te hibád. Elnézést kérek.
Forrás: opennet.ru
