Publikussá váltak a Pwn2Own-on bemutatott Linux helyi privesc sebezhetőség részletei

Titkosítás, biztonság, privát szféra

Publikussá váltak annak a privilégium-szint emelést lehetővé tevő, helyi Linux sebezhetőségnek a részletei, amelyet ChaitinTech mutatott be és használt ki a 2017-es Pwn2Own rendezvényen.

( Hunger | 2017. 03. 30., cs – 11:51 )

> user namespaces

újabb bizonyíték a kernel fejlesztők nemtörődömsége és érv a grsec használata, spender kompetenciája mellett

Anno, pár éve csináltam egy kis összefoglalót a konténerek biztonsági hiányosságairól,
szerintem már akkor is a user ns vezetett a hibák tekintetében...

itt van a dia róla: https://ibb.co/f4bKgF

(eddig még sosem akartam képet beágyazni, de nekem az img tag megadása nem működött)

Itt ugye ráadásul arról van szó, hogy a nem privilegizált felhasználók kezébe is oda adták azt a lehetőséget, hogy maguk hozhassanak létre ilyen saját user namespacet, amelyben azokat a kernel funkciókat is el lehet érni, amelyekre korábban a fejlesztők úgy hivatkoztak, hogy nem érdekes biztonsági szempontból, mert úgyis csak "root" érheti el (CAP_SYS_ADMIN). Most kinyitották a nagyvilág számára ezt a lehetőséget és ez hatalmas támadási felületet ad a kernelben. Bárki létrehozhat magának egy user namespacet, amelyben ő a root. Ezzel aztán alaposan kiterjesztették a lehetőségeket a kernelhibák kihasználásához.

Na ezt nem ertem pontosan, hogy hol szepit ez barmit. Egyszerusitsd a mondatot.
"This leads to the potential for privilege escalation."
Ez privilegium szint emeles lehetosegehez vezet.
Magyarul megteremti a lehetoseget arra. Ha mas lenne a szorend es jelzokent lenne hasznalva, akkor allna a taknyolas erzete.

Nem véletlenül írják így, ez a "potential" használat kevésbé célirányos és egyértelmű, mintha leírnák tisztán, hogy "proven exploitable vulnerability". Aki átfut csak a szövegen az kevésbé fogja érezni a súlyát.

Rendszeresen csinálják ezt. Aki olvassa a kernel commitokat folyamatosan az tudja miről beszélek. Ráadásul Linus is bevallotta már, hogy direkt ködösítenek a commit üzenetekben, úgyhogy felesleges a szerecsenmosdatás...

Ennyi erővel előfeltétel az CONFIG_XFRM_USER kernel konfig is és számos más tényező (pl. lokális kódfuttatásra való lehetőség)... Ha ez így működne, akkor mindenre csak "potential" hibaként lehetne hivatkozni, mert garantáltan lehet olyan konfigurációt találni, ahol a probléma nem kihasználható, vagy valamilyen módon mitigálható.

De ugye bizonyítottan létezik rá "practical" exploit, ezért a "potential" hivatkozás ilyen esetekben meglehetősen bárgyú.

Persze előfordulhat, hogy mindjárt jön majd valaki és megmondja a tutit, hogy: "Potential" is an ancient African word meaning 'you are totally pwned'... ;)

"Ha ez így működne, akkor mindenre csak "potential" hibaként lehetne hivatkozni, mert garantáltan lehet olyan konfigurációt találni, ahol a probléma nem kihasználható, vagy valamilyen módon mitigálható."h

Azért potenciális a vanilla kernel szempontjából, mert azt forrásban terjesztik és a forrásból végeredményként kapott lefordított kernel a lefordítás előtt elvégzett beállításoktól függően lesz érintett vagy nem.

Akkor lenne igazad, ha pl. egy bizonyos Ubuntu, Debian stb. kernelcsomagról lenne szó, amit már lefordítva terjesztenek. Annál meg lehetne egyértelműen mondani, hogy érintett-e vagy sem.

--
trey @ gépház

Ezért írtam, hogy ennyi erővel minden csak potenciális hiba. Kenjük el a dolgokat, mindig találni lehet kibúvót. Mondj egy garantáltan kihasználható hibát és én tutira mondani fogok rá megoldást, amikor mégse kihasználható és így ráragasztható a "potential" plecsni, mert mindig lesz kivétel.

Csak ez nem vezet sehova, csak maszatoláshoz. Persze marketingeseknek kiváló lehetőség...

Teljesen életszerű ez a megközelítés, hiszen egy Linux kernel forrását le lehet fordítani beágyazott rendszerre, vagy egy átlagos szerverre is.

A disztribútorok külön kernelt szállítanak ugyanabból a forrásból ARM rendszerekhez és mondjuk x86_64 rendszerre. Az viszont nem mindegy, hogy a disztribútornak _ugyanabból a forrásból_ készített ARM vagy x86_64 kernelcsomagra kell-e kiadnia figyelmeztetőt vagy sem. Könnyen előfordulhat, hogy az ARM rendszereket nem érinti az x86_64-et pedig igen vagy fordítva.

Szóval, hacsak egy hiba nem érint minden architektúrát és minden alap kernel beállítást, akkor potenciális.

Ha a kernel olyan részét érinti, ami minden architektúrán jelen van és mindig belefordul a kernelbe (nem modulban, hanem fixen vagyis nem kikapcsolható), akkor nem potenciális.

A gyakorlat egyébként ugyanez pl. a FreeBSD esetén is. Ha valami bizonyos beállítások mellett nem használható ki, akkor potenciális:

https://www.freebsd.org/security/advisories/FreeBSD-SA-17:01.openssh.asc

--
trey @ gépház

Te kis bolondos ember, ez nem micsilogic, hanem abban próbálok nektek tájékozódni, hogy mi az oka, hogy ezt írják _mások_.

Egyelőre még nem tartunk ott, hogy én mondjam meg nekik, hogy mit írjanak oda, bár, az előmenetelemet nézve egyszer talán erre is sor kerülhet.

--
trey @ gépház

> Szóval, hacsak egy hiba nem érint minden architektúrát és minden alap kernel beállítást, akkor potenciális.

hat nem. a potencialis a hiba kihasznalhatosagara vonatkozik, nem a jelenletere/triggerelhetosegere. ha pl. egy kernel egyaltalan nem tartalmazza a hibas kodot, akkor arra nem azt mondjuk hogy, potencialisan kihasznalhato, hanem azt, hogy nem kihasznalhato.