Jaderné noviny – 28. 6. 2018: Podpora Control-Flow Enforcement v jádře

15. 7. 2018 | David Kolibáč | Jaderné noviny | 2568×

Stav vydání jádra. Archivy LKML na lore.kernel.org. Citáty týdne: John Stultz a Dan Carpenter. Podpora Control-Flow Enforcement v jádře.

Stav vydání jádra

Kernel release status. Jonathan Corbet. 27. června 2018

Současné vývojové jádro je 4.18-rc2, vydané 17. června. Linus řekl: „Každopádně jsme na začátku řady kandidátů na vydání, ale vypadá to celkem normálně.“ Kromě toho si postěžoval na vývojáře, kteří zasílají novinky po uzavření začleňovacího okna.

Stabilní aktualizace: 4.17.3, 4.16.18, 4.14.52 a 4.9.110 byly vydány 26. června. Upozorňujeme, že 4.16.18 je poslední aktualizací řady 4.16.

Archivy LKML na lore.kernel.org

LKML archives on lore.kernel.org. Jake Edge. 22. června 2018

Na lore.kernel.org je nyní k dispozici nový archiv příspěvků (od roku 1998) z poštovní konference linux-kernel (LKML). Založený je na public-inbox (článek z února), který umožňuje mj. stáhnout celý archiv přes Git: „Na konci každé stránky jsou URL pro Git clone. Podotýkáme, že archiv LKML je vzhledem ke své velikosti rozdělený do více repozitářů, každý z nich velký 1 GB. Vedle klonování na lore.kernel.org se k těmto repozitářům dostanete také na git.kernel.org.“ Úplné oznámení s informacemi o nové instanci Patchwork a pokyny k odkazování na nový archiv je k přečtení na kernel.org.

Citáty týdne

Quotes of the week. Jonathan Corbet. 27. června 2018

Je to boj, vyvážit nekonečný příliv žádostí o revize naivního nebo jinak nedokonalého kódu s jinými důležitými vývojovými prioritami, takže *opravdu rozumím, jak je to frustrující*.

Navíc je extra otravné vypořádávat se s hromadami momentálních vývojářských žádostí, když se sami musíte věnovat údržbě v dlouhodobém časovém horizontu. Ale v opravdu dlouhodobém časovém horizontu nikdo není správcem věčně a nové olympijské plavce si nikdy nevychováme, když budeme pořád čůrat do bazénu.

—John Stultz

Čítač Reported-by jednoznačně říká, že jsi rocková hvězda.

—Dan Carpenter

Podpora Control-Flow Enforcement v jádře

Kernel support for control-flow enforcement. Jonathan Corbet. 25. června 2018

Útočníci se od doby, kdy přišli o možnost snadno spouštět kód uložený v paměti s možností zápisu, začali více zabývat „programováním zaměřeným na instrukce návratu“ (return-oriented programming, ROP) a souvisejícími technikami ke kompromitování zranitelných systémů. Útoky ROP využívají kódu v programu, na který útočí, a těžko se jim brání softwarovými prostředky. Tudíž se možnostmi, jak se vypořádat s technikami jako ROP na nižší úrovni, zabývají výrobci hardwaru. Jedním z výsledků je Intel Control-Flow Enforcement Technology [PDF] (CET), která pro obranu před těmito útoky přidává dva mechanismy (stínové zásobníky a sledování nepřímého větvení). Skupinu patchů ukazujících, jak tuto technologii použít k obraně linuxových systémů, nedávno zveřejnil Yu-cheng Yu.

Patche přidávající podporu CET byly rozděleny do čtyř samostatných skupin: podpora a dokumentace CPUID, nějaké práce na správě paměti, stínové zásobníky a sledování nepřímého větvení (indirect-branch tracking, IBT). Současné patche podporují pouze 64bitové systémy a CET pouze v případě kódu v uživatelském prostoru. Budoucí revize by měly odstranit obě tato omezení.

Útoky ROP obecně fungují tak, že se na zásobník načte skupina umělých rámců volání, z nichž každý „se vrací“ do pečlivě zvoleného kusu kódu. Zřetězením těchto „gadgetů“ ROP může útočník vyvolat spuštění dostatku užitečného kódu k tomu, aby ovládl systém. V každém větším programu je „gadgetů“ hojnost a možnost „vrátit se“ doprostřed vícebajtové instrukce tak, že dostaneme zcela jinou posloupnost operací, tomu na systémech s architekturou x86 napomáhá ještě víc. Běžící program samozřejmě může zapisovat na zásobník – ten obsahuje kombinaci informací o řízení toku programu (např. návratové adresy) a jiných dat. Je to právě ta kombinace, která činí útoky ROP proveditelnými.

Jeden způsob, jak tyto útoky zmařit, je přesunout návratové adresy do jiného kontextu, kde s nimi nejde dělat neplechu. To je ústřední myšlenka stínových zásobníků. Ve stručnosti: když jsou stínové zásobníky povoleny, volání funkce uloží návratovou adresu jak na obyčejný zásobník, tak na zvláštní stínový zásobník. Když se narazí na instrukci návratu, návratová adresa se vezme z obou zásobníků a porovná – pokud se neshodují, dojde k chybě. O operace přidání na zásobník a odebrání z něj se stará procesor. Jestliže útočník nemůže zasahovat do stínového zásobníku, mělo by se tak účinně zabránit užití instrukce návratu k odklonu od kýženého běhu programu.

Aby se zabránilo takovým zásahům, stínový zásobník vyžaduje zvláštní zacházení. Alokuje se v rozsahu virtuální paměti a základ adresy se uloží do registru specifického pro model (model-specific register, MSR). Stránky stínového zásobníku musejí mít nastavenu nezvyklou kombinaci bitů: pouze pro čtení, ale dirty. Doposud stav dirty používalo téměř výhradně jádro, a to ke sledování stránek, které bylo potřeba zapsat na fyzické úložiště, ale stínové zásobníky se bez něj neobejdou. Tudíž se ve stránkovacích tabulkách musí alokovat nový bit „software dirty“, který nahrazuje dosavadní hardwarový bit dirty.

Ochrana stínového zásobníku pouze pro čtení by měla útočníkům zabránit v přidávání vlastních zvláštních záznamů – pokud tuto ochranu nelze změnit. Co se toho týče, stínové zásobníky se alokují ve zvláštním druhu oblasti virtuální paměti (virtual-memory area, VMA), který je označen nový příznakem VM_SHSTK. Systémová volání jako madvise(), mprotect(), mremap() a munmap() nad VMA stínového zásobníku odmítnou pracovat. Přibyla skupina nových operací arch_prctl(), které se stínovými zásobníky pracovat budou. Popsán je v tomto dokumentačním patchi. Předpokládá se, že tato — neprivilegovaná – volání se použijí při spuštění programu, aby zásobník připravila. Jedno z nich (ARCH_CET_LOCK) jde použít k tomu, aby se zabránilo vypnutí stínových zásobníků (a IBT).

Stínových zásobníků se dotýká jeden zajímavý problém, a sice jak interagují s retpoline používaným k rušení druhé varianty útoků Spectre. Retpoline nahrazuje nepřímé volání funkce (tj. když adresa funkce se určí za běhu programu) posloupností instrukcí, která blízce připomíná útok ROP, takže nebude fungovat současně se stínovými zásobníky. Intel (v kapitole 4.3 tohoto dokumentu [PDF]) tvrdí, že retpoline není na procesorech s podporou CET potřeba. Doufejme, že se nedočkáme žádných překvapení, která by si vynutila volbu pouze jedné z těchto dvou technologií.

„Programování zaměřené na skoky“ (jump-oriented programming) je technika podobná ROP, ale zneužívá nepřímé skoky a volání funkcí. Jedna možnost, jak tyto útoky výrazně omezit, je zabránit skokům do všech oblastí, do kterých se se skoky nepočítalo. IBT toho dosahuje tím, že přidává dvojici nových instrukcí (endbr32 a endbr64), které slouží jako „žádné“ operace, ale udávají možný cíl nepřímého skoku. Starší procesory bez podpory CET je budou interpretovat jako „žádné“ instrukce. S povoleným IBT bude procesor vyžadovat, aby instrukce endbr byla první po nepřímém skoku: pokud se narazí na něco jiného, dojde k chybě.

Stínové zásobníky by se měly programům, které s návratovými adresami na zásobníku nedělají nic divného, jevit v zásadě transparentní. IBT je ale jiné. Je-li povoleno, spuštěný program musel být přeložen tak, aby na správných místech byly vloženy instrukce endbr. IBT nelze povolit, když patřičně přeložený program vyžaduje knihovnu, která tak přeložena nebyla, v takovém případě se program rozbije. Takže zavaděč ELF na systémech s povoleným CET bude muset krom jiného zkontrolovat, zda jsou všechny knihovny kompatibilní s CET, a CET povolit pouze tehdy, když na to budou všechny komponenty připraveny.

Nicméně, to nepokrývá jeden pozoruhodný případ: program může při spuštění vyžadovat pouze knihovny, které jsou s CET kompatibilní, ale později zavolat dlopen(), aby načetl knihovnu, která s CET nepočítá. V takové situaci připadají v úvahu toliko dvě možnosti: buď CET pro tento proces vypnout, nebo operace selže. Pokud byla vyvolána výše popsaná operace ARCH_CET_LOCK, zbyde pouze druhá možnost. Takže ji lze použít jen za cenu značného rizika rozbití programů, když bude IBT povoleno.

To vedlo k dlouhé diskuzi, zda vůbec ARCH_CET_LOCK dává nějaký smysl. Kees Cook zastával pozici, že bez ní útočníci před provedením útoku zaměří veškeré úsilí na to, jak vypnout CET. Andy Lutomirsky odpověděl, že útočník bude mít ve chvíli, kdy dokáže vypnout CET, beztak moc nad systémem a CET vlastně nic nezmůže. Zatím není jasné, co s tím.

Když odhlédneme od sporů nad těmito detaily, zdá se, že (aspoň mimo říši grsecurity) o funkci CET nikdo nemá starosti. Mělo by to systém učinit výrazně odolnějším vůči některým rozšířeným technikám útoků, a to zřejmě bez obětí v podobě výkonu či pohodlí. Je ale možné, že tato technologie přijata nebude, dokud nedokáže pokrýt i jaderný kód, protože právě na něj se mnoho útoků zaměřuje. Takže na podporu CET v Linuxu nedojde v nejbližší době, ale to platí i pro dostupnost procesorů s CET.

       

Komentáře

[pc2005]

Já bych tam rovnou dal servisní procesor, který by kontroloval kroku hlavního procesoru .