Jaderné noviny – 22. 6. 2017: Jak předcházet přeskakování ochranné stránky zásobníku

27. 7. 2017 | Redakce

Články - Jaderné noviny – 22. 6. 2017: Jak předcházet přeskakování ochranné stránky zásobníku  

Stav vydání jádra. Jak předcházet přeskakování ochranné stránky zásobníku.

Stav vydání jádra

Současné vývojové jádro je 4.12-rc6, vydané 19. června. Linus řekl: „Dobrou zprávou je, že rc6 je menší než rc5, myslím, že jsme zpět v obvyklém tempu a rc5 byla velká jen náhodou kvůli načasování. Uvidíme. Další víkend, až budu doma a udělám rc7, se rozhodnu, co dál. Stále doufám, že půjde o normální vývojový cyklus a rc7 bude posledním kandidátem na vydáním.“

Stabilní aktualizace: 4.11.6, 4.9.33 a 4.4.73 byly vydány 17. června.

Stabilní aktualizace 4.11.7, 4.9.34, 4.4.74 a 3.18.58 byly v době psaní tohoto článku v procesu revidování. Touto dobou již měly být dávno venku, možná se čekalo na odstranění problémů s řešením zranitelnosti „Stack Clash“. Skutečně vyšly 24., resp. 26. června.

Greg Kroah Hartman také oznámil, že příští řada vydání jádra s dlouhodobou podporou bude 4.14.

Jak předcházet přeskakování ochranné stránky zásobníku

Obvykle by člověk v testovacím vydání jádra -rc6 nečekal 900řádkovou změnu ve správě paměti. Ale jak už to tak bývá, byla právě taková změna v tichosti začleněna hned před vydáním 4.12-rc6. Možná, že právě to byl důvod, proč vydání vyšlo o pár hodin později, než mělo. Nicméně tato změna je důležitá, řeší totiž nově zveřejněnou bezpečnostní hrozbu, která je, zdá se, aktivně zneužívána.

Oblast zásobníku běžícího procesu je na většině architektur umístěna na relativně vysokou virtuální adresu a roste směrem dolů podle toho, jak se zvyšují požadavky zásobníku procesu. Oblast virtuální paměti, která automaticky roste kvůli výpadkům stránek, přináší jistá rizika. Zejména je třeba zabránit jí v růstu do jiných oblastí paměti umístěných pod ní. V procesu s jedním vláknem může být těžké dosáhnout přetečení potenciálně dost velkého adresního prostoru, který je zásobníku vyhrazen. Procesy s více vlákny ale obsahují více zásobníků. Ty jsou menší a pravděpodobně budou umístěny do oblasti mezi další oblasti virtuální paměti. Náhodné přetečení by mohlo poškodit oblast pod zásobníkem – záměrné přetečení, pokud se ho podaří dosáhnout, může být použito ke kompromitaci systému.

Oprava: Ben Hutchings upozornil, že analýza Qualys vychází ze zásobníku „hlavního vlákna“ a žádných jiných, které – aspoň s glibc – nemají dovoleno růst.

Jádro již dlouho umísťuje ochrannou stránku – stránku, která je nepřístupná nadřazenému procesu – pod každou oblast zásobníku. (Vlastně to není až tak dlouho, ochranná stránka byla přidána v roce 2010). Proces, který putuje ze spodní části zásobníku do hlídací stránky bude odměněn signálem poruchy segmentace, což pravděpodobně způsobí předčasný konec daného procesu. Svět obecně předpokládal, že hlídací stránka je dostatečná ochrana před přetečením zásobníku, ale zdá se, že se svět zmýlil.

19. června zveřejnila firma Qualys skupinu zranitelností, které jasně ukazují, že jediná ochranná stránka jako ochrana proti útokům pomocí přetečení zásobníků nestačí. Tyto chyby jsou přezdívány „Stack Clash“, přidružené domény, logo a řada designového spodního prádla zatím ještě nedorazily na trh. O tomto problému se již na neveřejných kanálech jistě nějaký čas mluvilo, protože řada distributorů byla okamžitě připravena s aktualizací jádra ve snaze situaci uklidnit.

Základní problém je v tom, že je ochranná stránka příliš malá. Existuje řada způsobů, jak lze zásobník rozšířit o více než jednu stránku najednou. Patří mezi ně místa v GNU C Library, která provádějí volání alloca() s požadavkem na hodně paměti, a programy s velkými poli proměnlivé délky nebo jinými velkými datovými strukturami na zásobníku. Ukazuje se, že pro útočníka je relativně snadné přimět program, aby generoval adresy zásobníku, které přeskočí ochrannou stránku a přistanou v jakékoliv paměti, která se nachází pod ním. Všechny důkazy proveditelnosti útoku zveřejněné firmou Qualys představují místní vykonání kódu, ale zdá se být nerozumné předpokládat, že neexistuje způsob, jak by se problém dal zneužít na dálku.

Oprava začleněná pro vydání 4.12 přišla od Hugha Dickinse s poděkování Olegu Nesterovovi a Michalu Hockovi. Jedná se o přímočarý způsob řešení problému, dá se říct hrubou silou. 4KB ochranná stránka se změní na 1MB ochrannou oblast v libovolné části automaticky rostoucí virtuální paměti. Jak stojí v poznámce seznamu změn patche: „Samozřejmě se nejedná o plnohodnotnou opravu, protože se jedná o inherentní problém, ale mělo by to hodně snížit prostor pro útoky.“ Velikost ochranné oblasti není za chodu konfigurovatelná (to počká do doby, kdy někdo ukáže, že to potřebuje), ale dá se změnit při zavádění systému pomocí parametru příkazového řádku stack_guard_gap.

Hlídací oblast o velikosti 1 MB by mělo být obtížné přeskočit. Jedná se (nebo mělo by se jednat) o vzácný program, který se snaží přidělit tolik paměti na zásobníku, a jiná omezení (například omezení délky příkazového řádku) by měla ztížit možnost oklamat programy, aby alokaci provedly. Na většině 64bitových systémů by mělo být možné – v případě, že se správce obává, že 1 MB paměti nestačí – vytvořit ochrannou oblast podstatně větší. Nepochybně existují útočníci, kteří horečnatě pracují na způsobech, jak se přes tyto oblasti dostat, ale aspoň na chvíli by mohli dojít k závěru, že jsou snazší způsoby, jak na příslušný systém zaútočit.

Skutečným problémem je samozřejmě to, že ukazatel na zásobník se dá zneužít k přístupu k paměti, která není součástí zásobníku. Možná jednou budeme mít paměťové typy v ukazatelích, které umožní hardwaru detekovat a blokovat takové útoky. Prozatím však musíme aktualizovat své systémy, abychom zvýšili laťku pro úspěšnou kompromitaci. Distributoři již aktualizovali a oprava je ve frontě pro další kolo stabilních aktualizací jádra, ke kterému došlo 21. června.