Jemny uvod do buffer overflow #1

Buffer overflow vulnerability - casto sa s nou mozno stretnut v changelogoch, alebo security advisories. Co to vlastne je a preco to vznika? Pre ludi znalych platformy x86, jej adresovacieho mechanizmu by sa mohlo zdat, ze je to priam jav nemozny. Opak je vsak pravdou. Tento clanok sa pokusi poskytnut jemny uvod do tejto vcelku lahko vytvoritelnej diery v mnohych programoch, ktora moze mat siahodlhe nasledky.

Nepojde o nijak prevratny clanok s nejakymi novymi a brutalnymi znalostami, bude skor zamerany na spojenie vsetkych elementov, ktore prispievaju k vzniku buffer overflow "efektu". Nebudem predpokladat ziadne vyznamne znalosti v oblasti bezpecnosti, iba trochu rozumu a znalost programovania v C. Znalost assemblera nebude na skodu. Ak bude zaujem, v moznom pokracovani nacrtnem aj to, ako sa proti takymto zalezitostiam branit. V tejto casti zhrniem vsetky podstatne faktory, ktore prispievaju k vzniku tejto zranitelnosti.

Prvym faktorom k vzniku buffer overflow je pouzitie vhodneho programovacieho jazyka. Co sa v tomto ohlade povazuje za vhodny jazyk? No v prvom rade musi dany jazyk byt dostatocne ignorantsky a v druhom rade musi byt dostatocne benevolentny pri kontrole chyb. Vcelku do tohto vzorca zapada jazyk C, resp. C++, ktore su navyse aj dobre rozsirene a vcelku slusne normalizovane. Prilisna benevolencia jazyka C vsak nie je sposobena tym, ze jeho navrhari nepouzili rozum, ale jeho urcenim. Pouziva sa na aplikacie, kde je hlavny vykon a efektivita a tam by overovanie kazdej blbosti, rozsahu, spravnosti kod vyrazne spomalilo a obmedzilo moznosti programatora, kedze niektore z vlastnosti (neoverovanie rozsahu poli) sa priamo vyuzivaju pri programovani. Doplnkom k tomuto faktoru je, ze programator casto nepredpoklada, ze by do funkcie mohol dostat viac dat, nez kolko si vyhradil v buffri, preto neosetri taketo pripady a pri kopirovani blokov dat kopiruje "kym este su data" a nie "kym este su data a v buffri je volne miesto". To sposobuje, ze vytvorit zranitelny program je velmi jednoduche.

Druhym faktorom je podpora platformy. Na domacich pocitacoch a vo sfere lowend serverov je asi najpouzivanejsou platformou platforma x86 a x86_64. Tato platforma uz cca od roku 1986 podporuje ochranu pamati a strankovanie - 2 zakladne faktory pre slusny memory managment. Organizacia pamate sa teda deli na 2 na sebe postavene vrstvy:

• segmentacia - pamat je mozne rozdelit do lubovolne velkych blokov, ktore zacinaju na lubovolnom mieste v pamati. Je mozne zabezpecit, aby segmenty nesuce kod programu neboli citatelne, takisto je mozne zabezpecit, aby procesy nevedeli pristupovat do pamate inych procesov (to napriklad po windows 95 nebolo splnene, pri windows 95 a vyssich iba pre plne 32bitove programy), ani ju vobec nevideli (nevidiet znamena nevediet ju adresovat - pamat z pohladu ineho procesu neexistuje, a co nevidis, na to nemozes utocit). Na platforme x86 a od nej odvodenych je segmentacia povinna a neda sa vypnut (dodatok nizsie)
• strankovanie - pamat je mozne rozdelit do blokov konstantnej velkosti (tzv. stranok) obvykle velkych 4kB. Proces prekladu strankovanej pamate zabezpeci preklad adresy ziskanej z prekladu segmentovanej pamate na fyzicku adresu v pamati. Vyhodou strankovania je, ze je nim mozne zabezpecit, aby 2 rozne procesy pouzivajuce 2 rozne segmenty pamate vyuzivali fyzicky tu istu pamat, cim sa jednoznacne pamat setri. Dalsim vyuzitim strankovania je lahsia podpora virtualnej pamate, nez pri segmentovani, nakolko sa lahsie pracuje s blokmi konstantnej velkosti, nez s blokmi variablinej velkosti. Strankovanie je na x86 platforme volitelne a standardne je vypnute, aj ked ho dnes pouzivaju snad vsetky operacne systemy bezne prevadzkovane.

Kazdy proces sa obvykle sklada z troch casti:

1. kod procesu - obsahuje vykonatelny kod programu, zodpoveda mu kodovy segment, ktory nie je zapisovatelny a casto ani citatelny. Pri pokuse o zapis do tohto segmentu vyvola procesor chybu ochrany pamate a program bude operacnym systemom s najvacsou pravdepodobnostou zostreleny.
2. data procesu - obsahuje data programu, skladaju sa zo statickych dat (ktore su zname uz v case zostavovania programu - obvykle retazce, konstantny a podobne) a miesta pre dynamicke data (vstupy uzivatela, nacitane data a dalsie). Zodpoveda im datovy segment, ktory moze byt volitelne zapisovatelny, ale citatelny je vzdy. Vykonavanie programu sa neda preniest do datoveho segmentu. Pri pokuse o vykonanie niecoho v datovom segmente procesor vyhlasi vynimku ochrany a operacny system proces zostreli.
3. zasobnik - je oblastou, do ktorej pristupuju dve specialne instrukcie procesora PUSH a POP. Jedna sa o LIFO (last-in first-out) strukturu, teda zo zasobnika je mozne vybrat len to, co je navrchu, nove data mozno taktiez polozit len na vrch zasobnika. Vyhodou je to, ze ak sa dodzi poradie a mnozstvo dat pri vkladani a vyberani (pri vyberani je poradie presne opacne), netreba si pamatat adresu ukladanych dat, su vzdy na vrchole zasobnika. Zasobniku zodpoveda stack segment. Tento segment musi byt zapisovatelny, v opacnom pripade pri pokuse o pouzitie segmentu vyvola procesor vynimku a operacny system proces zostreli.

Programy pracuju s adresami v tvare Segment:Offset (tomu sa hovori logicka adresa), ta sa segmentaciou meni na linearnu adresu v tvare Offset [od zaciatku linearnej pamate] a tato linearna adresa sa strankovanim meni na fyzicku adresu pamati v tvare Offset [od zaciatku skutocnej pamate procesora]. Pri strankovani ale nie je zakazane premapovat 2 oblasti linearnej pamate na tu istu oblast fyzickej pamate.

Do zasobnika sa najcastejsie ukladaju navratove adresy podprogramov (ked volate podprogram, obvykle sa chcete vratit a pokracovat v behu programu tam, odkial ste podprogram zavolali, tak si adresu nasledujucej instrukcie hodite na vrch zasobnika (hodi ju tam procesor) a idete vykonavat podprogram). Je to preto, lebo pri navrate z podprogramu je velmi jednoduche urcit, kde v pamati sa navratova adresa nachadza - je na vrchole zasobnika. Ak sa tam nenachadza, tak bud programator vo vnutri programu pouzil nesparovanu PUSH / POP operaciu, alebo je program blbo napisany - jednoducho padne, pretoze sa zo zasobnika ako navratova adresa vytiahne nejaka somarina a program skonci s chybou neplatna instrukcia, alebo chyba segmentacie - jednoducho zacne v lepsom pripade vykonavat nieco, co nie je kod, v horsom pripade zacne citat pamat, ktora neexistuje. Zasobniku sa tolko venujem preto, lebo je pre vykonanie buffer overflow klucovy. Ako som napisal vyssie, ak PUSH a POP nie su sparovane, pri navrate z podprogramu sa precita namiesto navratovej adresy podprogramu (adresa instrukcie, ktora by sa mala vykonavat) nejaka somarina, ktora moze byt ina navratova adresa podprogramu o uroven vyssie, alebo docasne ulozene data na zasobniku z predoslej funkcie.

Uvazujme vsak, ze sa nam podari prepisat navratovu hodnotu v zasobniku tak, aby to bolo pre nas uzitocne (napriklad aby sa zacal vykonavat program na inom mieste, nez chceme). Tomtu aktu brani hned niekolko veci. V prvom rade program len tak sam od seba nepojde prepisovat zasobnik, pretoze to robit nepotrebuje a ani velmi nevie (pokial v kode programu nieco take nie je, tak to nie je v jeho silach), ak potrebuje pouzije instrukcie push a pop, nebude donho priamo sahat a jednak je dost tazke ho k tomu donutit. Aby sme ho k tomu nainstruovali, potrebovali by sme prepisat kod v kodovom segmente, ktory vsak nie je zapisovatelny, na zapis do kodoveho segmentu vsak potrebujeme prava kernelu (ked ich mame, je nam nanic utocit na obycajny program). Je to proste zacarovany kruh. Vsetky tieto obmedzenia platia, pokial predpokladame, ze kodovy, datovy a segment zasobnika sa v pamati neprekryvaju.

Uz v dokumentacii k procesoru Intel 80386 (rok 1986) sa pisalo, ze ak ma 386tka simulovat procesory, kde neexistuje segmentacia (napriklad procesory Motorola MC68000), segmentaciu sice nie je mozne vypnut, ale je mozne nastavit ju tak, aby sa procesor tvaril, ze ju nepouziva. Robi sa to tak, ze kodovemu, datovemu aj zasobnikovemu segmentu sa nastavi adresa ich zaciatku na adresu 0 (pociatok pamate) a velkost segmentu na 4GB (maximalna mozna velkost pri 32bitovych procesoroch). Tym sa efektivne odstavia vsetky mechanizmy kontrolujuce segmentaciu a nemoze dojst k vyvolaniu chyby na urovni segmentov. Tomuto pamatovemu modelu sa hovori flat memory model (kazdy program ma pristup k celej pamati procesora).

Prave flat memory model otvoril cestu k existencii buffer overflowu v spojeni s chovanim sa kodu napisaneho v jazyku C.

Flat memory model sa pouziva v zrejme valnej casti dnesnych operacnych systemov. Mohlo by sa na prvy pohlad zdat, ze nie je prilis bezpecny, lebo kazdy proces vidi celu pamat procesora, ale nie je tomu tak. Vdaka strankovaniu je mozne pamat virtualizovat a kazdemu procesu pridelit jeho vlastnu virtualnu pamat. Vyhodou oproti modelu segmetovanej pamate je v tom, ze kazdy program zacina na linearnej adrese 0 a nemusi brat v ohlad segmentove casti adries. Druhou nespornou vyhodou je, ze ak sa zavedie segmentacia aj strankovanie, vysledny memory managment je velmi komplikovany a je jednoduchsie starat sa o managment na urovni stranok, nez o managment na urovni segmentov (ako bolo spomenute vyssie, lahsie sa prideluju a uvolnuju bloky pamate pevnej velkosti, ako dynamickej velkosti a navyse stranky sa daju pridelovat za letu, ale to je uz ina rozpravka).

To je prvy z faktorov platformy. Vo vacsine operacnych systemov sa teda kod, data a zasobnik prekryvaju.

Druhym faktorom platformy je chovanie Cckovskych (ale zrejme aj inych reentranciu podporujucich programovacich jazykov) programov. Premenne sa totizto rozdeluju na globalne a lokalne. Lokalne premenne platia len v ramci jedneho volania funkcie, globalne premenne su pristupne v celom programe. Jazyk C vsak nezistuje, kolko krat po sebe (vnorene) sa funkcia zavola a ci nevola sama seba. V skutocnosti toto zrejme ani v rozumnej miere overovat nejde. Preto nemozu byt lokalne premenne funkcie ulozene na pevnom mieste v pamati (pri druhom volani funkcie, ak este predosle volanie neskoncilo, by sa data prepisali a program by zrejme padol).

Vhodnym miestom pre ulozenie tychto dat sa preto stava zasobnik. Do zasobnika ako takeho sa sice priamo nezapisuje, ale adresa niecoho v zasobniku je taka ista, ako adresa toho isteho v datovom segmente (a je taka ista, ako adresa niecoho v kodovom segmente). Programy preto vyuzivaju tzv. stack frames. Pri vstupe do podprogramu si tento vyhradi tolko miesta, kolko potrebuje na ulozenie lokalnych premennych a do tohto miesta potom cez datovy segment zapisuje. Vyhodou je, ze moze do zasobnika sucasne zapisovat cez datovy segment do lokalnych premennych a nadalej vyuzivat instrukcie push a pop (ktore operuju mimo tychto dat a z ich pohladu su to len data zasobnika a spravne napisany program sa k nim nedostane).

Poslednym faktorom platformy je chovanie sa zasobnika. So zasobnikom sa operuje vyhradne pomocou operacii PUSH a POP (ak opomenieme jeho inicializaciu). operacia PUSH do zasobnika vlozi udaj pevnej velkosti (obvykle 16, 32 alebo 64 bitov) a posunie vrchol zasobnika o tuto velkost hore. Pri tom sa neuchovava informacia o velkosti, ani adrese objektu, ktory tam bol ulozeny. To ani netreba, totizto data sa daju vytiahnut len z vrcholu zasobnika (netreba adresu, vrchol zasobnika je urceny systemovym registrom) a predpoklada sa, ze velkost objektu bude kod, ktory ho vybera, poznat. Zasobnik je vsak mierne postaveny na hlavu, totizto u zasobnika je dno (adresa 1. vlozeneho udaju) na vyssej adrese, ako vrchol (adresa posledneho vlozeneho udaju) zasobnika. Zasobnik "rastie" k nizsim adresam, to znamena, ze ak do zasobnika vkladame data, vrchol zasobnika smeruje k nule. Toto chovanie sa v minulosti vyuzivalo najma k zistovaniu pretecenia zasobnika. Nastavit velkost zasobnika, ktory rastie hore, by si vyziadalo zaviest register najvacsej povolenej adresy v zasobniku a vzdy ho overovat. To by skomplikovalo procesor, program a na lacnych platformach, ako 8051 a 8080 sa nenosilo. Preto sa zvolil opacny pristup. Pri starte programu sa nastavi vrchol zasobnika na nejaku adresu (vzhladom k tomu, ze v zasobniku nic nie je, je vrchol sucasne aj dnom zasobnika), pridavanim dat do zasobnika bude adresa vrcholu stupat a ked dosiahne 0, zasobnik je zaplneny a program padne (nic dalsie sa donho uz nezmesti). Nevyhodou bolo, ze nebolo ako zistovat podtecenie zasobnika (tahanie dat z prazdneho zasobnika), ale to zas nebol tak casty jav, ktory navyse vznikal len nespravne napisanym programom, zatial co pretecenia mohlo vzniknut aj nespravne nastavenym operacnym systemom.

Toto chovanie sa zachovalo, aj ked pri flat memory modeli sa nepouziva detekcia pretecenia zasobnika tymto sposobom, ale nejako inak (netusim, ako).

Opacny rast zasobnika sposobi, ze ak zapisujeme do oblasti zasobnika nieco, co je vacsie, nez miesto pre to vyhradene a pretecie nam to cez buffer, prepise nam to veci, ktore boli v zasobniku skor, ako bol vyhradeny stack frame. Je to sposobene tym, ze hoci je buffer v oblasti zasobnika, ta stale rastie smerom k vyssim adresam. Tam sa nachadza aj navratova hodnota z funkcie, kedze stack frame si tvori funkcia a navratovy kod zapisuje do zasobnika procesor pred spustenim funkcie.

Ak sa na situaciu pozrieme teraz, vidime, ze mame program, ktory "zapisuje do zasobnika", cize ak ho prinutime prepisat navratovu adresu, moze program skocit na lubovolne miesto, kam my chceme. Mame teda moznost prinutit program k tomu, aby zmenil svoj obvykly tok, to je nam vsak nanic, ak mu nemozeme prikazat robit nieco, co normalne nerobi, preto musime do programu pred samotnym prepisom navratovej adresy tento kod dostat a potom sa donho "vratit".

Pri tomto injektovani kodu do programu je hlavnym pomocnikom fakt, ze jazyk C si bezne nestrazi rozsahy poli a adresa dat v datovom segmente je rovnaka ako adresa tych istych dat v zasobniku a je rovnaka ako adresa tych istych dat v kodovom segmente. To dava moznost pouzit data ako obsah zasobnika, alebo vykonatelny kod.

Kedze sa mi tu ta teoria mierne (neplanovane) rozflakla, na tomto mieste to ustrihnem. Dalsia cast sa bude venovat praktickejsej ukazke toho, ako nevinne taky buffer overflow moze vzniknut, co vsetko sa nim da dosiahnut a nejake doplnkove informacie. Bude sa mihat takymi obskurnostami, ako vykonavanie dat, prepis kodu, skok na zasobnik, ktore su v tazkom rozpore s tym, co bolo povedane vyssie, ale ukaze sa, ze co je teoreticky nemozne, je v skutocnosti relativne lahko vykonatelne.