Lokální eskalace práv v Linuxu (CVE-2016-0728)

V Linuxu byla nalezena bezpečnostní chyba CVE-2016-0728 zneužitelná k lokální eskalaci práv. Chyba se dostala do linuxového jádra v roce 2012. Zranitelná jsou jádra od verze 3.8 [reddit].

19.1.2016 16:00 | Ladislav Hagara | Bezpečnostní upozornění

Komentáře

[Jardík]

Zkoušel jsem exploit, ale nějak se nemůžu dočkat toho výsledku. Už to běží hodinu a nic, asi to chcíplo někde ve smyčce "increfing".

[Michal Kubeček]

V závislosti na procesoru to může trvat klidně i přes hodinu. Ten prográmek je ale potřeba přizpůsobit konkrétnímu jádru; nejde jen o adresy těch dvou funkcí, ale třeba i struktura key_type se od verze do 3.8 do současnosti změnila nejméně dvakrát.

[jikos]

Plus je samozrejme potreba pouzit platnou adresu prepare_creds().

[Ladislav Hagara]

Ubuntu, Debian, Red Hat, ...

[xvasek]

Oldstable - not vulnerable. Zív. Nasazení Jessie je u mě zatím ve fázi usilovného zvažování.

[NN]

Vie sa aky trest postihne toho, kto je za danu chybu zodpovedny? V inych odvetviach ludskej cinnosti ja za taketo nieco minimalne drahy sud. No a v Cine, alebo v Severnej Korei...

[Jaroslav Kucera]

Pokud za tím stojí Čína nebo Severní Korea, tak je velmi pravděpodobné, že dotyčný tvůrce již svou odměnu dostal z fondů tajných služeb příslušných zemí.

To platí i o tajných službách jiných zemí

No a jinak by někdo musel prokázat úmysl. Jinak by do kernelu a opensource obecně asi nikdo dobrovolně nepřispíval, pokud by mu za náhodnou chybu hrozil nějaký trest. Navíc by jakýkoli patch měl procházet minimálně přes code review.

[NN]

No minimalne by som cakal, ze vsetok kod od daneho programatora, alebo firmy prejde co najskor dokladnou kontrolou.

[Michal Kubeček]

Co si takhle dát studenou sprchu a místo spřádání konspiračních teorií se podívat, kdo je ten autor? Hint:

mike@unicorn:~/work/git/kernel-upstream> git log --author dhowells --no-merges --oneline -- security/keys | wc -l
164
mike@unicorn:~/work/git/kernel-upstream> git log --no-merges --oneline -- security/keys | wc -l
313

Vy jste nikdy neudělal chybu? Na úsloví "kdo nic nedělá, nic nezkazí" je hodně pravdy.

[trekker.dk]

Vy jste nikdy neudělal chybu? Na úsloví "kdo nic nedělá, nic nezkazí" je hodně pravdy.

To je pravda. Na druhou stranu když někdo udělá chybu v jiných odvětvích, tak z toho jsou zpravidla vyvozeny důsledky - svolávací akce u aut, vyšetřování a - v případě závažných důsledků - obvinění atd. U software se většina chyb odmávne s tím, že to nebylo úmyslné (i kdyby bylo, tak to nedokážete) a že by to možná chtělo lepší revize.

[pavlix]

V lékařství se taky většina chyb odmávne s tím, že všichni udělali, co bylo v jejich silách, a to i v případě úmrtí nebo trvalých následků.

[chrono]

Keď sa budú dať skopírovať aj autá, tak to možno bude iné aj pri autách.

[Michal Kubeček]

Rozdíl mezi svolávací akcí u aut a vydáním updatu u software vidím jen v tom, že

• update software je výrazně pohodlnější, nemusíte s počítačem do servisu
• proto se update vydává i s opravami běžných chyb, zatímco u aut se svolává jen kvůli těm opravdu nejkritičtějším

[lertimir]

To je jen otázka řízení chyb. Samozřejmě by pravděpodobně bylo možné spravovat linuxové jádro režimem obdobným jako se spravuje bezpečnost a spolehlivost řídících systému jaderné elektrárny nebo třeba jak spravuje IBM své řady mainfraimových OS, ale pak je třeba zapomenout na širokou podporu HW a rychlý vývoj systému. Pro řízení chyb máš vždy nějakou základní chybovost (která v software je dána v podstatě práce) a pak procesy hledání a odstraňování chyb. A obvykle odstraňování má exponenciální závislosti. V nějakém úsilí dostaneš chybovost 99,99% a dostat se na 99,9999% dá třeba 20x větší úsilí. V linuxu na to nejsou prostředky, aby se současný poměr významně vylepšil. Už jsme se tu mnohokrát bavili u různých regresí a problémů o úprku těch, kteří implementují featury, před těmi, kteří hledají a odstraňují chyby. A nemyslím si, že se to může změnit, jedině když by ve vývoji bylo mnohem více peněz. Nevím jak kdo, ale pro mne číst cizí kód, kontrolovat ho, a hledat v něm chyby je mnohem otravnější, než vymýšlet a psát něco nového a nechal bych si za to platit o dost více.

[Jendа]

Pro řízení chyb máš vždy nějakou základní chybovost (která v software je dána v podstatě práce)

Ještě můžeš zkusit všechno formálně verifikovat. Ale s tím hodně štěstí, jestli se ti vývoj zpomalí jenom tisíckrát, tak to bude super výsledek.

Pro bezpečnostní chyby by ti teoreticky mohlo stačí verifikovat hypervizor/nejdůležitější kód mikrokernelu jako to dělá SeL4.

[xvasek]

Na to mám specializaci VŠ, pokud mi to někdo dobře zaplatí, budu to rád dělat, je to celkem zábavné. Jenom bych ze zkušenosti podotkl, že často je lepší změnit strukturu programu, aby produkovala mnohem jednodušší důkaz, ale zavádí to zbytečné instrukce a neefektivitu programu samotného. Jsou místa, kde se na tento aspekt dá kašlat - například u řízené střely bude prioritou spíš 100% správná funkčnost, než to, že interní procesor by teoreticky po vystřelení mohl být o 30% déle v "idle" stavu, čekat na vstupy a uspořit enerigii, ale Linuxové jádro je trochu trochu něco jiného.

Každopádně formální důkaz správnosti algoritmu - co já vím - pro výpočet faktriálu je práce na pár hodin, takže zásadně déle, než to trvá intuitivně napsat. Navíc v důkazu samotném mohou být chyby, resp. potenciální útočník může předložit důkaz, který je na první pohled korektní a teprve podrobnější analýza odhalí, že to vlastně není OK, takže jsme vlastně tam, kde jsme začali...

[pavlix]

Spíš než o důkazu pro faktoriál bychom se mohli pobavit o důkazu pro vícevláknový program se sdílenou pamětí.

[xvasek]

Proto píšu, že bych to napřed přepsal na něco jednoduššího a pak teprve dokazoval správnost.

[Jendа]

Hustý, nechceš o tom něco napsat?

[Radek Miček]

Každopádně formální důkaz správnosti algoritmu - co já vím - pro výpočet faktriálu je práce na pár hodin, takže zásadně déle, než to trvá intuitivně napsat.

Dost záleží na tom, v jakém jazyce ten program a ten důkaz píšete a také, co přesně dokazujete. Například vše můžete relativně snadno napsat v Coqu a pak vyextrahovat program v OCamlu. Nevýhodou ovšem je, že kompilátor OCamlu není formálně ověřený.

Navíc v důkazu samotném mohou být chyby, resp. potenciální útočník může předložit důkaz, který je na první pohled korektní a teprve podrobnější analýza odhalí

Tohle nechápu – čekal bych, že ověřit důkaz je trivialita (oproti vytvoření specifikace).

[lertimir]

Ale SeL4 je myslím v Haskelu a dokazovali to Isabellou. Netuším jestli je tento důkazní aparát aplikovatelný na jazyk jako C++.

[Jendа]

seL4 je v C. A nedokazují jenom že C odpovídá specifikaci, ale dokonce i že zkompilovaný kód odpovídá tomu C.

[trekker.dk]

V nějakém úsilí dostaneš chybovost 99,99% a dostat se na 99,9999% dá třeba 20x větší úsilí. V linuxu na to nejsou prostředky, aby se současný poměr významně vylepšil.

Ale jo, to chápu. Akorát mě zaráží, že u systému, který běží na velkém podílu serverů i smartphonů, jsou velcí hráči se současným poměrem spokojení. S podobnými chybami jde napáchat hromada škod a vsadil bych se, že se to ještě nestalo jenom proto, že ještě nikdo nechtěl. Vypůjčím si s prezentace o tom, jak hackovali Teslu S - já bych radši, kdyby nikdo nemohl. Samozřejmě nemluvím jenom o Linuxu, ale o software s velkým rozšířením obecně.

A moc bych za to nedal, že u služeb to bude podobné - co se občas člověk dozví, co nabízí velké firmy, co za to chtějí a jak to ve skutečnosti funguje (a někdy stačí jenom to poslední), to je dohromady k neuvěření, že celé tohle odvětví vůbec nějak funguje.

(Konec depresivního zamyšlení nad stavem věcí )

[deda.jabko]

Kdyby sis precetl licenci nebo se podival do zdrojaku urcite bys tam nasel nasledujici:

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY

[Jendа]

To bych byl strašně rád, kdybych někam dal zadarmo svobodný program, a když ho někdo použije a bude v něm chyba, tak mě budou soudit.

[Lol Phirae]

Že jo, tohle jsou super nápady, to by určitě hrozně pomohlo. #facepalm