Závažná vzdálená zranitelnost v DNS serveru NSD 3

V blogu CZ.NIC vyšel článek Ondřeje Surého týkající se vážné zranitelnosti NSD 3. Na problém přišli při testování DNS serveru Knot DNS jeho vývojáři Marek Vavruša a Ľuboš Slovák. Ondřej Surý v textu s názvem Závažná vzdálená zranitelnost v DNS serveru NSD 3 kromě jiného píše: "Při testování se ukázalo, že NSD ve všech verzích 3.x (i vývojové verzi 4.x) obsahuje zranitelnost, která je zneužitelná pro pád DNS serveru z libovolného místa v Internetu. Při přijmutí takové DNS zprávy dojde k dereferenci NULL pointeru a NSD spadne s chybou SIGSEGV." Aktuální blogpost obsahuje i opravný patch. O problému vědí i vývojáři DNS serveru NSD, kteří operativně reagovali na upozornění českých kolegů a krátce poté poslali opravný patch.

20.7.2012 09:54 | Vilem Sladek | Bezpečnostní upozornění

Komentáře

[Marek]

Kontroluj pointery, kontroluj pointery, kontroluj pointery nebo ti to spadne.

[little.owl]

Při přijmutí takové DNS zprávy dojde k dereferenci NULL pointeru a NSD spadne s chybou SIGSEGV.

A to je pritom jediny pripad, kdy vam nejaka kontrola pomuze (NULL) ....

[Marek]

Nebo použij reference (nejsou v C), ty nemůžou být NULL-ové, nebo lépe nullptr-ové. Stále však mohou referencovat neplatnou paměť (dangling reference).

[pavlix]

A technicky je za tím zase obyčejný pointer :).

[little.owl]

Ale checkovany pri kompilaci ....

[pavlix]

Odvážné tvrzení.

[little.owl]

OK, jiste, mohu dat treba referenci jiz neexistujiciho objektu, nicmene u systemu bez dynamicke alokace je riziko minimalni; plusem je typove kontrola, a v kombinaci s pclintem se da odhalit kupa chyb velmi brzy.

[pavlix]

Tak zrovna u pclint wikipedie uvádí, že je určený pro C a C++, kteréžto oba používají explicitní dynamickou alokaci.

Konkrétně v tom C++ probíhá pokud vím kontrola reference i ukazatelů naprosto stejně a podle stejných pravidel.

[little.owl]

kteréžto oba používají explicitní dynamickou alokaci.

Tohle neni zalezitost jazyka, ale jak ho pouzivate. U cele rady projektu neni dynamicka alokace pomoci new/delete/malloc/free/* povolena a veskera pamet musi byt alokovana staticky, viz. treba MISRA C; pak je jedinym problemem reference na objekt alokovany na stacku (uhlida pclint).

PcLint je jen nastroj, kteremu predhotite konfiguracni soubor s pravidly (treba pro MISRA C) a on vam udela statickou analyzu kodu zdali jsou pravidla dodrzena a testovani jde nad ramec C/C++ standardu.

v tom C++ probíhá pokud vím kontrola reference i ukazatelů naprosto stejně

Nemyslim, zejmena pokud jde o implicitni konverze parametru. Je rozdil pokud predavate parametry pouzivaje pointer na void ci referenci na urcity datovy typ. Nebo dynamic_cast vam vyhodi vyjimku, pokud je vystupem reference a ne pointer, kdyz konverze dopadla spatne: muzete mit nulovy pointer ne vsak nulovou referenci. Dalo by se toho nalezt vice.

[pavlix]

Tohle neni zalezitost jazyka, ale jak ho pouzivate.

Tedy s/používají/nabízejí/. Nicméně, ať používám jazyk jak chci, vždy musím volit z prostředků, které mi nabízí (a které mi nabízejí dostupné knihovny a nástroje).

Nemyslim, zejmena pokud jde o implicitni konverze parametru. Je rozdil pokud predavate parametry pouzivaje pointer na void ci referenci na urcity datovy typ.

Toto vnímám jako pouhopouhou manipulaci. Tvrdil jsem něco jiného, než co vyvracíš.

Nebo dynamic_cast vam vyhodi vyjimku, pokud je vystupem reference a ne pointer, kdyz konverze dopadla spatne

Zdroj?

muzete mit nulovy pointer ne vsak nulovou referenci.

Nulový pointer nemá s typovou kontrolou nic společného. Je to validní a explicitně povolená hodnota. Nicméně bych netvrdil, že je problém vytvořit nulovou referenci. I když samozřejmě lze zavést proti tomu kontroly a je zcela jistě v C++ nevalidní, lze ji nahradit speciální instancí, jako se to dělá třeba v Pythonu.

Dalo by se toho nalezt vice.

Spíš mám pocit, že se zatím nenašlo nic.

[little.owl]

Toto vnímám jako pouhopouhou manipulaci. Tvrdil jsem něco jiného, než co vyvracíš.

Rekl bych, ze jsme si neporozumeli. Nektere kodovaci standardy zakazuji pouzit dynamickou alokaci, bez ohledu na to, ze jazyk nebo standardni knihovna pro to poskytuji nastroje - tim jsem myslel ono "systemu bez dynamicke alokace" - a jde to.

Psal jste:

Konkrétně v tom C++ probíhá pokud vím kontrola reference i ukazatelů naprosto stejně a podle stejných pravidel.

Pak by bylo dobre upresnit, co tim myslite. Reference a pointer jsou z hlediska C++ jine veci a jsou na ne take kladeny jine pozadavky, z toho plyne i jinak provadena kontrola kompilatorem. To ze nakonec z reference na urovni generovaneho kodu muze byt "obycejny" pointer na tom nic nemeni.

Nebo dynamic_cast vam vyhodi vyjimku, pokud je vystupem reference a ne pointer, kdyz konverze dopadla spatne

Zdroj?

A jsme u jednoho rozdilu. Bible C++, primo standard, sekce 5.2.7/9:

The value of a failed cast to pointer type is the null pointer value of the required result type. A failed cast to reference type throws bad_cast (18.5.2).

Vyjimku zachytim a zpracuji, s access violation je to slozitejsi.

Nulový pointer nemá s typovou kontrolou nic společného.

Ma, viz vyse uvedeno, tedy pokud tedy nechcete tvrdit ze dynamic_cast nema nic spolecneho s typy a RTTI.

[pavlix]

Rekl bych, ze jsme si neporozumeli. Nektere kodovaci standardy zakazuji pouzit dynamickou alokaci, bez ohledu na to, ze jazyk nebo standardni knihovna pro to poskytuji nastroje - tim jsem myslel ono "systemu bez dynamicke alokace" - a jde to.

Ono by to pořád ještě chtělo upřesnit. Protože slovo dynamická alokace se IMO používá pro to, že alokuju paměť podle potřeby, což je v běžných aplikacích prakticky nutnost. Takže zřejmě to vyjádření „zakázat dynamickou alokaci“ pro tebe znamená něco jiného, než jak je to podle mě běžně chápáno.

Psal jste:

Prosím nevykat.

Pak by bylo dobre upresnit, co tim myslite.

Můžeš začít.

Reference a pointer jsou z hlediska C++ jine veci a jsou na ne take kladeny jine pozadavky, z toho plyne i jinak provadena kontrola kompilatorem. To ze nakonec z reference na urovni generovaneho kodu muze byt "obycejny" pointer na tom nic nemeni.

Nicméně z toho nevyplývá nic o typové kontrole.

A jsme u jednoho rozdilu. Bible C++, primo standard, sekce 5.2.7/9:

Výborně. Akorát na první pohled to ve mně vyvolává pocit, že je to návrhová vada.

Ma, viz vyse uvedeno, tedy pokud tedy nechcete tvrdit ze dynamic_cast nema nic spolecneho s typy a RTTI.

To bych si nedovolil. Jen jsem čekal na nějakou smysluplnou informaci, a té se mi nedostalo tak úplně hned.

[little.owl]

Ono by to pořád ještě chtělo upřesnit. Protože slovo dynamická alokace se IMO používá pro to, že alokuju paměť podle potřeby

Tak definice dynamicka/staticka/automaticka alokace jsou ve svete C/C++ jednoznacne pojmy. V pripade staticke alokace kompilator zna [relativni] adresu objektu/dat uz behem kompilace, v pripade dynamicke alokace, ktera se dela za behu tu informaci nema. Proc jsem to uvadel - pokud se dynamicka alokace nepouziva, je zatracene slozite mit neplatnou referenci, neb jedina rozumna cesta jak ji vytvorit je referovat na promennou automaticky alokovanou na stacku a to lze uhlidat.

, což je v běžných aplikacích prakticky nutnost.

Lze psat aplikace i bez dynamicke alokace, a u kritickych systemu je to casto nutnost, jinak to neprojde certifikaci; nikdo proste nechce aby pacos umrel nebot se jeho ridicimu procesoru umelych plic po peti dnech chodu fragmentoval heap.

Psal jste:

Prosím nevykat.

Pokusim se, rozsirim sva pravidla o podminkach tykani na nutnost prezit vzajemny flame bez urazek, a to jsme jiz v minulosti splnili.

Reference a pointer jsou z hlediska C++ jine veci a jsou na ne take kladeny jine pozadavky, z toho plyne i jinak provadena kontrola kompilatorem. To ze nakonec z reference na urovni generovaneho kodu muze byt "obycejny" pointer na tom nic nemeni.

Nicméně z toho nevyplývá nic o typové kontrole.

Vyplyva z cele rady bodu ve standardu C++, nechce se mi je ted hledat, jsem utahan. Napriklad neni mozne vzit referenci jednoho typu a priradit ji referenci druheho typu, kompilator tady testuje typ reference. U pointeru mohu C-kovsky pretypovat cokoliv na cokoliv, kompilator sice nekdy vygeneruje warning (na to se kasle), ale pusti to; v pripade reference mas kompilacni chybu - smula a podobne u parametru funkci; proste u referenci jsou striktnejsi pravidla a tudiz vice testovani ze strany kompilatoru.

A jsme u jednoho rozdilu. Bible C++, primo standard, sekce 5.2.7/9:

Výborně. Akorát na první pohled to ve mně vyvolává pocit, že je to návrhová vada.

Neni. Jak bys jinak testoval smysluplnost a bezpecnost konverze v hiearchii mnoha trid s vicenasobnou dedicnosti, zejmena kdyz trida vubec nemusi mit predka na ktereho konvertujes? A navic, co byl mel dynamic_cast vratit krom NULL pointeru, kdyz konverze proste nedava smysl a vyhodit vyjimku kdyz NULL reference neexistuje?

[pavlix]

Lze psat aplikace i bez dynamicke alokace, a u kritickych systemu je to casto nutnost, jinak to neprojde certifikaci; nikdo proste nechce aby pacos umrel nebot se jeho ridicimu procesoru umelych plic po peti dnech chodu fragmentoval heap.

versus

což je v běžných aplikacích prakticky nutnost.

Mimochodem, jak se v takových případech řeší hloubka zásobníku? Vyloučí se nechráněná rekurze a udělá se statická analýza programu, jak hluboký zásobník maximálně využije?

Pokusim se, rozsirim sva pravidla o podminkach tykani na nutnost prezit vzajemny flame bez urazek, a to jsme jiz v minulosti splnili.

Díky.

v pripade reference mas kompilacni chybu

V C++ už jsem hodně dlouho nedělal, takže se dá říct, že ten jazyk už neumím (aspoň si nepamatuju tyhle detaily a některé z nich jsem možná ani neřešil). Ale nepodléhají náhodou reference polymorfii stejně jako pointery?

A navic, co byl mel dynamic_cast vratit krom NULL pointeru, kdyz konverze proste nedava smysl a vyhodit vyjimku kdyz NULL reference neexistuje?

Tak skoro bych čekal, že opatrný cast bude schopný při runtime chybě vyhodit výjimku. Ale možná jsem opravdu zhýčkaný z Pythonu, kde se každá runtime chyba (kromě nízkoúrovňové magie či problému v C knihovně) projeví výjimkou.

[little.owl]

Mimochodem, jak se v takových případech řeší hloubka zásobníku? Vyloučí se nechráněná rekurze a udělá se statická analýza programu, jak hluboký zásobník maximálně využije?

Rekurze nejsou samozrejme povoleny. Ohledne velikosti stacku, delam analyzu calltree a meri se jeho hloubka, a analyzuje se i velikost objektu uklozenych na stacku a jeho vyuziti za behu. Metody jsou ruzne, moje oblibena metoda je modifikace prologu funkci, zalezi na architekture, kompilatoru a pouzitem OS.

Tak skoro bych čekal, že opatrný cast bude schopný při runtime chybě vyhodit výjimku.

Tak ono lze prekladat C++ code s disablovanim vyjimek ci disablovanim RTTI a tahle specifikace pak umoznuje napsat implementaci, ktera zajisti rozumnejsi chovani codu/kompilatoru v takovem pripade.

[pavlix]

Rekurze nejsou samozrejme povoleny.

Já si říkám. Ačkoli bez rekurze nemáš k dispozici ekvivalentní výpočetní sílu (myslím úplně bez rekurze, tedy i bez jejího modelování zásobníkem).

Tak ono lze prekladat C++ code s disablovanim vyjimek ci disablovanim RTTI a tahle specifikace pak umoznuje napsat implementaci, ktera zajisti rozumnejsi chovani codu/kompilatoru v takovem pripade.

No… on je velký rozdíl mluvit o C++ v kontextu jeho běžného použití a o C++ s těmito omezeními a ještě navích chováním upraveným kompilátorem. Rozhodně je to zajímavé téma, ač už jsme sedostali trochu jinam.

Ale pro mě je to teď opravdu jen pro zajímavost, protože se v nejbližší době nechystám na žádném takovém projektu pracovat.

[tom]

Kontroluj pointery, kontroluj pointery, kontroluj pointery nebo ti to spadne.

Tak todle pravidlo je pekna <>. Pokud je invariantem programu to, ze dany pointer pokazde ukazuje na data, tak tim akorat zamaskujete chybu nekde jinde.

[Marek]

Ano jistě, ale co je podle Vás lepší:

• program vynechá nějakou činnost (chová se divně, ale bezpečně)
• program spadne nebo ještě hůře přepíše nějakou paměť a spadne později nebo spustí nějaký (podstrčený) kód

[little.owl]

Testovat pointery na NULL ma smysl predevsim jen tehdy, pokud konzistentne v mistech kde je zneplatnite je zaroven nastavujete na NULL, jinak to jen indikuje chybejici inicializaci.

[finn]

Tady mi to připadá tak, že nebyly řádně ošetřené vstupy, tj. program se zhroutil, pokud přijal paket s daty, která nepředpokládal. Kontrola na NULL pointer by tenhle primární problém nevyřešila, program by asi nespadl, ale choval by se nějspíš divně.

[pavlix]

Podle mě je lepší se s tím takhle nesrat a snažit se, aby byl program robustní. Pokud mi v tom pomůže kontrola pointeru, OK. Pokud ne, taky OK.

[Luboš Doležel (Doli)]

Ještě že mám dokonale bezpečný BIND... oh wait

[Dreit]

Výborně   Je vidět že naše testovací praktiky jsou na úrovni a že práce na jednom projektu může pozitivně ovlivnit i ostatní projekty, dobrá práce