Bezpečnostní chyba v Bind9 (Vzdálený DoS) (diskuse)

[Xerces]

FLAME - nemá být spíše: Aktualizujte co nejrychleji na nejnovější verzi, nebo úplně jiný DNS?

[Foo Bar]

Názory patří do blogu a ne do bezpečnostní zprávičky.

Jinak změna na jiný DNS bez rozmyslu je stejně škodlivá. Monokultura jako monokultura.

[Foo Bar]

Mohl by editor laskavě zpátky změnit jméno na "MICHA Krause"? Michal Krause s tím nemá nic společného :(. Když už má pocit, že je zapotřebí dělat opravy, tak by bylo fajn si to jméno aspoň ověřit v tom bugreportu.

[Tomáš Heger (geckon)]

Opraveno.

[Foo Bar]

Další testování ukázalo, že DNS server musí být pro zónu master. Čímž do toho spadá i většina rekurzivních serverů, které se řídí rfc1912 (sekce 4.1 - zóny localhost, etc.).

[zajdee]

Podle toho exploitu to vypadá, že je zneužitelný jen tehdy, je-li zóna updatovatelná a mám-li platný klíč k podepsání updatu. Je tomu tak, nebo jsem to jen nepochopil správně? 

[Michal Kopecny]

No, mne to s uvedenym exploitem shodilo server i bez klice a nemam updatovatelne zony ;)

Ale debian uz vydal zaplaty, takze je to ok ...

 

Michal

 

[zajdee]

Mi bind jen zalogoval

Jul 29 11:43:46 xxx named[21366]: client xxx#35187: request has invalid signature: TSIG xxx: tsig verify failure (BADKEY)

pro reverzni zonu, ktere jsem master, kdyz jsem si vymyslel aktualizacni klic, a dal bezi...
 

[Michal Kopecny]

No, ja klic proste nenastavoval a server jsem zhodil ;)

 

[Foo Bar]

No, ok to bude až ve chvíli, kdy lidi tu aktualizaci nasadí :)

[petr_p]

Zatím jenom na řadu 9.6.

[Foo Bar]

Pletete se, v debian-security (DSA-1847-1) tohle dopoledne vyšly aktualizované verze pro oldstable, stable.

For the old stable distribution (etch), this problem has been fixed in version 9.3.4-2etch5.

For the stable distribution (lenny), this problem has been fixed in version 9.5.1.dfsg.P3-1.

For the unstable distribution (sid), this problem has been fixed in version 1:9.6.1.dfsg.P1-1.

[trekker.dk]

A v testing prd... jako vždy

[Foo Bar]

http://www.debian.org/releases/testing/ http://lists.debian.org/debian-testing-security-announce/2008/12/msg00019.html

[trekker.dk]

Njn, aplikovat patch a vydat nový balíček je holt zjevně i v případě takto kritické chyby příliš obtížné... stejně jako tenkrát u té chyby v OpenSSH, kdy se na opravu v testing čekalo tři dny.

[Foo Bar]

Co je tak těžkého na tom pochopit, že testing aktuálně bezpečnostní aktualizace nemá? Pokud s tím máte problém, používejte stable. Přesně tak, jak se píše v již odkazovaném emailu.

[petr_p]

No, v době kdy jsem to kontroloval, tak stav byl takový, jaký jsem popsal. A jako napotvoru testing, který používám, je stále bez patche. Ale to se časem podá :(

[danysek]

Rychlym workaroundem muze byt:

iptables -A INPUT -p udp --dport 53 -j DROP -m u32 --u32 '30>>27&0xF=5'

Prevzato  z debian mailing listu k teto chybe (a opravny balicek je u debianu uz take na svete).

[Stanislav Petr]

Akorat bych to asi nezkousel na vic zatizenejch DNS serverech. Rychlost u32 klasifikatoru neni z nejlepsich.

[the.max]

Stale me nekdo presvedcuje jak BIND je super, at na nej prejdu... a ja porad radeji zustavam u PowerDNS a jak je videt, delam dobre.

[Käyttäjä 11133]

On ten PowerDNS snad vzdáleně zneužitelné bugy nemá? Například tady jeden.

[Filip Jirsák]

Mně to připomnělo jeden téměř rok starý komentář:

Jen doufam, ze si Kaminskyho prezentaci projdou vasnivi obdivovatele DJB a zamysli se nad uzivanim DJBDNS...

Zatím se zdá, že rozhodnutí zůstat kvůli bezpečnosti bylo stále ještě správné…

[Milan Jurik]

Fakt? Takze djbdns uz ma DNSSEC? Navic djbdns ma do jiste miry s "Kaminsky utokem" take problemy, zda se. Doufam, ze jste si prosel vsechny prislusne vyzkumy a aplikoval sadu patchu (existuji vubec?) a zkontroloval konfiguraci.

Ano, Bind ma security chybu. Prizna se k ni a okamzite ji resi. Rozhodne lepsi nez se tvarit, ze problemy neexistuji.

[Filip Jirsák]

Takze djbdns uz ma DNSSEC?

Nemá. A pak taky ještě neumí loupat ořechy.

Navic djbdns ma do jiste miry s "Kaminsky utokem" take problemy, zda se

Ovšem ne větší, než jiné servery (tedy po aplikaci patchů na ty jiné servery, před aplikací měly ty jiné servery problém daleko větší). Ovšem jiné servery zdá se mají problém se vzdáleným DoS, se kterým djbdns problém nemá.

Ano, Bind ma security chybu. Prizna se k ni a okamzite ji resi. Rozhodne lepsi nez se tvarit, ze problemy neexistuji.

Ale co když problémy opravdu neexistují (resp. nejsou známy)? To je podle vás chyba? To jako má občas DJB do djbdns nějakou chybu udělat, aby ji pak mohl s velkou slávou zase opravit?

[Milan Jurik]

Nemá. A pak taky ještě neumí loupat ořechy.

Jakou vymluvu pouzijete, az infrastruktura bude rozumne funkcni a budou ostatni na tom docela dobre oproti djbdns?

Ano, djbdns byl velice slusny kus software slouzici jako DNS server (v mnoha smerech prekonavajici i stavajici konkurenci). V dobe sveho vzniku byl rozhodne unikatni. Jenze uz se nevyviji a zastarava.

Ovšem ne větší, než jiné servery (tedy po aplikaci patchů na ty jiné servery, před aplikací měly ty jiné servery problém daleko větší). Ovšem jiné servery zdá se mají problém se vzdáleným DoS, se kterým djbdns problém nemá.

http://www.your.org/dnscache/djbdns.pdf

ci

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-0858

Jsem si vedom reakci DJB na oba problemy. Jsem pak docela zvedav, co on mysli "These patches are an extremely poor substitute for proper cryptographic protection."

Ty "jine servery" k objevenym problemum pristupuji aktivne a snazi se resit jakekoliv problemy, dokonce i drobnosti.

Ale co když problémy opravdu neexistují (resp. nejsou známy)? To je podle vás chyba? To jako má občas DJB do djbdns nějakou chybu udělat, aby ji pak mohl s velkou slávou zase opravit?

Jenze on je udelal, aniz by chtel. Jsou to obcas velice obskurdni problemy na dobu, kdy dany software vznikal, jenze i IT svet se vyviji, svina jedna.

[Filip Jirsák]

Jakou vymluvu pouzijete, az infrastruktura bude rozumne funkcni a budou ostatni na tom docela dobre oproti djbdns?

Až budu chtít používat něco, co djbdns neumí, podívám se znova, jaké jsou možnosti, a posoudím, zda mi za tu vlastnost stojí nasazení serveru, který třeba zase neumí něco jiného nebo má sem tam problém s bezpečností.

Jenze on je udelal, aniz by chtel. Jsou to obcas velice obskurdni problemy na dobu, kdy dany software vznikal, jenze i IT svet se vyviji, svina jedna.

Ano, ale výše uvedené chyby jsou – alespoň co já jsem zaznamenal – poprvé skutečně nějaké chyby. V souvislosti s Kaminského útokem se hodně mluvilo o tom, že všichni upravují kód proti tomu útoku, a DJB nic, ale jaksi se zapomínalo dodat, že djbdns tu „opravu“ má už dávno. Že by po těch letech teď už opravdu došlo k okamžiku, kdy se síly vyrovnaly?

[Milan Jurik]

Že by po těch letech teď už opravdu došlo k okamžiku, kdy se síly vyrovnaly?

Jenze na to jsem tu narazel pred rokem a narazim neustale. DJB pristupuje ke kodu jako ke knize. On kod opravdu pise, my ostatni jej prgame. Jenze nove revize knizky roky nevydava a ty stavajici prestavaji byt aktualni a to dost prudce. Bohuzel nemalo jeho fanousku si tohle strasne spatne pripousti. Kdyz k tomu pricteme jeho postoj "Muj software je bez chyb, a kdyz uz tam najdete nejakou, tak to je obskurdni vec, tou se nezabyvam", tak to cely vysledek jeho prace proste kazi a ohrozuje jine.

Na druhou stranu, jeste stale jsou lide, co uzivaji BIND 4, ze

[Milan Jurik]

Kdyby ten .... neprilozil ten perl skript

[Foo Bar]

Tak by se nestalo vůbec nic... Schopní BlackHats by tu chybu zvládli objevit jen podle popisu a tak by snad zpomalilo ScriptKiddies. Navíc ta chyba je v podstatě nezajímavá, prostě ten bind jenom spadne na assert, tj. buffer overflow přes to pravděpodobně udělat nejde.

Hádám, že dotyčný reportující si možná ani neuvědomil, o jak závažný problém se jedná. Prostě experimentoval a přišel na to, že mu to padá, tak to nahlásil.

[Milan Jurik]

Take si myslim, ze on jen nedomyslel nasledky. Pokud by reportoval ale skrze security listy, nezvlcelo by to tolik a ja bych mel klidnejsi vcerejsi pracovni den