Matthew Garrett, egy elismert kernelfejlesztő Linux, aki egykor díjat kapott a Szabad Szoftver Alapítványtól a szabad szoftverek fejlesztéséhez való hozzájárulásáért, beszélt az SBAT (Secure Boot Advanced Targeting) mechanizmus lényegéről, amelyet a rendszerbetöltő sebezhetőségeinek blokkolására hoztak létre a digitális aláírás visszavonása nélkül, valamint a frissítésével kapcsolatos legutóbbi incidensben betöltött szerepéről. Windows, ami miatt egyes disztribúciók betöltése leállt Linux, párhuzamosan telepítve a Windows olyan rendszereken, amelyeken engedélyezve van az UEFI Secure Boot. Röviden, mind a Microsoft, amely nem tesztelte teljes mértékben a frissítést, és olyan rendszerekre telepítette, amelyekre nem kellett volna, mind egyes disztribúciók fejlesztői a hibásak. Linux, amely nem frissítette a GRUB rendszerbetöltőjét és az SBAT generációs számát, amikor sebezhetőségeket fedeztek fel a GRUB-ban.
Az alábbiakban Garrett feljegyzésének fordítása olvasható:
Amikor az UEFI Secure Boot specifikációt fejlesztették, annak minden résztvevője, mondjuk, kissé naiv volt. A Secure Boot alapvető biztonsági modellje, hogy minden olyan kódot, amely a rendszermag szintjén privilegizált környezetben fut, ellenőrizni kell a végrehajtás előtt - a firmware ellenőrzi a rendszerbetöltőt, a rendszerbetöltő ellenőrzi a kernelt, a kernel ellenőrzi a futás közben betöltött további kernelkódokat, és most van egy megbízható környezetünk, amellyel bármilyen más biztonsági politikát bevezethetünk, amit akarunk. Nyilvánvaló, hogy az emberek hibázhatnak, de a specifikáció módot adott a megbízhatatlannak talált aláírt komponensek visszavonására: egyszerűen add hozzá a nem megbízható kód hash-jét egy változóhoz, majd megtagadják, hogy bármit is betöltsenek ezzel a hash-sel, még akkor is, ha az megbízható kulccsal aláírva.
Sajnos kiderül, hogy a probléma a méretarány. Minden eloszlás LinuxA Secure Boot ökoszisztémán belül működő GRUB saját rendszerbetöltő binárisokat generál, mindegyiket saját hash-sel. Ha egy ilyen rendszerbetöltő forráskódjában sebezhetőséget fedeznek fel, akkor nagyszámú különböző bináris fájlt kell előhívni. Az összes hash-t tartalmazó változó tárolására szolgáló memória korlátozott. Egyszerűen nincs elég hely új hash-készlet hozzáadására minden alkalommal, amikor a GRUB (egy eredetileg a Secure Boot előtti korszakban írt rendszerbetöltő, több különálló .img elemzővel és egy betűtípus-elemzővel) egy másik mechanizmust is tartalmaz, amellyel a támadó tetszőleges kódot futtathat, ezért egy másik megoldásra volt szükség.
Ez a megoldás a SBAT volt. Az SBAT általános koncepciója meglehetősen egyszerű. A rendszerindító lánc minden kritikus összetevője deklarál egy biztonsági generációt, amelyet az aláírt bináris tartalmaz. Amikor egy sebezhetőséget felfedeznek és kijavítanak, ez a generáció növekszik. Ezt követően kiadható egy frissítés, amely meghatározza a minimális generációt - a rendszerindító komponensek megnézik a lánc következő elemét, összehasonlítják a nevét és generációszámát a firmware-változóban tárolt adatokkal, és ez alapján eldöntik, hogy végrehajtsák-e vagy sem. . A nagyszámú egyedi kivonat visszavonása helyett egyetlen frissítést is kiadhat, amely egyszerűen azt mondja: "A GRUB minden olyan verziója, amelynek biztonsági generációja ez alatt a szám alatt van, nem megbízhatónak minősül."
Miért vált ez hirtelen fontossá? Az SBAT-ot a közösség közösen fejlesztette ki. Linux és a Microsoft és a Microsoft úgy döntött, hogy kiad egy frissítést a következőhöz: Windows, amely azt mondta a rendszereknek, hogy ne bízzanak meg a bizonyos szint alatti biztonsági generációjú GRUB verziókban. Erre azért került sor, mert ezek a GRUB verziók valódi biztonsági réseket tartalmaztak, amelyek lehetővé tették a támadók számára a biztonságos rendszerindítási lánc feltörését. Windows, és valós példákat láttunk arra, hogy rosszindulatú programok ezt akarták tenni (a Black Lotus kihasználta a rendszerbetöltő sebezhetőségét Windows, de a GRUB sebezhetősége ugyanolyan hatékony volt). Tisztán biztonsági szempontból ez egy teljesen jogos vágy.
A „Valami komolyan rosszul sült el” üzenettel és a frissítés miatti rendszerindítási képtelenséggel kapcsolatban a Shim az, ami kiírja, nem pedig valamilyen Microsoft-kód. A Shim figyelembe veszi az SBAT frissítéseket, és annak érdekében, hogy ne sértse a rendszerben lévő többi rendszerbetöltő által alkalmazott biztonsági alapelveket, és bár a Microsoft kiadott egy SBAT frissítést, a rendszerbetöltő a felelős. Linux Ennek eredményeként nem hajlandó elindítani a GRUB régebbi verzióit. Minden úgy működik, ahogy kellene.
Az emberek által tapasztalt probléma az, hogy több disztribúció is előfordul. Linux nem adtak ki újabb generációs biztonsági funkciókkal ellátott GRUB verziókat, ezért ezeket a GRUB verziókat nem biztonságosnak tekintik (érdemes megjegyezni, hogy a GRUB-ot maguk a disztribúciók írták alá, nem a Microsoft, így itt nincs külsőleg bevezetett késleltetés). A Microsoft terve szerint a frissítés Windows A frissítésnek csak azokra a rendszerekre kellett volna alkalmaznia az SBAT frissítést, amelyek csak a következőn futnak: Windows, és minden kettős rendszerindítású telepítés sebezhető marad a támadásokkal szemben, amíg a telepített disztribúció nem frissítette a GRUB-ot és az SBAT generációt. Sajnos, ahogy most már világos, ez nem a tervek szerint működött, és legalább néhány kettős rendszerindítású rendszer telepítette a frissítést, a disztribúció Shim-je pedig nem volt hajlandó betölteni a GRUB-ot.
Mi a lényeg? A Microsoft (nyilvánvaló okokból) nem akarta Windows a GRUB egy sebezhető verziójával támadható, amely rávehető tetszőleges kód végrehajtására, majd egy bootkitet beillesztésére a kernelbe Windows a rendszerindítás során. A Microsoft ezt egy frissítés kiadásával tette meg Windows, amely frissítette az SBAT változót, jelezve, hogy a GRUB sebezhető verzióit nem szabad ezeken a rendszereken elindítani. A Shim disztribúció által biztosított első szintű rendszerbetöltő beolvasta ezt a változót, beolvasta az SBAT partíciót a GRUB telepített példányából, felismerte az ütközést, és megtagadta a GRUB betöltését a „Valami komolyan rosszul sült el” üzenettel. Ez a frissítés nem kettős rendszerindítású rendszerekre lett volna tervezve, de ennek ellenére telepítették.
Általában:
1) A Microsoft olyan rendszerekre alkalmazta a frissítést, amelyekre nem kellett volna alkalmaznia.
2) Néhány disztribúció Linux nem frissítette a GRUB rendszerbetöltőt és az SBAT biztonsági generációt, amikor sebezhetőségeket fedeztek fel a GRUB-ban.
Ennek eredményeként néhány ember nem tudja elindítani a rendszerét. Szerintem sok embert lehet itt hibáztatni. A Microsoftnak több tesztet kellett volna végeznie annak biztosítása érdekében, hogy a kettős rendszerindítási telepítések pontosan észlelhetők legyenek. Az aláírt rendszerbetöltőket szállító disztribúcióknak azonban meg kell győződniük arról, hogy frissítik azokat, és frissítik a biztonsági generációt, hogy megfeleljen, mert ellenkező esetben olyan támadási vektort biztosítanak, amely felhasználható más operációs rendszerek feltörésére, és ez egyfajta társadalmi szerződés megsértését jelenti. minden.
Sajnos itt elsősorban a végfelhasználók az áldozatok, akik szembesülnek azzal a ténnyel, hogy a rendszer hirtelen megtagadja a betölteni kívánt operációs rendszer betöltését. Ennek soha nem szabadna megtörténnie. Nem hiszem, hogy a végfelhasználók megkérdezése, hogy szeretnének-e Secure Boot frissítéseket, jó eredményt fog hozni, és bár homályosan hajlamos vagyok azt gondolni, hogy az UEFI Secure Boot nem olyan dolog, ami a legtöbb végfelhasználó számára előnyös, de ezt is megteszi. Nem akarom megtudni az ilyen esetek után, ezért is szimpatizálok azzal, hogy alapértelmezés szerint engedélyezve van, ezért támogatom, hogy alapértelmezés szerint engedélyezve legyen, és osztom a Microsoft választását, kivéve azt a szerencsétlen kísérletet, hogy elkerülje a dual boot rendszerek frissítését.
Mindenesetre nagymértékben részt vettem ennek a mechanizmusnak a megvalósításában Linux 2012-ben írtam a Shim első prototípusát (ami most egy lényegesen jobb rendszerbetöltő, szélesebb körben támogatott, és amihez évek óta nem nyúltam), szóval ha valakit hibáztatni akarsz, nyugodtan engem hibáztass. Ennek nem lett volna szabad megtörténnie, és hacsak nem vagy Microsoft vagy egy disztribúció... Linux, akkor nem a te hibád. Elnézést kérek.
Forrás: opennet.ru
