Integer overflow v libxml2 (diskuse)

[Thyrst']

Stane se :)

[Maruška]

Co by tomu řekl Jára Cimrman

[Jardík]

Hmm, hodně stará informace, která byla součástí changelogu Chromia, na který bylo odkazováno v některé starší zprávičce. Bude to něco přes měsíc, co to tu bylo.

[Jardík]

Jinak integer overflow je šmejd a nejčastěji se nachází o programů, co používají znaménkový int (a nebo i neznaménkový, ale znaménkový je podstatně horší, protože overflow znaménkového typu v C = může se stát cokoliv od "nic se nestalo" po smazání uživatelova adresáře, proč? Protože standard) místo neznaménkového size_t.

[Voty]

Já vždycky doufám, že mi to objedná pizzu a ono pokaždý nic :(

[Zvedavec]

Cira zvedavost: Jak muze preteceni integeru dovolit utocnikovi spustit libovolny kod? Cekal bych nedeterministicke chovani, segfaulty a podobone, ale tohle fakt ne... Diky za vysvetleni.

[D.A.Tiger]

Je to jen čirá spekulace, ale předpokládám, že to souvisí s maximální velikostí typu int na dané platformě - místo toho, aby byla hodnota uložená v proměnné ořezána tak ji program zkusí na hulváta narvat do paměti a tím ji asi protuneluje do dalšího segmetu paměti, který už však nemá alokovaný. Pokud by tam byl nachystaný vhodný exploid tak se asi tím pádem spustí. Proč to neodchytí systém a aplikaci nesestřelí, v tuto chvíli netuším. Každopádně divné mi to je taky a navíc si nemyslím, že by to bylo zas tak jednoché....

[:::]

taky by me zajimalo jak je to mozny

jinak ten tvuj pokus o vysvetleni, jestli jsem ho pochopil, tak neni spravne. Kdyz si predstavis kod v asm, tak tam je presne dany jak je ktery registr velky a s kolika byty pameti instrukce pracuje. Ne ze by si procesor vsimnul ze mu vyslo velky cislo a tak pouzil vetsi typ a neco prepsal

[Voty]

Nevím jak je to v tomto konkrétním příkladě, pač ten patch jsem moc nepochopil :( Ale podle normy (jak již psal Jardík) je možné, aby po přetečení znaménkového typu došlo k čemukoliv a optimalizace překladače toho obvykle dost zneužívají.

[ewew]

Prikladám link na Debian Bug report log.Posledná správa hovorí čo má robiť daná úprava.Vážnosť chyby je označená ako vysoká. Na prvom linku v správičke je napisané, že ide o integer overflow.

[D.A.Tiger]

Já to začínám chápat (ona v tom možná hraje roli i moje poměrně blbá angličtin) tak, že jim nepřetíká int jako takový, ale buď ukazatel na int, nebo přímo celý pole typu int. A jen blbě zvolily titulek. Každopádně jasnější by to bylo, kdybych měl někde úryvek toho kódu, žel bohu, odkaz na to jsem nenašel...

[Jardík]

No ono to může být přetečení intu. Jestli někde libxml používá int místo size_t a narazí na nějaký vstup s "velkou velikostí", tu narve do intu, tam to přeteče, nebo to přeteče po přičtení něčeho, na dané platformě se to třeba může zachovat (kromě smazání disku ^^) třeba uložením záporného čísla (třeba -1) a pak ten trotl zavolá malloc(můj_záporný_int) a ono mu to vyprskne třeba nějaký malloc(SIZE_MAX), což by mohl vysvětlovat nějaký ten patch omezující malloc na 512M. Ale popravdě netuším, co se tam děje za voloviny, nějak jsem to nezkoumal a ani se mi nechce.

[Jardík]

Jinak tohle v tom patchi, to je opravdu vopičárna:

*(volatile char*)0 = '\0';
return NULL;

jejíž jediným smyslem je zabránit rozpadnutí se zřejmě rozbitého kódu, který si nic jiného než rozpadnutí nezaslouží.

[Voty]

Jojo, to mě docela rozesmálo. Být překladačem, tak to klidně budu ignorovat :)

[Martin Mareš]

To se u čehokoliv, co je volatile, jaksi nesmí.

[Voty]

Pokud je to zároveň undefined behavior, tak bych řekl, že se to může. Nevidím důvod, proč by se UB nemohlo projevit právě tím, že se daný statement neprovede :)

[Michal Kubeček]

Asi z nějakého důvodu nechtěli nebo nemohli použít abort() - akorát mne žádný nenapadá.

[Michal Vyskočil]

To bude proto, že tohle je oprava od Chromia pro jejich sandbox, kde je to afaik ta korektní cesta.

[little.owl]

A to opravdu nazyvaji "oprava"?

[Michal Kubeček]

To je jen obrat pro případ, že by někdo zavolal xmlMalloc() s parametrem větším než 2^29. Ale není mi moc jasné, proč v takovém případě prostě nevrátit NULL, jak je ve slušné společnosti zvykem, nebo když už se rozhodli nechat takový program zhavarovat, proč nepoužili funkci abort(), která je k tomu určená.

[little.owl]

Nejspis chteji program ukoncit misto vraceni NULL nebot plno PC programatoru proste netestuje navratovou hodnotu u alokace pameti a architektura aplikaci nemusi byt pripravena na pripadne selhani; rychly fix pak proste casto neni mozny. V pripade nepouzitu abort() se mozna chteji vyvarovat pripadu kdy aplikace maji SIGABRT handler. Jen spekuluji.

[Michal Kubeček]

To je možné vysvětlení. Ještě mne napadlo, že by to mohlo být kvůli nějakým platformám, kde abort() není nebo nedělá co má, ale ta funkce je předepsaná ISO normou jako součást standardní C knihovny, takže to by snad hrozit nemělo.

[pavlix]

Ještě mne napadlo, že by to mohlo být kvůli nějakým platformám, kde abort() není nebo nedělá co má, ale ta funkce je předepsaná ISO normou jako součást standardní C knihovny

Jenže little.owl psal o případu, kdy abort() k dispozici je a podle normy se chová, tedy pokud ISO nedefinuje abort() výrazně odlišně od jiných zdrojů (první, co mi vypadlo z googlu).

[Michal Kubeček]

Čeština má holt málo časů, to "ještě mne napadlo" byla zmínka o další možnosti, o které jsem uvažoval před jeho příspěvkem (a před příspěvkem Michala Vyskočila).

[pavlix]

Spíš já blbě čtu.