Bezpečnostní problémy v X.Org

X.Org upozorňuje na dva bezpečnostní problémy CVE-2011-4028 a CVE-2011-4029. Lokální uživatel je může zneužít k nastavení přístupových práv k libovolnému souboru nebo adresáři na 444, tj. čtení pro všechny. Může si tak přečíst například soubor /etc/shadow, konfigurační soubory obsahující citlivé informace nebo si vypsat obsah zakázaného adresáře. Problémy jsou řešeny v X.Org repozitáři jednořádkovými záplatami (CVE-2011-4028 a CVE-2011-4029). Nadace X.Org děkuje osobě jménem vladz za nalezení problémů a pomoc s testováním.

28.10.2011 14:58 | Ladislav Hagara | Bezpečnostní upozornění

Komentáře

[BFU]

Ono jde fakt vylistovat adresar, ktery ma jenom r-bit ? Zajimave, BFU se kazdy den dozvi neco noveho

[martin-ux]

no, asi ti vypadla ta hlavna cast tej spravy:

Lokální uživatel je může zneužít k nastavení přístupových práv

ak mas defaultne prava na shadow 444, tak ti asi unika pointa shadow

[BFU]

Ano, jsem BFU a proto nechapu ani jednoduchou ceskou vetu, takze je mozne, ze mas pravdu

Lokální uživatel je může zneužít k nastavení přístupových práv k libovolnému souboru nebo adresáři na 444, tj. čtení pro všechny. Může si tak přečíst například soubor /etc/shadow, konfigurační soubory obsahující citlivé informace nebo si vypsat obsah zakázaného adresáře.

[pingu]

no, hezky to řekla ta víla ve filmu o potterovi. "Pokud se musíš ptát, nic se nedozvíš, Pokud víš kde, stačí se zeptat." :p Jde o to, že některé cesty jsou známé (+- se stoprocentní jistotou úspěchu), nemusíš listovat adresáře, šaháš na jistotu.

[Michal Kubeček]

Víla???

[Michal Kubeček]

I tak je ale potřeba access na všechny adresáře v cestě od kořene k danému souboru. To ale samozřejmě nesnižuje vážnost té chyby, protože existuje souborů s citlivým obsahem, které jsou ve veřejně přístupných adresářích.

[Bubak]

/etc ale obvykle ma 755, jinak by asi dost veci prestalo fungovat. A treba /etc/ssh jakbysmet.

[Michal Kubeček]

Přečtěte si, prosím, ještě jednou druhou větu příspěvku, na který reagujete.

[martin-ux]

Nuz, i ked by som rad, s cestinou ti veru nepomozem. Ale slovencina a cestina je v tomto pripade rovnaka :)

Odkaz v sprave hovori, ze si mozes nastavit lubovolny subor na 444 (bez ohladu na jeho prava), tj, kazdy moze citat subor. No a ked mas na systeme /etc/super-tajne-hesla, ktore ma prava 600 a niekto ti ich nastavi na 444 .. tóž, to bude problem..

..security report som ale necital, takze neviem co presne moze/nemoze user urobit..

[Josef Kufner]

R ti na vylistování samozřejmě stačí. Sice si nepřeteš obsah toho, co vylistuješ, ale přečteš si, že to tam je.

[Michal Kubeček]

Je ale třeba dodat, že si nepřečte nejen obsah, ale ani metadata. Takže selže nejen 'ls -l', ale na většině distribucí i samotné 'ls' (kvůli zapnutému obarvování).

[David Watzke]

Já měl za to, že ls barví jen podle přípony.

[David Watzke]

Koukám na obsah /etc/DIR_COLORS a už chápu, že ne.

[Michal Kubeček]

Obecně je přístup k inodu potřeba už jen na rozlišení obyčejného souboru a adresáře. Třeba u ext{2..4} lze duplikovat informaci o typu souboru přímo v adresářové položce, ale obecně na to spoléhat nelze.

[Josef Kufner]

Dostaneš seznam souborů, ale nedozvíš se nic o nich, jen názvy:

$ mkdir a
$ touch a/b
$ touch a/c
$ chmod 444 a
$ ls -l a
ls: nelze přistoupit k a/c: Operace zamítnuta
ls: nelze přistoupit k a/b: Operace zamítnuta
celkem 0
-????????? ? ? ? ?            ? b
-????????? ? ? ? ?            ? c
$

[ewew]

Myslím, že problém je v tom že príkaz startx spúšťa commandline exec /usr/bin/X -nolisten tcp "$@".

Defaultne je binárny súbor v priečinku /usr/bin/X s právami 6755 alebo -rwsr-sr-x.

[zulu]

A tím jsi jako chtěl říct co? :)

[Michal Kubeček]

Něco takového jsem naposledy viděl ještě někdy v minulém století, kdy bylo zvykem startx používat. Dnes obvykle buď není grafické prostředí k dispozici vůbec (server) nebo se spouští prostřednictvím {x,k,g,w}dm. Tak či onak není důvod X serveru nastavovat SGID bit.

[petr_p]

Asi žiji v minulém století :) Tak či tak X server v Linuxu potřebuje přímý přístup ke grafické kartě, což se sice dá zařídit i bez SUID na /usr/bin/Xorg, ale ať se to udělá jakkoliv (vynecháme-li Xfb), tak efektivně musí mít taková práva, že si s nimi může šáhnout v paměti kamkoliv, tudíž možnost chmod(2) je opravdu ten poslední problém.

[Michal Kubeček]

Ne, to vůbec není ten poslední problém. Podstata tohoto problému je v tom, že i neprivilegovaný uživatel může zneužitím této chyby za jistých okolností zcela reálně měnit práva souborů, u kterých k tomu není oprávněn. To je aktuální a vážný bezpečnostní problém, který je potřeba řešit teď hned. Oproti tomu skutečnost, že X server potřebuje práva roota, aby se mohl přímo bavit s grafickou kartou, je sice koncepční problém, ale bez konkrétní chyby v kódu (jako je třeba ta, o které je tady řeč) je to jen potenciální problém, jehož řešení navíc není zdaleka záležitost jednoho jednořádkového patche.

Navíc to vůbec nesouvisí s komentářem, na který reagujete. V něm jsem kolegu pouze upozornil kolegu, že tvrzení, že X server má defaultně nastavený SUID bit, ani zdaleka neplatí obecně. A pokud to tak snad v nějaké distribuci stále ještě je, je to chyba příslušné distribuce.

[Michal Kubeček]

Oprava: "...nastavovat SUID bit..." (i když SGID taky ne).