Lokální eskalace práv v Linuxu (CVE-2017-6074)

Byly zveřejněny informace o bezpečnostní chybě CVE-2017-6074 v Linuxu zneužitelné k lokální eskalaci práv. Jde o chybu v podpoře DCCP (Datagram Congestion Control Protocol). Do linuxového jádra se dostala v říjnu 2005. V upstreamu byla opravena 17. února (commit). Bezpečnostní chyba byla nalezena pomocí nástroje syzkaller [Hacker News].

22.2.2017 17:28 | Ladislav Hagara | Bezpečnostní upozornění

Komentáře

[anon]

... allows local users to cause a denial of service

to moc nezní jako eskalace práv

[Michal Kubeček]

Je to use after free, takže při náhodné střelbě to typicky skončí nějakým page faultem. Ale při cílením útoku lokálního uživatele se to dá zneužít i k eskalaci práv.

[trekker.dk]

Zajímalo by mě, jestli se tohle DCCP a SCTP a podobné vůbec někdo odvažuje používat - co pár měsíců, to exploit.

[Michal Kubeček]

On to Andrej Konovalov v jednom z těch mailů píše:

Anyway, my bet was that DCCP is poorly tested and maintained and I decided to try fuzzing it specifically with syzkaller. I found a few bugs, one of them is an exploitable double free.

Pokud vím, DCCP se opravdu v praxi moc nepoužívá. SCTP někde ano, ale zaslechl jsem nějaké zmínky, že tam, kde se používá ve větším měřítku, často nepoužívají implementaci z linuxového jádra, ale nějakou jinou. Někde se ale určitě používá i ta linuxová implementace, protože už jsem na to měl nareportované nějaké bugy.

V případě téhle chyby je ale situace horší, protože ke zneužití lokálním uživatelem stačí to, že je modul nainstalovaný (naloaduje se automaticky, pokud někdo zkusí vytvořit DCCP socket).

[anonymni_tester]

U nas (Xura=ex-Acision), SCTP pouzivame hodne. V hlavnim produktu mame imho vlastni SCTP stack, v jednom testovacim toolu mame na vyber bud tu klasickou linuxovou nebo (opet zrejme vlastni? ale jinou) implementaci v user space.

[Peter Golis]

Práve som si pozrel posledné jadro vetvy 4.4, presnejšie 4.4.51 či má ten patch v sebe keď už vyšlo dňa 2017-02-23

no akosi

[Michal Kubeček]

Což není zase až tak překvapivé, pokud víte něco o tom, jak ten proces funguje. Jestli o to tak moc stojíte, ten patch se IIRC aplikuje naprosto hladce na cokoli přinejmenším od 3.0 (IIRC i na 2.6.32) a i na 2.6.16 byla potřeba minimální úprava, ke které není ani potřeba rozumět tomu kódu.

Pokud DCCP nepoužíváte - a to téměř jisté nepoužíváte - stačí ten modul smazat a je po problému (případně odloadovat, pokud by náhodou byl už naloadovaný).

[Peter Golis]

Áno, viem. Len ma prekvapuje že dochádza k zbytočnému oneskoreniu schválenia bezpečnostnej záplaty priamo v prípade vanilla jadra. Proste ma prekvapilo že vydali jadro bez už známej bezpečnostnej záplaty.

Na druhú stranu má tá chyba len čosi vyše 10 rokov. Nie je ani najmladšia, a ani najstaršia.

[Michal Kubeček]

Len ma prekvapuje že dochádza k zbytočnému oneskoreniu schválenia bezpečnostnej záplaty priamo v prípade vanilla jadra.

Tam k žádnému zpoždění nedošlo. Patch byl poslán do netdev listu 16.2., 19.2. už byl v mainline a téhož dne vyšla 4.10 i s ním. (Mimochodem, embargo na detailní informace o té chybě oficiálně skončilo až ve středu 22.2.)

Co se týká stable updatů, viz první větu mého minulého příspěvku. Proces přípravy a vydávání stable updatů není optimalizován na to, aby opravy vážnějších bezpečnostních chyb byly ve vydaném updatu v minimálním možném čase. Pokud chcete tohle, používejte distribuční jádro.

[Peter Golis]

Pokiaľ nie je proces prípravy a vydávania stabilných verzií jadra optimalizovaný na vydávanie bezpečnostných záplat v čo najkratšom možnom čase, tak tam je vsunuté plánované zdržanie. A to je zlé.

Ale ďakujem že si na to poukázal.

[Michal Kubeček]

Žádné "plánované zdržení", ten proces prostě funguje určitým způsobem a jeho cílem není (a nikdy nebylo) zaručit, že když dnes Greg vydal 4.4.51, že v něm budou všechny v tu chvíli známé security fixy (nebo i jen všechny od určité úrovně závažnosti).

[Peter Golis]

Je zaujímavé čítať vetu čo je tak dlhá, až si odporuje. Najprv zneguješ plánované zdržanie, potom ho definuješ a nakoniec potvrdíš.

Tak to je ešte smutnejšie.

[Michal Kubeček]

Tak ještě jeden zoufalý pokus. Proces vydávání stable updatů funguje svým víceméně pravidelným tempem a nebere ohled na to, že se v některé jeho fázi (v tomto případě den před vydáním) nějaká bezpečnostní chyba stala mediální hvězdou. (Občas vyjde mimořádný opravný update jen s jedním fixem, ale to se stává spíš v případech, že se bezprostředně po vydání updatu přijde na to, že přináší regresi, která je buď hodně kritická nebo se týká hodně uživatelů.) Pokud tomu chcete dál říkat "plánované zdržení", tak si to užijte, to je váš problém.

Nezbývá mi než zopakovat: pokud chcete mít kritické security fixy ASAP, nepoužívejte Gregova jádra, od toho jsou tady distribuce.

[Peter Golis]

Skús si zapamätať:

Na zmenu priorít podľa požiadaviek klienta slúži platená podpora.

Bez toho sa budeš stále zamotávať do protichodných informácií ktoré podávaš. Najmä ak zoberieme do úvahy že táto bezpečnostná chyba má vyše 10 rokov, vývojári o nej nejakú dobu vedeli, a informačné embargo bolo pochopiteľne až do vydania opravy. Čas od vydania opravy až do jej aplikácie je zdržaním. Plánovaným (kvôli pravidelnému testovaniu záplat ktoré trvá nejaký čas) alebo neplánovaným (keď má zodpovedná pracovná jednotka niečo iné a zároveň dôležitejšie na práci).

[Michal Kubeček]

Je to marné, vzdávám to. Říkejte si tomu jak chcete, to je váš problém, ne můj.

[Peter Golis]

Ja v tom ale problém nevidím.