Linux 2.6.30+ 0day helyi root exploit

Bug

A Grsecurity-ról ismert Brad Spengler (spender) a minap egy, a 2.6.30+ kernelekhez (és a 2.6.18-hoz is) használható helyi root exploit-ot postázott a DailyDave levlistára. Az exploit érdekessége, hogy egy olyan sebezhetőséget használ ki, amely forráskód szinten nézve kihasználhatatlannak látszik. Azonban a gcc optimalizációinak köszönhetően kihasználhatóvá válik.

Az exploit többféleképpen fordítható. 2.6.30-as kernelre fordítható úgy, hogy a cél rendszeren engedélyezve van a SELinux, illetve úgy is, hogy nincs. Illetve 2.6.18-as kernel és Red Hat Enterprise Linux 5 kombóra is fordíthatjuk.

A következő videó működés közben mutatja be az exploit-ot:

A bejelentés - benne link az exploit forrására - elolvasható itt. További részletek itt és az tgz-ben található exploit.c fájlban.

( suckit | 2009. 07. 17., p – 16:53 )

Jaj istenem, mind meghalunk!

Az igazán trükkös az lenne, ha egy fasza flash exploit is lenne a youtube-os videóban, és míg nézed, real time is zajlanának az események az ubuntun.

Szerencsére a Windowsomon tökéletes biztonságban vagyok, talán nem véletlen, hogy spender is arról nyomja. :)

suckIT szopás minden nap! SSD FreeBSD 7-tel és FreeBSD 8-cal

( uid_1526 | 2009. 07. 17., p – 16:53 )

(premature) optimization is the root of all evil

( funtom | 2009. 07. 17., p – 17:37 )

[...] egy, a 2.6.30+ kernelekhez [...]

$ uname -r
2.6.31-3-generic

$ ./cheddar_bay.sh
[+] Personality set to: PER_SVR4
E: bluetooth-util.c: Error from ListAdapters reply: org.freedesktop.DBus.Error.ServiceUnknown
UNABLE TO OPEN THE DEVICE!

Szerk: Szerintem az író itt nem erre gondolt... :)

( LGee | 2009. 07. 17., p – 17:29 )

Most varhatjuk, az anti-sec mikor defaceli a grsecurity-t ;-)

( skynetpro | 2009. 07. 17., p – 17:46 )

kell az ilyen, hogy a windows trollok is örüljenek néha (nem, mintha a jelenlévők nem etetnék őket eleget)

( gee v | 2009. 07. 17., p – 20:00 )

Csak egy dolgot hiányolok, mivel ugye ő és az RSBAC csapat a SELinuxot erősen lenézi, merthogy nem teljesértékűen véd, meg infot szivárogtat, meg nem tudom még miért.

Vajon grsecurity megfogja ezt az exploitot? (csak a videot néztem, nem olvastam utána)

G

> Csak egy dolgot hiányolok, mivel ugye ő és az RSBAC csapat a SELinuxot erősen lenézi, merthogy nem teljesértékűen véd, meg infot szivárogtat, meg nem tudom még miért.

SELinux-szal mas a problema, de ezt mar mashol sok helyen kifejtettuk ;).

> Vajon grsecurity megfogja ezt az exploitot? (csak a videot néztem, nem olvastam utána)

tekintve, hogy PaX igy grsec sincs 2.6.30-ra, ezert a kerdesnek nincs igy ertelme. de ha altalanosan kerdezed, akkor igen, a PaX-ban szamos feature (UDEREF/KERNEXEC) van, ami megfogna ezt is, mint ahogy sok mas ugyanebbe a kategoriaba tartozo hibara epulo exploitot is.

Igen, erre voltam kíváncsi.

Azt nem tudtam, hogy még nincs, de ha tudtam volna, akkor úgy hangzott volna a kérdés, hogy megfogná-e.

És akkor ezek szerint a PaX rész fogná meg.

Köszi.

Totálisan off: Azt tudom, hogy a Redhat egy saját megoldást tol erősen.
De más disztribúciókban vajon miért nem lehet grsec-et látni?

Legutoljára adamantixban láttam PaXot alapból, amíg élt, miután meghalt, hardened gentoot néztem, de az (nekem) gyakorlatilag használhatatlan volt (nem lehetett telepíteni, stb).

De látom, hogy pl. Debianban is SELinux van.

Szóval miért SE-t választanak a disztribúciók? Ez a kérdésem.

Hátha valaki tudja.
G

De más disztribúciókban vajon miért nem lehet grsec-et látni?

Lehet azért. Csak hogy mindjárt egy magyar disztribúciót említsek: a frugalware is ha jól tudom szállít grseces kernelt.

hardened gentoot néztem, de az (nekem) gyakorlatilag használhatatlan volt (nem lehetett telepíteni, stb)

"Dehisz egyetlen paranccsal telepíthető" :)

Jó, hát debian-ban is volt (van?) pl. kernel-patch-grsecurity

Csak éppen nem telepíthető, mert más verzióra van, mint a szállított kernel.

De én nem is erre gondoltam igazán, hogy utólag felteszem, és ha mondjuk minden jó, akkor majd beállítgatom magamnak, hanem ahogy jön a SELinux enabled kernel alapból, és a hozzá tartozó dolgok abban a kevés disztróban, amit ismerek, vajon van-e ilyen más disztrókban (tehát alapból jön)

És ha mondjuk a válasz nem (vagy legalábbis elterjedt disztrókban nem), akkor vajon miért van az, hogy a SELinuxot részesítik előnyben a csomagolóemberek?

Esetleg azért, mert az a kernel része, és nem kell peccselni, nem kell várni, míg az új vanilla kernelhez elkészül a patch, vagy van valami más oka?

G

amiert nincs grsec-kel megtamogatott distro, az tobb csillag egyuttallasa miatt van ;). az egyik amit te is emlitettel, hogy nem a vanilla kernel resze (aminek megint csak tobb oka van, mashol mar leirtuk). a masik, hogy egy MAC rendszer tamogatasa (most a PaX reszt hagyjuk ki, hiszen SELinux-szal hasonlitottad ossze) tobb-kevesebb extra munkat igenyel a userland-ben (valakinek ugye meg kell irnia es karban kell tartania a policy-ket). a distro-kat csinalo embereknek van epp eleg bajuk igy is, szoval ertheto, hogy minimalizalni akarjak az erre elfecserelt idot (hasonlo okokbol nem szeretnek sokfele virtualizaciot se tamogatni, lasd Red Hat meg Xen/KVM). a harmadik ok, hogy az SELinux mogott komoly kormanyzati/kereskedelmi hatszel van (az mas kerdes, hogy jo lora tesznek-e persze ;), nyilvan egy ceg se a sajat erdekeinek az ellensege.

Mindegyik fajta verzió fordításához ott az -fno-stack-protector. Mondjuk persze ez hiába védené ki, ha fordításkor ki lehet kapcsolni...

Üdv,
Dw.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

( bervi | 2009. 07. 17., p – 20:51 )

aranyos, ahogy "grsec-kel vajon menne-e"-vel meg "nincs itt semmi probléma"-val dobálóznak, ahelyett, hogy csinálnának valamit (nyilvánosan)

szerintem.

( Pontscho | 2009. 07. 17., p – 21:01 )

Kivancsi vagyok, h a PulseAudio local root sechole mikor lesz publikus. :)

---
pontscho / fresh!mindworkz

Sajnálatos, ha ez publikus volt egyéb körökben már régóta. Annak viszont örülök, hogy a széles körben publikussá válás után hamar reagáltak. Vannak proprietry gyártók, akik a széles körben publikussá válás + a vendor által kiadott javítás után is képesek fél évet elb.szni egy javítással egy _remote_ hibánál (OS X Java, rémlik?). Ilyen is van.

--
trey @ gépház

Sajnálatos, ha ez publikus volt egyéb körökben már régóta.

Az, h en tudtam rola az azt jelzi, h azok elott, akik ezeket uzemszeruen keresgelik ne adj isten kotyavetyelik mar sokkal regebben ismert volt.

hogy a széles körben publikussá válás után hamar reagáltak

Ez igy van, dicseretes dolog. Mondjuk egy local root exploitnal elvart dolog.

Vannak proprietry gyártók, akik a széles körben publikussá válás + a vendor által kiadott javítás után is képesek fél évet elb.szni egy javítással egy _remote_ hibánál (OS X Java, rémlik?). Ilyen is van

Erdekes ahogy mindig csopog nemi kisebbsegi erzes, ami miatt mindig azonnal ellentamadasba kell atmenni ha valami erzekenyen erint valakit... :)

---
pontscho / fresh!mindworkz

"Mondjuk egy local root exploitnal elvart dolog."

Olvastam egy tanulmányt valamikor, ami mintha arról értekezett volna, hogy egy ideje nem a local root exploit-ot a legveszélyesebbek és a legjobban keresettek, hanem a remote böngésző és hasonló dolgok. Ha jobban belegondolok, akkor valamennyire értem is a tanulmány mögött álló elképzelést.

"Erdekes ahogy mindig csopog nemi kisebbsegi erzes, ami miatt mindig azonnal ellentamadasba kell atmenni ha valami erzekenyen erint valakit... :)"

Nem, a támadás itt kezdődött, kaján vigyorral. Ez csak egy válasz volt arra.

--
trey @ gépház

Olvastam egy tanulmányt valamikor, ami mintha arról értekezett volna, hogy egy ideje nem a local root exploit-ot a legveszélyesebbek és a legjobban keresettek, hanem a remote böngésző és hasonló dolgok. Ha jobban belegondolok, akkor valamennyire értem is a tanulmány mögött álló elképzelést.

Akkor az illeto nem volt teljesen szazas. Pl. ha erdekelne a dolog, tudnek olyan exploitot osszebogaraszni ami bongeszo sebezhetosegen at tud localroot expolittal privilegiumot emelni es onnantol annyi. Mondjuk a cel donti el, adatlopashoz, spambothoz eleg a remote is.

kaján vigyorral

Nem volt kajan. :)

---
pontscho / fresh!mindworkz

Most így hirtelen átfutott az agyamon, hogy melyikből lehet több a világban, melyikből lehet nagyobb, bérbe adható botnet-et csinálni. Azzal, hogy megpróbálok összevadászni sok ezer olyan gépet, amin XY sebezhető portálmotor fut + xy sebezhető kernellel, vagy xy verziójú sebezhető böngészőt futtató desktop usert kell rávennem arra, hogy "Hé, Britney Spears meztelen, ide süss!!!".

Egyébként botnet építéséhez már az első eset is jó, lenne és teljesen felesleges lenne a root exploit.

Hát ezért tolódik el állítólag egyre inkább a sebezhetőségek értéke a local exploit-okról a széles körben kihasználható szolgáltatások és programok hibáit kihasználó remote exploit-ok felé.

Sokkal kisebb energiával kihasználhatók, sokkal nagyobb a sebezhető bázis, ebből adódóan rövid idő alatt nagy hálózat építhető.

--
trey @ gépház

Egyébként botnet építéséhez már az első eset is jó, lenne és teljesen felesleges lenne a root exploit

Ez erősen rendszer/infrastruktúra/konfiguráció függő. Normális helyen nem kapcsolódhat kifele agyba-főbe mindenhova a portálmotort futtató webszerver sem, ahogy otthoni desktop téren is egyre gyakoribbak az olyan jellegű tűzfalak használata, amely korlátozza a kifele irányuló kapcsolatokat (céges szinten meg pláne).

"mindenhova a portálmotort futtató webszerver sem"

Valóban, de nem biztos, hogy ezt a korlátozást a helyi gépen root felhasználó megszerzésével fel tudod oldani. Mi van ha van előtte korlátozó tűzfal? A legtöbb esetben van.

Amíg elegendően nagy számú lamer otthoni felhasználó van, aki rendszergazdaként használja a gépét (és elegendően nagy számú van) mindenféle egyéb védelem nélkül, addig valószínűleg a kisebb ellenállás felé fognak elmozdulni, mert az az olcsóbb.

--
trey @ gépház

Azért a 2 valahol összefügg ám..
Azt a verziót pont kihagytad, hogy egy hibás portálmotoron keresztül injektelnek kódot a portálba, amit aztán a sok okoska látogató le is futtat.. Tekintve, hogy a weboldalakat könyebb megtalálni, és detektálni a hibáit, így nem vagyok benne biztos, hogy a weboldalak olyan kis prioritással rendelkeznének ilyen téren..
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Ez a támadás céljától függ.
Ha egy mezei botnet-et akar felépíteni valaki, akkor könnyebb a stupid usereket betámadni.
Egy célzott támadás esetén, viszont a portálmotor/CMS lesz az elsődleges célpont. Egy árnyékhálózat kiépítésekor szükség lehet magas rendelkezésre állású, nagy sebességű adatkapcsolatra. Ezt egy stupd user nem biztos, hogy biztosítani tudja.
A másik eshetőség, amikor egy adott céllal (károkozás, adatlopás, számlafejés) törik a rendszert. Ilyenkor az első körös tapogatózás (portscan, OS/service fingerprinting) után jól jöhet ha ismert sebezhetőség kombót találnak. Ez utóbbi esetben, nem csak a kernel local exploitok jöhetnek szóba, hanem az adott gépen futó összes szolgáltatásé.

A botnetek, a rendszer törések egy kicsi, de jól jövedelmező hányada. Rengeteg egyéb olyan indok lehet ami miatt egy adott rendszert nekiállnak törni.

--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Ez alatt nem az anyagi, vagy darabszámát értettem, hanem mint célt.
A botnet hálózatok a méretük és a végfelhasználók érintettsége miatt vannak benn a köztudatban. A többiről általában igen nagy hallgatás van, mert szolgáltatók, állami, egyetemi, katonai hálózatok a célpontjaik és az ilyeneket nem szeretik nagydobra verni.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Nem volt ilyen állítás. Bár az nyilvánvalóan csökkenti egy exploit piaci értékét az (is), ha nem egy széles körben használt szolgáltatásban, programcsomagban, komponensben található sebezhetőséget használ ki, hanem valami specifikus dolgot, ami esetleg nincs jelen minden egyes gépen egységesen (ugyazon sebezhető verzióban), alapértelmezetten, stb.

--
trey @ gépház

( Huncraft v | 2009. 07. 17., p – 21:34 )

Na azért vannak itt még érdekes dolgok ám :)

"Bypassing the null ptr dereference protection in the mainline kernel
via two methods ->
if SELinux is enabled, it allows pulseaudio to map at 0
UPDATE: not just that, SELinux lets any user in unconfined_t map at
0, overriding the mmap_min_addr restriction! pulseaudio is not
needed at all! Having SELinux enabled actually *WEAKENS* system
security for these kinds of exploits!"

____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

( vomberg | 2009. 07. 18., szo – 15:41 )

Na most azért nézzük már meg ezt a kódot, mert nekem nem áll össze az egész...

struct sock *sk = tun->sk; // initialize sk with tun->sk
…
if (!tun)
return POLLERR; // if tun is NULL return error

Magyarul itt a kóder egy slampos disznó, mert vagy legális az, hogy a tun == 0 és akkor milyen alapon dobná vissza hibával később, vagy illegális de akkor hogy merészel értéket adni a tun alapján a vizsgálat előtt?

Az optimalizáló "hibáját" nem tartom annak, mert logikus amit csinál, csak ugye arra bazírozták az optimalizáló kóderei a dolgot, hogyha valaki használ egy pointert akkor azt előtte ellenőrzi, hogy érvényes-e. Az pedig, hogy a 0 az egyszerre jelzi az érvénytelent ám lehet oda mmap-olni, hát mit mondjak... a 0 értéket a pointernél azonnal kell ellenőrizni és nem pedig a felhasználás után.