Portál AbcLinuxu, 4. května 2024 09:47
Aktuální verze jádra: 3.7-rc4. Citáty týdne: Mel Gorman, David Miller. Omezení jádra pod UEFI secure boot.
Aktuální vývojová verze jádra je 3.7-rc4 vydaná 4. listopadu. Linus k ní řekl: Je zajímavá pravděpodobně jen rozruchem, který způsobila v jistých kruzích, protože obsahuje opravu v žurnálování bitmapy na ext4. Je to drobný patch a navzdory vzniklému šílenství nebylo možné problém reprodukovat, pokud jste si nehráli se speciálními volbami pro mount.
Stabilní vydání: verze 3.0.51, 3.4.18 a 3.6.6 vyšly 5. listopadu. Všechny obsahují důležité opravy. Poslední dvě zmíněné verze obsahují opravu poškozování dat na ext4.
Kdo nemá po ránu rád vůni formálních metod?
-- Mel Gorman
Kód pro metriku říká: „Yo dawg, I heard you like sizeof, so I did a sizeof of a sizeof, so you can size your size!“ Oprava od Juliana Anastasova.
-- David Miller
"Problém" s UEFI secure boot se linuxového systému dotýká na různých úrovních. Nejprve tu máme problémy s tím Linux vůbec spustit, které jsou snad povětšinou vyřešeny dvěma podepsanými zavaděči, které jsou k dispozici pro distribuce a uživatele. Pak tu jsou jaderné funkce, které mají potenciál sabotovat secure boot. V závislosti na pohledu na věc by tyto funkce buď měly být v jádře nastavitelné – aby je některé distribuce mohly u podepsaných jader vypnout – nebo nepředstavují větší nebezpečí než existující (nebo neznámé) chyby v jádře. Jak asi tipujete, tak na linux-kernel zazněly oba pohledy na věc.
Podstatou problému je to, že na linuxových systémech jádro uživateli root důvěřuje. To znamená, že root může ve stavu systému provádět různé dočasné – nebo trvalé – změny. Mezi tyto změny patří použití kexec() ke spuštění jiného operačního systému nebo zápis hibernačního obrazu na swapovací oddíl pro použití při obnově (resume). Ale obě tyto funkce může útočník použít k obejití ochrany, kterou má secure boot vynucovat.
Pokud by uživatel například spustil systém přes jeden z Microsoftem podepsaných linuxových zavaděčů – „vata“ (shim) nebo „předzavaděč“ – s jádrem, které neomezuje pravomoci roota, tak by toto jádro mohlo spustit jiné jádro, které třeba mohlo být kompromitováno. Horší je ještě to, že z pohledu těch, co se bojí, že Microsoft bude blacklistovat zavaděče nebo klíče, by tímto jiným jádrem mohla být zákeřná verze Windows. Systém chráněný secure bootem by tedy nakonec spustil nějaká špatná Windows, což je přesně tou situací, které má secure boot zabránit.
Pokud by se toto rozšířilo, tak různí lidé věří, že by Microsoft zakázal zavaděč, který byl v tomto útoku použit. Pokud by šlo o stejný zavaděč, jako by se používal pro start Linuxu, tak by nové systémy, stejně jako ty staré, kam se rozšířila aktualizace blacklistu, odmítly spustit Linux. Matthew Garret má z tohoto strach, a proto navrhl změny, které by vhodně nastaveným jádrům zakázaly kexec() a další věci, co by k obejití bylo možné použít.
To se řešilo na začátku září a tyto změny nebyly moc kontroverzní až na název capability, kterou Garrett pojmenoval jako (CAP_SECURE_FIRMWARE), a omezení kexec(). V půlce září poslal další dávku patchů, které byly skoro stejné, až na odstranění patche kexec() a přejmenování capability na CAP_COMPROMISE_KERNEL. K patchům uvedl, že pokud je někdo chce nasadit, tak zakáží kexec do doby, než bude začleněna podpora pro načítání podepsaných dat.
Asi tak na měsíc zavládlo ticho a pak se rozjelo rozsáhlé vlákno. Dotaz od Jiřího Kosiny o načítání firmwaru do „bezpečného“ jádra vedl k debatě o modelu rizik, který je pokryt Garretovým patchem. Ačkoliv Garrett souhlasil, že načítání firmwaru by mělo být řešeno přes podpisy, nekladl tomu velkou váhu. Automatizovaný útok za použití upraveného firmwaru by značně závisel na použitém hardwaru, vyžadoval by zpětné inženýrství a ve výsledku bychom z nich asi měli prospěch.
Jak James Bottomley upozornil, tu vždy budou chyby v jádře, které umožní obejití těchto omezení (např. když si root přečte podpisový klíč pro hibernaci nebo přepne bit dané capability):
[...] útok lokálně zvyšující práva obvykle využívá nějaké chyby (typicky buffer overflow), která spustí libovolný kód v kontextu jádra. V tomto případě může být stejný typ útoku použit ke kompromitaci jakéhokoliv jaderného ochranného mechanismu včetně vypnutí secure boot a přečtění jaderného soukromého podpisového klíče.
[...] Jde mi o to, že vzhledem k tomu, že většina exploitů dokáže spustit v jádře libovolný kód, tak nemá moc smysl uvažovat o podobných věcech jako o něčem, co zabrání útoku. Měli bychom se zaměřit na debatu o tom, proč chcete v prostředí secure boot zakázat legitimnímu lokálnímu rootovi zapisovat na oddíl pro hibernaci.
Jaderné exploity, ze kterých mají Garrett a další obavy, asi nikdo řešit nechce, alespoň co se secure boot týče. Kosina řekl:
Já to chápu tak, že nám nejde o ochranu před tím, aby root zneužíval chyby v jádře. Snažíme se zabránit tomu, aby root zasahoval do kódu a dat jádra přes standardní prostředky (/dev/mem, ioperm, přeprogramování zařízení, aby použila DMA na libovolná umístění, obnovení z obrazu hibernace, se kterým si pohrál, apod.).
Není ale jisté, proč by Microsoft rozlišoval mezi exploitem a regulérními jadernými službami, když by se rozhodoval blacklistovat. U distribucí, které šíří podepsaná jádra, je ale takto možné značně snížit riziko útoku.
Eric Paris podrobně popsal útok, jenž nainstaluje upravené linuxové prostředí (s legitimně podepsaným zavaděčem a jádrem), které se uspí poté, co připraví hibernační obraz Windows s trojanem. Uživatel by musel probudit systém dvakrát, ale nakonec by měl malware na systému se secure boot.
Bottomleymu a ostatním ale značně vadí představa „nedůvěryhodného roota“. V úpravách jádra pro bezpečný boot jde hlavně o omezení roota, aby nemohl v bootovacím prostředí dělat trvalé změny. Garrettem navržené patche odstraňují mnoho děr, pomocí kterých by root takové změny mohl udělat, ale lidé argumentují, že to nebude stačit. Alan Cox:
I s těmito všemi patchi mohu jako root nadále snadno převzít kontrolu nad strojem a současně jsi zakázal uspávání na disk, kexec a spoustu dalších užitečných věcí. Abys systém skutečně uzamknul, musel bys toho udělat mnohem víc.
Další možný způsob, jak by Linux mohl být použit k útoku proti Windows (právě tehdy by se asi klíče dostaly na blacklist), by bylo změnit chování zavaděče Linuxu. Bottomley navrhl, že ověření přítomnosti uživatele při prvním spuštění zavaděče, což se dá zjistit podle toho, že databáze klíčů UEFI a databáze „klíčů vlastníka stroje“ nebudou obsahovat ty správné klíče, rozsah problému omezí. Garrett upozornil na to, že předzavaděč toto nemá dělat, protože i při prvním bootu musí být schopen se spustit v nepřítomnosti uživatele. Bottomleymu to ale vadí:
[...] já ti říkám to, že umožněním automatického počátečního bootu způsobuješ problém, který může skončit útokem na Windows. Mohl bys snadno ověřit přítomnost uživatele při prvním bootu, což by tomu zamezilo. Místo toho ale řešíme všechno tohleto.
Garrett ale vidí automatický první boot jako naprostou nezbytnost, hlavně pro ty, kteří se snaží o automatizovanou instalaci. Ostatní s tím zase nesouhlasí a debata tak stále pokračuje. Hodí se říct, že předzavaděč, který Bottomley vydal, při prvním bootu ověřuje přítomnost uživatele (a nejen tehdy, dále pak při změnách v nastavení secure boot).
Hledání všech cest, jakými by „nedůvěryhodný root“ mohl zasahovat do prostředí secure boot, se zdá být tak trochu nekonečné. Kromě toho budou i všechny budoucí funkce muset být prověřovány, zda nemusejí být v závislosti na CAP_COMPROMISE_KERNEL zakázány.
Nedůvěra v roota je něco pro jaderné vývojáře (a uživatele) dosti nezvyklého. Asi si můžeme představit, že budou všechna problémová místa nakonec vystopována, ale bude to stát hodně úsilí. Jestli si to zaslouží funkce, která je značně (i když ne úplně) užitečná jen pro ochranu Windows, toť otázka. Na druhou stranu, nemoci snadno bootovat Linux na x86 hardwaru jen kvůli blacklistu klíče by bylo také problematické. Budeme si ještě muset počkat, jak to celé dopadne.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.