CVE-2008-5029 / kritická chyba všech linuxových jader

12.11.2008 02:37 | Přečteno: 2612× | GNU/Linux | | poslední úprava: 12.11.2008 03:01

V zprávičce k linuxovému jádru 2.6.27.5 je "velmi důrazně doporučován přechod na nové jádro". V zprávičce k linuxovým jádrům 2.6.26.8 a 2.6.25.20 se také "důrazně doporučuje update". Chybí už jenom zprávička k jádrům 2.4.36.9 a 2.4.37-rc2 také s důrazným doporučením aktualizace. Správci, kteří dosud neposlechli důrazná varování mohou mít vážné problémy (CVE-2008-5029). Byl zveřejněn exploit, jenž může být k útoku zneužit.

Běžný lokální uživatel může jejich systémy zcela zablokovat (Local Denial of Service). Všechna linuxová jádra mají/měla vážný problém s funkcí __scm_destroy() nacházející se v souboru net/core/scm.c.

Mail s požadavkem na CVE číslo.
Historie řešení problému z Red Hat Bugzilla: Bug 470201 CVE-2008-5029 kernel: Unix sockets kernel panic
Changelog linuxového jádra 2.4.36.9.

Problém byl nalezen skupinou #darkircop.
Bugtraq ID: 32154
       

Komentáře

[marek_hb]

já si říkal co za tím bylo

[Petr Tomeš]

Ty zprávičky jsou takové divné, jako by se zbořil svět pro ty, kdo používají starší verze jader. O ty se už distributoři nebudou starat nebo proč je doporučován přechod na novou řadu a ne jen aktualizace?

[Nicky726]

Jak psal Greg KH, neměly by už vyjít novější verze řad 25 a 26, než ty z 10.11. U řady 25, která je s námi už celkem dlouho, je to ok, u řady 26 se to může zdát poněkud ukvapené.

Na druhou stranu je pochopitelné, že vývojáři chtějí, aby se používalo nejnovější jádro.

[Heron]

Na druhou stranu je pochopitelné, že vývojáři chtějí, aby se používalo nejnovější jádro.

Vývojáři možná. Já jako admin chci, aby se s updatem (nejen) jádra nezměnilo ideálně vůbec nic (tedy pouze oprava chyb). Což je též důvod proč Red Hat pro RHEL5 udržuje kernel 2.6.18.

[Petr Tomeš]

A v CentOS 4 / RHEL 4 je jádro 2.6.9 a pochybuju o tom, že by nemělo být dobře zabezepčené, jak může vyplývat z Ondřejových výroků a urputné snahy vytvořit iluzi, že jedině používání dvou tří nejnovějších řad jádra je z hlediska bezpečnosti správné. Naopak je to postavené na hlavu.

[Kverulant]

To neni mozne, a OpenBSD to zase nepostihlo

[trekker.dk]

No jo, holt tam asi máte něco špatně...

[Bedňa]

To je postihnuté samo o sebe

[al-Quaknaa]

A co moje 2.6.21 na serveru? Té se to týká taky?

[Ladislav Hagara]

"Všech" znamená také 2.6.21.

[Petr Tomeš]

Vaše distribuce nemá něco jako monitoring bezpečnostních problémů a (správce) aktualizací? Tohle jsem nikdy nepochopil, proč je pro tyto lidi abc primárním zdrojem takových informací. Podle mně je to špatně.

[otasomil]

A co se muze vlastne stat ? Polopaticky pro radove smrtelniky ?
Nepredpokladam ze treba vybuchne monitor jako Kureti v policejni akademii kdyz osadil cip P6.
Uz pomerne dlouho obhajuji systemy "read only" ktere resi v podstate vsechny problemy s operacnimi systemy a to bez ohledu na platformu.
Nejaky kod ktery se nejakym neznamym zpusobem dostane do systemu a je jim interpretovan za ucelem zpusobeni skody, obtezovani uzivatele apod ?
Jen jedno tlacitko resi vsechny problemy radovych uzivatelu PC = Reset a nasledne nabootovani do puvodniho nezmeneneho OS.
Jak jednoduche.

[Ladislav Hagara]

Spuštěním exploitu systém totálně zamrzne, nereaguje vůbec na nic. Jedinou možností je jeho vypnutí a zapnutí. U počítačů řadových smrtelníků to není problém. U systémů, které mají běžet v režimu 24/7 docela průšvih. Libovolný z uživatelů může spustit exploit a systém na několik minut nebo i hodin (pokud se to nezjistí okamžitě, pokud je systém několik kilometrů vzdálen a nikdo u něj nesedí, ...) vyřadit z provozu.

[default]

Spuštěním exploitu systém totálně zamrzne, nereaguje vůbec na nic. Jedinou možností je jeho vypnutí a zapnutí.

Takže něco jako kolerovaný SELECT statement v UPDATE statementu spuštěný pod MySQL 3 (nebo 4, pamatuji si jen ten výjezd do serverovny)?

[Grunt]

Ale fujtajcl, bazmek jeden hnusný. Ještě, že se nestačil syncnout na disk než jsem ho spustil, protože už ho nechci ani vidět.