GHOST, kritická zranitelnost v glibc

V knihovně glibc byla nalezena kritická zranitelnost CVE-2015-0235, jež dostala jméno GHOST. Jedná se o přetečení zásobníku ve funkci __nss_hostname_digits_dots(). Útočník může v nejhorším případě vzdáleně spustit libovolný kód. [CSIRT.CZ]

27.1.2015 23:23 | Ladislav Hagara | Bezpečnostní upozornění

Komentáře

[rastos]

http://www.openwall.com/lists/oss-security/2015/01/27/9

- A patch already exists (since May 21, 2013), and has been applied and tested since glibc-2.18, released on August 12, 2013:

[Jan Trávníček]

Opensuse 13.2 glibc 2.19-16.2.5 testováno prográmkem v odkazu s výsledkem "not vulnerable".

[Michal Kubeček]

Takových ještě bude… Zdrojáky resolveru v glibc by se měly ukazovat při výuce programování - jako odstrašující příklad.

[pavlix]

Obávám se, že je to příliš těžký kalibr.

[Ivan]

Ted si trochu zatrolim - prominte. Kolik lidi se doopravdy hrabe ve zdrojacich glibc? Kdykoliv se objevi nejaky problem s glibc, tak se mi jako prvni vybavi neskutecna arogance jeho spravce.

[pavlix]

Kolik lidi se doopravdy hrabe ve zdrojacich glibc?

Docela dost, jenže tady je řeč o jejich zcela konkrétní části, ve které se nehrabe skoro nikdo a na netriviální patche nikdo v praxi nereaguje. Sám jsem se v tom začal hrabat vcelku nedávno, ale už jsem si stihl napsat vlastní implementaci, abych mohl ty věci pořádně otestovat a pak se teprve o tom bavit s nimi, jenže se zatím zdá, že není s kým ;).

tak se mi jako prvni vybavi neskutecna arogance jeho spravce.

Kterého že?

[Sixkill]

Kterého že?

Ulrich Drepper?

[kralyk z abclinuxu]

Kterého že?

Nejspíš myslí toho-jehož-jméno-nesmíme-vyslovit, kterej už tam 3 roky není...

[Michal Kubeček]

Kolik lidi se doopravdy hrabe ve zdrojacich glibc?

Možná to nebylo zřejmé, ale psal jsem to na základě osobní zkušenosti.

neskutecna arogance jeho spravce

Už nějakou dobu to není one man show, právo commitovat má víc lidí. Jak moc se situace zlepšila, to si netroufám posoudit; moje zkušenost nebyla úplně nejlepší, ale sebekriticky přiznávám, že z nezanedbatelné části i mou vinou.

[Hans1024]

Z nejakeho duvodu je soucasti reslolveru jeste dedictvi z BSD . Pritom jine casti glibc (vrtal sem se ze zvedavosti treba v mallocu) mi pripadaji celkem v pohode.

[pavlix]

Tak on je v podstatě celý DNS resolver vykopírovaný z bindu. Jestli tomu chceš říkat dědictví z BSD, budiž.

[Hans1024]

Vzdyt bind je dedictvi z BSD, ne?

[pavlix]

Taky jsem psal budiž :).

[Lol Phirae]

tak se mi jako prvni vybavi neskutecna arogance jeho spravce.

UDa už před několika lety vyhodili. Nicméně pravda že, že dojebaný resolver je zcela jeho práce a kvalita jeho komunikačních schopností se vyrovnala legendárnímu "správci" RPM (taktéž s mnohaletým neomluvitelným zpožděním odejitému od Červených kloboučníků...)

[Šangala]

CentOS 6 => vulnerable
yum update
CentOS 6 => not vulnerable

Update: 2.12-1.149.el6_6.5 z ≈2015-01-27

[pavel]

optimisto ;)

[Jendа]

Tím vulnerable určitě myslel tuhle jednu díru. Že tam má sto dalších je snad každému jasné.

[Šangala]

To je výstup jednoduchého testu, který je součástí popisu této konrétní zranitelnosti.

[Jendа]

18. 1. 2015 15:32: Přes co lze vyownovat tvůj systém dnes se dozvíš za týden na libovolném security listu.

Já vám nechci podsouvat žádné konspirační teorie, ale…

[Heron]

Mno a jakže vyownuješ můj systém pomocí tohodle?

Na rootu vyšel článek o tom, že rok 2014 byl rokem děsivých bezpečnostních chyb. Já to vidím spíše jako rok zveličování. Objevilo se pár celkem běžných chyb a stejně jako ostatní prostě byly opraveny. Tohle je jedna z nich. Nic víc.

[Michal Kubeček]

Já bych řekl hlavně rokem, kdy se bezpečnostním chybám začala dávat zajímavá jména a zakládat domény druhé úrovně.

[brm]

Je nutne restartovat po update glibc (centos 6) ?

[Jendа]

Na Debianu se dpkg zeptá a alespoň síťové démony restartuje. Ale glibc používá skoro všechno, takže to možná bude nejjednodušší.

[Šangala]

Otočit (bránu a DNS server jsem hned otočil…) - je to to nejsnazší.

[David Watzke]

Aby se to načetlo všude, tak jo. Jinak se stačí zamyslet nad tím, které služby lze ovlivňovat zvenčí a restartovat je (zejména bych otočil mailserver, sshd, http server a pak je zpravidla bezpečný otočit crond, atd, ntpd, pač to ničemu nevadí). Ne všude si člověk může restart dovolit.

[Jakub Lucký]

Na Debianu je v debian-goodies script checkrestart, ktery detekuje, jake procesy pouzivaji stare verze knihoven a maji se restartovat. Asi to není foolproof, ale vesměs to stačí...

[Michal Kubeček]

To umí třeba i "zypper ps", ale tady jde spíš o to, že v případě updatu glibc nejde ani tak o to, které běžící procesy používají starou verzi knihovny (to budou víceméně všechny kromě nově spuštěných), ale o to, které je nutné restartovat proto, že jsou zranitelné.

[Jakub Lucký]

A to není stejná množina? (Netrolluju, vážně si to tak myslím, ale zase tomu nerozumím natolik, abych nepodlehl protiargumenům)

[Michal Kubeček]

V tomto konkrétním případě je problém jen s těmi procesy, které může útočník donutit, aby zavolaly gethostbyname() nebo gethostbyname2(). Což znamená, že jednak musejí ty funkce vůbec někdy volat (spousta programů vůbec nepotřebuje resolvovat jména, jiné používají getaddrinfo(), která AFAIK tímto problémem ohrožená není), jednak musí být útočník schopen přimět program, aby ten lookup provedl (takže třeba u serveru bez lokálních uživatelů nás víceméně zajímají jen programy komunikující po síti - ani ty ne všechny).