AbcLinuxu:/ Články / Jaderné noviny - 25. 2. 2016: Programování orientované na Sigreturn a jeho zmírňování

Štítky: bez, C, citace, data, exploit, funkce, hardware, jádro, kernel, nastavení, patch, predmety, problém, proces, programování, psaní, telefony, uložení, x86, život

Jaderné noviny - 25. 2. 2016: Programování orientované na Sigreturn a jeho zmírňování

2. 3. 2016 | Redakce | Jaderné noviny | 3005×

Stav vydání jádra. Citáty týdne. Programování orientované na Sigreturn a jeho zmírňování.

Stav vydání jádra

Současný vývojový kernel nese označení 4.5-rc5, vydán byl 20. února. Podle Linuse je vše v pořádku a v klidu, jen s čištěním VM THP jsou stále problémy na s390.

Stabilní aktualizace: 4.3.6 (poslední v řadě 4.3.x) a 3.10.97 byly vydány 19. února. Verze 4.4.3, 3.14.62 a 3.10.98 byly v době psaní překladu tohoto vydání jaderných novin v procesu revidování a nyní jsou k dispozici.

Citáty týdne

No ne, máme spelling.txt! Myslím, že můžeme prohlásit jádro za hotové a dělat něco jiného...

-Borislav Petkov

Což vlastně nebude vůbec vadit, protože za 22 let nebude 32bitový systém nikde běžně k vidění. Stačí se podívat na platformy x86, Pentium Pro je už dneska sběratelským předmětem. Všechna ta dnešní uzamčená, sotva udržovaná vestavěná zařízení a telefony budou po připojení k čemukoli přinejlepším jakýmsi digitálním ekvivalentem nebezpečného odpadu.

-Alan Cox

Programování orientované na Sigreturn a jeho zmírňování

Za starých dobrých časů (alespoň z jednoho úhlu pohledu) měli útočníci jednoduchý život. Stačilo jim najít zranitelnost způsobenou přetečením vyrovnávací paměti a vsunout (code injection) do zranitelného procesu kód dle svého gusta. V průběhu času se vývojáři kernelu snažili zajistit, aby data, která mohou být zapsaná aplikací, nemohla být stejnou aplikací vykonána. Tento krok učinil „vstřikování“ kódu ve většině situací neproveditelným. Útočníci tedy reagovali technikami, jako je return-oriented programming (ROP), ale ROP jsou většinou docela náročné na provedení. Na některých systémech mohou útočníci využít jednodušší sigreturn-oriented programming (SROP). Naštěstí již kolují patche, které by měly odvrátit tento typ útoků.

Trocha vysvětlování

Jestliže nemohou být data na zásobníku přímo spuštěna, nemůže dojít ke zneužití přetečení vyrovnávací paměti a vložení kódu přímo do aplikace. Tyto zranitelnosti ovšem mohou být zneužity ke změně čítače programu přepsáním aktuální adresy vracené funkcí. Jestliže se útočníkovi podaří identifikovat kód, který se nachází uvnitř adresního prostoru příslušného procesu, jenž vykonává zadaný úkol, může zneužít přetečení vyrovnávací paměti k navrácení se k tomuto kódu a nabytí kontroly.

Naneštěstí pro útočníky postrádá většina programů vhodné místo pro vstup skrze přepsanou návratovou adresu. I tak je pravděpodobné, že daný program požadovanou funkcionalitu obsahuje, jen je rozsekaná na malé kousky a rozptýlená po celém adresním prostoru. Základní myšlenkou ROP je najít tyto kousky v místech, kde je následuje instrukce pro návrat (return). Útočník, který má kontrolu nad zásobníkem, může nejen skočit k první z těchto pasáží, ale také umístit návratovou adresu na zásobník, takže když tento kousek vykoná svou instrukci návratu, přechází kontrola na další místo vybrané útočníkem – další část užitečného kódu. Seřazením těchto kousků může útočník uvnitř cílového procesu vytvořit zcela nový program.

Existují různé nástroje, které mohou s tvorbou ROP útoků pomoci. Skenery mohou projet spustitelný obraz a identifikovat předměty zájmu. „ROP kompilátory“ mohou poté vytvořit program k dosažení útočníkova cíle. Nezbytné nástroje ovšem nemusí být dostupné a techniky jako randomizace adresního prostoru (address-space layout randomization, ASLR) ROP útoky stěžují. ROP útoky tudíž bývají vskutku delikátní záležitostí; často jde o konkrétní útoky na konkrétní systémy (někdy dokonce pouze konkrétní běžící proces). Útočníci jsou lidé zaneprázdnění, stejně jako my ostatní, takže je nemůžeme vinit, když se snaží najít jednodušší způsoby, jak ovládnout systém.

Zneužívání sigreturn()

Seznamme se se sigreturn(), linuxovým systémovým voláním, které ovšem nikdo nevolá přímo. Když dojde k doručení signálu procesu, přejde se k obsluze daného signálu; jakmile ta skončí, vrátí se vykonávání programu k místu, kde došlo k přerušení. Signály jsou typem softwarového přerušení – se všemi takovými přerušeními musí být nějak naloženo. Dříve než může jádro doručit signál, musí si zaznamenat kontext vykonávání programu, a to včetně hodnot, které se ukládají ve všech registrech procesoru.

Bylo by možné uložit tuto informaci přímo v jádře, ale to by mohlo umožnit útočníkovi (jiného ražení) přinutit jádro alokovat libovolné množství paměti. Takže místo toho ukládá jádro tuto informaci na zásobník procesu, který je příjemcem signálu. Před vyvoláním obsluhy signálu přidá jádro některou variantu struktury sigcontext (v závislosti na architektuře) na zásobník procesu. Tato struktura obsahuje informace z registrů, o využívání čísel s plovoucí desetinnou tečkou aj. Jakmile obsluha dokončí svůj úkol, zavolá sigreturn(), který vrátí všechny informace ze struktury na zásobníku.

Útočníci, kteří využívají techniky ROP, se musí snažit najít programy, které uloží požadované hodnoty do konkrétních registrů procesoru. Ovšem pokud mají možnost zavolat sigreturn(), mají to jednodušší, protože toto systémové volání nastavuje hodnoty všech registrů přímo ze zásobníku. Jak už to tak bývá, nemá jádro žádný způsob, jak rozpoznat, zda konkrétní sigreturn() pochází z legitimní obsluhy signálu či nikoli; celý systém byl navržen tak, aby jádro tuto informaci nemuselo sledovat. Takže jak poznamenali Erik Bosman a Herbert Bos v tomto článku (PDF), vypadá to, že volání sigreturn() by mohlo být útočníkům nápomocné.

Existuje však jedna překážka, kterou musí útočníci překonat nejprve: musí najít kus kódu volající sigreturn(), což dělá jen několik málo aplikací. Jednou z metod by bylo najít obecnější část programu pro vyvolávání systémových volání a pak zařídit, aby došlo k tolika voláním, aby to odpovídalo sigreturn(). V mnoha případech je to ale zbytečné. Vývojáři po mnoho let příhodně umisťovali sigreturn() tam, kde jej útočníci mohou snadno najít – na pevnou adresu, která není v režii ASLR. Tato adresa se nachází v oblasti „virtuálního dynamického sdíleného objektu“ (vDSO), na stránce namapované jádrem ve známém umístění v každém procesu, a to kvůli optimalizaci některých systémových volání. Na jiných systémech se sigreturn() nachází v knihovně jazyka C. K jeho zneužití je nejprve třeba najít způsob, jak přijít k informacím o ASLR.

Bosman a Bos předvedli, že se dá sigreturn() použít pro napadení procesů, které jsou zranitelné skrze přetečení paměti. Často stačí pouze kus kódu se sigreturn() a útok se podaří. V některých případech se dá exploit napsat nezávisle na systému, takže se dá použít znovu bez dalšího úsilí. Nová jádra činí taková napadení složitější (například oblast vDSO se již nedá použít), ale ještě zdaleka nejsou nemožné. Navíc spousta zajímavých cílů stále používá starší verze jádra.

Je třeba zastavit SROP

Scott Bauer nedávno zveřejnil sadu patchů, která by měla skoncovat s útoky SROP. Jakmile je problém znám, je řešení jasné celkem rychle: jádro potřebuje způsob, jak si ověřit, že struktura sigcontext na zásobníku je ta, kterou tam samo dalo. To by zajistilo, že sigreturn() bude možné volat pouze na konci skutečného doručení signálu.

Scottův patch funguje tak, že generuje náhodné „cookie“ hodnoty pro každý proces. Tato hodnota je uložena na zásobníku jako součást každého procesu doručení signálu, hned vedle struktury sigcontext. Před uložením dojde ke XORování s adresou umístění zásobníku, kde dojde k uložení, takže je o mnoho složitější z ní zpětně číst. Budoucí plány volají po rozdělení této hodnoty, čímž se zcela znemožní obnovení „cookie“ hodnoty. I tak by ale měla být hodnota „cookie“ dostatečně bezpečná; útočník, kterému by se podařilo tuto hodnotu přečíst přímo ze zásobníku, má již tak či tak systém pod kontrolou.

Implementace sigreturn() již vyžaduje pouze ověřit, že „cookie“ existuje v předpokládaném umístění. Pokud tam je, potom je volání legitimní a může k němu dojít. V opačném případě operace skončí a vrátí SIGSEGV volajícímu procesu, čímž dojde k jeho ukončení, pakliže proces není nějak ošetřen.

Patch má stále nějaké praktické problémy. Nebude kupříkladu pracovat správně v situaci, kdy je aktivní bod obnovy v uživatelském prostoru (obnovený proces bude mít novou a náhodnou hodnotu cookie, staré cookie mohou být stále na zásobníku). Tyto problémy je možné obejít, ale může si to vynutit přidání přepínače sysctl pro vypnutí ochrany v situacích, kde nefunguje. Také nijak nepřispívá k ochraně před ROP útoky obecně, pouze zabraňuje jednomu z relativně snadno zneužitelných scénářů těchto útoků. Ale je na dosah, takže jeho získání je asi dobrý nápad. Ostatně, proč útočníkům zjednodušovat život?