Matthew Garrett, známý vývojář jádra Linux, který v minulosti obdržel ocenění od Nadace pro svobodný software za svůj přínos k rozvoji svobodného softwaru, hovořil o podstatě mechanismu SBAT (Secure Boot Advanced Targeting), navrženého k blokaci zranitelností v zaváděčích bez zrušení digitálního podpisu, a také o jeho roli v nedávném incidentu s aktualizací pro Windows, která vedla k přerušení spouštění některých distribucí Linuxu nainstalovaných paralelně s Windows na systémech se zapnutým UEFI Secure Boot. Stručně řečeno, za chyby mohou jak společnost Microsoft, která aktualizaci nedostatečně otestovala a aplikovala ji na systémy, pro které nebyla určena, tak vývojáři některých distribucí Linuxu, kteří neaktualizovali zaváděč GRUB a číslo verze SBAT, když v GRUB byly nalezeny zranitelnosti.
Níže je překlad poznámky Garretta:
Když byla vyvíjena specifikace UEFI Secure Boot, všichni její účastníci byli, řekněme, trochu naivní. Hlavní bezpečnostní model Secure Boot spočívá v tom, že veškerý kód, který se spouští ve privilegovaném prostředí na úrovni jádra, musí být ověřen před jeho vykonáním — firmware ověřuje zaváděč, zaváděč ověřuje jádro, jádro ověřuje jakýkoli další kód, který je načten během běhu, a nyní máme důvěryhodné prostředí pro prosazení jakékoli další bezpečnostní politiky, kterou chceme. Je zřejmé, že lidé mohou chybovat, ale ve specifikaci byla zavedena možnost zrušení podpisu podepsaných komponent, které se ukázaly jako nedůvěryhodné: stačí přidat hash nedůvěryhodného kódu do proměnné a poté odmítnout načítat cokoliv s tímto hashem, i kdyby to bylo podepsáno důvěryhodným klíčem.
Bohužel, jak se ukázalo, problém je v rozsahu. Každá distribuce Linuxu, která funguje v ekosystému Secure Boot, generuje své vlastní spouštěcí binární soubory, a každý z nich má svůj vlastní hash. Pokud se v původním kódu takového spouštěče objeví zranitelnost, je třeba stáhnout velké množství různých binárních souborů. A objem paměti pro uložení proměnné obsahující všechny tyto hashe je omezen. Prostě nebude dost místa na přidávání nového souboru hashů pokaždé, když se ukáže, že GRUB (spouštěč napsaný původně v době, kdy se neprováděla ochrana při spouštění a má několik samostatných parserů img-obrázků, stejně jako parser fontů) má další mechanismus, jak umožnit útočníkovi, aby vykonal libovolný kód, proto bylo potřeba jiné řešení.
Tímto řešením se stal SBAT. Celková koncepce SBAT je poměrně jednoduchá. Každá důležitá součást v řetězci spouštění vyhlašuje generační bezpečnost, která je zahrnuta do podepsaného binárního souboru. Když je zranitelnost nalezena a odstraněna, tato generace se zvyšuje. Poté je možné vydat aktualizaci, která určuje minimální generaci – komponenty spouštění se podívají na další prvek v řetězci, porovnají jeho název a číslo generace s těmi, které jsou uloženy v proměnné firmwaru, a rozhodnou se, zda jej provést či nikoli, na základě toho. Místo toho, aby bylo potřeba stahovat velké množství samostatných hashů, je možné vydat jednu aktualizaci, která jednoduše říká: „Jakákoli verze GRUB s generační bezpečností nižší než toto číslo je považována za nedůvěryhodnou.“
Proč se to tedy stalo aktuálním? SBAT byl vyvinut společností Linux a Microsoft a Microsoft se rozhodl vydat aktualizaci pro Windows, která říkala systémům, aby nedůvěřovaly verzím GRUB s generační bezpečností pod určitou úrovní. To bylo učiněno proto, že tyto verze GRUB měly skutečné bezpečnostní zranitelnosti, které umožnily útočníkům narušit řetězec bezpečného spouštění Windows a viděli jsme skutečné příklady malwaru, který se to snažil provést (Black Lotus využíval zranitelnost ve spouštěči Windows, ale zranitelnost v GRUB byla stejně efektivní). Pokud se na to díváme čistě z pohledu bezpečnosti, je to zcela oprávněné přání.
Pokud jde o zprávu „Něco se pokazilo“ a nemožnost spustit po této aktualizaci, je to způsobeno shimem, nikoli nějakým kódem od Microsoftu. Shim zohledňuje aktualizace SBAT a aby nedošlo k porušení bezpečnostních zásad přijatých jinými bootloadery v systému, a i když Microsoft vydal aktualizaci SBAT, právě linuxový bootloader odmítá spustit starší verze GRUB. Všechno funguje tak, jak má.
Problém, s nímž se lidé setkali, spočívá v tom, že několik distribucí Linuxu nevydalo verze GRUB s novější generací zabezpečení, a proto jsou tyto verze GRUB považovány za nezabezpečené (je třeba poznamenat, že GRUB je podepisován samotnými distribucemi, nikoli Microsoftem, takže zde není žádná vynucená zpoždění zvenčí). Podle Microsoftu mělo aktualizace Windows Update aplikovat aktualizaci SBAT pouze na systémy fungující výhradně s Windows, a všechny instalace s dual boot zůstávaly zranitelné vůči útokům, dokud nedojde k aktualizaci GRUB a nového generace SBAT instalovanou distribucí. Bohužel, jak nyní jasné, to nefungovalo tak, jak bylo zamýšleno, a alespoň některé systémy s dual boot aplikovaly aktualizaci, a Shim této distribuce odmítl spustit GRUB této distribuce.
Jaký je závěr? Microsoft (z pochopitelných důvodů) nechtěl, aby bylo Windows možné napadnout zranitelnou verzí GRUB, kterou bylo možné podvodně donutit k provedení libovolného kódu, a poté zavést bootkit do jádra Windows během spouštění. Microsoft to udělal tím, že vydal aktualizaci Windows, která aktualizovala proměnnou SBAT a uvedla, že zranitelné verze GRUB by neměly být spouštěny na těchto systémech. Poskytnutý distribucí Shim bootloader první fáze přečetl tuto proměnnou, načetl oddíl SBAT z nainstalované kopie GRUB, pochopil, že jsou v konfliktu, a odmítl spustit grub se zprávou „Něco se pokazilo“. Tato aktualizace neměla být aplikována na systémy s dual boot, ale i tak byla aplikována.
Obecně:
1) Microsoft aplikoval aktualizaci na systémy, na které neměla být aplikována
2) Některé distribuce Linuxu neaktualizovaly bootloader GRUB a generaci zabezpečení SBAT, když byly v GRUB objeveny zranitelnosti.
V důsledku toho někteří lidé nemohou načíst své systémy. Myslím, že je tu hodně viníků. Microsoft by měl provést více testů, aby se ujistil, že instalace s dvojím bootováním mohou být přesně identifikovány. Ale také distribuce, které dodávají podepsané bootloadery, by měly zajistit, že je aktualizují a přizpůsobí generaci zabezpečení, aby odpovídaly, jinak poskytují útočný vektor, který může být použit k napadení jiných operačních systémů, a to je jakýsi narušení veřejného smlouvání kolem toho všeho.
Bohužel oběťmi zde většinou stávají koncoví uživatelé, kteří čelí tomu, že se systém náhle odmítá načíst operační systém, který chtějí načíst. K tomu by nikdy nemělo dojít. Nemyslím si, že průzkum koncových uživatelů ohledně toho, zda chtějí aktualizace systému bezpečného spouštění, povede k dobrému výsledku, a i když se mírně přikláním k tomu, že bezpečné spouštění UEFI není něco, co většině koncových uživatelů přináší prospěch, je to také věc, kterou nechcete zjistit po podobných incidentech, takže sympatizuji s tím, že je zapnuta ve výchozím nastavení, proto podporuji její zapnutí ve výchozím nastavení a sdílím volbu Microsoftu, s výjimkou neúspěšného pokusu vyhnout se aktualizaci na systémech s dvojím bootováním.
V každém případě jsem byl silně zapojen do implementace tohoto mechanismu pro Linux v roce 2012 a napsal jsem první prototyp Shim (který je nyní výrazně lepším bootloaderem, podporovaným širším okruhem lidí, a kterého jsem se dotkl již několik let), takže pokud chcete někoho jednoho obvinit, prosím, neváhejte obvinit mě. To, co mělo stát, se mělo stát, a pokud nejste Microsoft nebo distribuce Linuxu, není to vaše vina. Omlouvám se.
Zdroj: opennet.ru
