Jaderné noviny – 8. 3. 2018: Prevence úniků z jaderného zásobníku

20. 3. 2018 | David Kolibáč | Jaderné noviny | 2749×

Stav vydání jádra. Citáty týdne: Greg Kroah-Hartman a Linus Torvalds. Prevence úniků z jaderného zásobníku.

Stav vydání jádra

Kernel release status. Jonathan Corbet. 7. března 2018

Současné vývojové jádro je 4.16-rc4, vydané 4. března. Linus prostě pravil: „Hmm. Celkem rozumně klidný týden.“

V nejnovějším seznamu regresí v cyklu 4.16 je sedm známých problémů.

Stabilní aktualizace: 4.14.24, 4.9.86, 4.4.120 a 3.18.98 byly vydány 5. března. Další aktualizace 4.15.8 a 4.14.25 byly v době psaní tohoto článku revidovány a vyšly 9. března.

Citáty týdne

Quotes of the week. Jonathan Corbet. 7. března 2018

Nebo se prostě přesuňte na 4.14.y. Vážně, to je z dlouhodobého hlediska nejspíš ta nejbezpečnější varianta pro všechny zúčastněné. A když si uvědomíte, že to udělat nemůžete, řvěte na své SoC, že vás svými >3 milióny řádků přidanými do vlastního jaderného stromu vtáhli do téhle noční můry. Váš čas byl vždycky vypůjčený a zdá se, že konečně vypršel…

—Greg Kroah-Hartman

Borci, všichni se shodneme, že C není bezpečný jazyk.

Myslíte, že absence bezpečnosti je _dobrá_ věc?

Uvědomujete si, že absence bezpečnosti skoro přímo odpovídá flexibilitě, přímočarosti a generování dobrého kódu?

Ale co kdybych vám řekl, že absence bezpečnosti do jisté míry na flexibilitě, přímočarosti, _nebo_ generování dobrého kódu nepřidává? Neřekli byste pak, že „nechcete, aby to bylo nebezpečné“?

Na rovinu vám říkám, že chybějící inicializace proměnných je skoro čistě špatná věc. C by bylo bezpečnějším jazykem s méně případy nedefinovaného chování, kdyby jenom zabránilo vyhýbání se inicializaci automatických proměnných.

—Linus Torvalds

Prevence úniků z jaderného zásobníku

Preventing kernel-stack leaks. Jonathan Corbet. 7. března 2018

Jaderný zásobník je malá, často opětovně používaná oblast paměti v adresním prostoru každého vlákna. Toto opětovné používání umožňuje efektivnější využití paměti a díky principu lokality cache poskytuje slušný výkon, ale také představuje problém: data, která na zásobníku zůstanou, mohou být znovu použita nezamýšlenými způsoby. Patche PaX obsahují mechanismus, který by měl zásobník vyčistit od dat a zabránit únikům, ale snaha začlenit tento kód do jádra se zadrhla.

Jazyk C byl navržen tak, že nedefinuje obsah automatických proměnných, tedy těch, které se vytvoří na zásobníku, když dojde k volání funkce, v níž jsou tyto proměnné definovány. Pokud programátor automatické proměnné neinicializuje, budou obsahovat nahodilé nesmyslné hodnoty, respektive to, co zrovna leželo ladem na zásobníku v místech, kde se alokují proměnné. Absence inicializace těchto proměnných může v důsledku vést k různým formám nechtěného chování. Zápisem neinicializované proměnné do uživatelského prostoru uniknou data ze zásobníku, a ta mohou být nějakým způsobem citlivá. Když se neinicializovaná hodnota použije uvnitř funkce, mohou se ukázat překvapivé výsledky, a přijde-li útočník na to, jak určit, co zbude na zásobníku, může být schopen to zneužít, aby kompromitoval jádro. Oba druhy zranitelností už se v minulosti v jádře objevily a určitě se objeví i v budoucnu.

Uvažte, že ačkoliv z většiny použití neinicializovaných dat lze jen těžko vinit programátora, není tomu tak vždy. Například struktury uložené na zásobníku mohou mít různě zarovnaná pole a překladač se může rozhodnout, že prostor použitý k zarovnání neinicializuje, protože program ho stejně aktivně používat nebude. Jenže tato paměť přesto může být odhalena uživatelskému prostoru, jestliže jádro zapíše takovou strukturu v reakci na systémové volání.

Nejlepším řešením tohoto problému by bylo najít a opravit všechna místa, kde proměnné na zásobníku nejsou řádně inicializovány. Nástroje jako KASan s tím mohou pomoci, ale hledání takových míst je hra bez konce. Bylo by tedy dobré moci tomuto druhu zranitelnosti automaticky předcházet.

Alexander Popov už nějaký čas pracuje na portu funkcionality PaX STACKLEAK do hlavního stromu jádra. Devátá verze této sady patchů byla zveřejněna 3. března. Přidává zásuvný modul GCC, který sleduje maximální výšku jaderného zásobníku. Ta se dá potom použít k zabránění přetečení zásobníku. Hlavním účelem sledování je ale umožnit jádru, aby jaderný zásobník vyčistilo po každém návratu ze systémového volání. Kód čistící zásobník může maximální výšku využít, aby zbytečně nečistil část zásobníku, která se nepoužila. Podle průvodního dopisu zapnutí této funkce stojí zhruba 1 % výkonu – výměnou za jaderný kód, který vždy běží v prostředí, o kterém je známo, že obsah zásobníku je nastavený správně.

Shodou okolností „čištění“ zásobníku nespočívá v jeho vynulování. Místo toho se používá zvláštní „jedovatá“ (poison) hodnota, která by měla pomoci s určením pádů, za něž může použití neinicializovaných proměnných na zásobníku.

Kees Cook poznamenal, že tato skupina patchů „by měla být připravena k dodání celkem brzy,“ ale to o ní ještě nevěděl Linus Torvalds. Ten z toho neměl radost a dal jasně najevo, že kód STACKLEAK se ve stávající podobě do hlavního stromu jádra jen tak nedostane. Stěžoval si:

Nezdá se, že by to vůbec pomáhalo *nacházet* chyby. Takže je to další případ „schovat a zapomenout“, který akorát přidává docela velkou režii, když je povolený.

Navrhl, že by se vývojáři od bezpečnosti měli víc věnovat nacházení a opravám chyb, a tedy vylepšování jádra, než aby takto problémy zakrývali.

Netřeba dodávat, že zúčastnění vývojáři to vidí trochu jinak. Cook odpověděl:

Myslím, že to jádro zlepšuje, zvlášť pokud se nám jeho větší část podaří pokrýt pomocí vestavěných voleb překladače (spíš než jen zásuvného modulu). Třeba právě teď je jádro zanesené memset()y, protože nemůžeme věřit překladači, že zarovnání správně vyplní nulami atd. To je nekonečný zdroj chyb a tahle řada patchů poskytuje všeobjímající, rychlý způsob, jak zásobník udržet čistý.

Tato reakce přivedla Torvaldse k tomu, aby začal přemýšlet o tom, co popsal jako „*chytrý*“ přístup k problému. Prostě vyčistit zásobník mu *chytré* nepřišlo, ale kdyby překladač všechny automatické proměnné inicializoval na nulu, to by už šlo. Inicializace tímto způsobem by poskytovala srovnatelnou ochranu před neinicializovanými daty, ale také by se dala přeskočit, kdykoliv by překladač mohl s jistotou určit, že proměnná byla řádně inicializována nějakým jiným způsobem. Výsledkem by byla ochrana s výrazně nižší režií.

Režie by se v případě kódu citlivého na výkon dala ještě výrazněji zmenšit přidáním zvláštního příznaku k proměnným, které by překladač inicializovat neměl, a to ani v případech, kdy by se inicializace jevila nezbytná. Místa, kde by se takový příznak hodil, by byla jasně patrná při profilování výkonu a samotný příznak by byl zřetelným varováním, že se na daném místě mohou vyskytnout neinicializovaná data.

Cook souhlasil s přidáním takové funkce do překladače, ale také řekl, že to nestačí. Široké přijetí nového překladače trvá dlouho – nová jádra jsou sestavována starými překladači až překvapivě dlouhou dobu. Takže bude trvat roky, než se řešení založené výhradně na překladači dostatečně rozšíří. Oproti tomu přidání čištění zásobníku do jádra nasazení ochrání bez ohledu na použití nového překladače. Dále Cook poukázal, že v pár případech vynulování automatických proměnných úplné pokrytí neposkytuje. Pokud zranitelnost útočníkovi umožní číst data pod aktuální hranicí zásobníku, dá se zneužít k přečtení potenciálně zajímavých dat, která se tam budou nacházet. Vyčištění zásobníku také smaže data, která by jinak mohla být čitelná pomocí nesouvisející zranitelnosti, takže výrazně zmenší okno, ve kterém by se taková zranitelnost dala zneužít.

V době psaní tohoto článku diskuze dosud nedospěla k definitivnímu závěru. Kód STACKLEAK se na cestě do hlavního stromu setkal s významnou překážkou, ale to zatím neznamená, že by měl být na odpis. Existují oprávněné důvody, proč by se taková funkce do jádra měla dostat, alespoň tedy v krátkodobém časovém horizontu, a pokud se někdo nechce smířit s vyšší režií, čištění zásobníku jde vypnout. Takže s dostatkem vytrvalosti (a vývojáři zaměření na bezpečnost se naučili být vytrvalí) patche STACKLEAK mohou mít v hlavním stromu své místo.