Linux 2.6.30+ 0day helyi root exploit

 ( trey | 2009. július 17., péntek - 16:39 )

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.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

hehe, durva

Mindenesetre megvan a szepsege annak, hogy a compiler optimalizacioja "helyezi el" a hibat az egyebkent korrekt kodban :)

Szerencsére az OpenBSD a pcc-vel jó lóra tett. :)


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

Abban biztosan sosem lesz hiba, mert tökéletesen biztonságos...

"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."

jah, mert az nem csinal ilyen optimalizaciokat :)

--
When in doubt, use brute force.

Attól még biztonságos.

nem is értem, hogy a P4i7-esek korában miért kell még mindig optimalizálni...

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

Mondjuk hogy nyerjenek igy is olyan atlag 5-20%-nyi teljesitmenyt? Sot, az SIMD utasitaskeszlet automatikus alkalmazasa sem igazan megoldott kerdes, tehat ha valaki ezeket ohajtja hasznalni akkor meg assembly-ben is tudnia kell programozni!!!!!111

---
pontscho / fresh!mindworkz

Ennél már csak a compiler level backdoor injection a szebb. Ez minden egyes forgatásnál hozzáad egy cuki kias hátsó bejáratot az alkalmazáshoz.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

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

ezért szál el a firefox 3.5.1 amikor teljes képernyőre akarom tenni az az flv vackot?

Igen és a fekete helikopterek is ezért köröznek a ház felett.

--
trey @ gépház

A multkor egy lyukat vagtak kommandosok a szomszed haz tetejen, es elvittek a ferfit... azota senki nem hozza at a leveleim, amit "veletlenul"(?) mindig oda dobott be a postas!
/Brazil Flash/

nem az ufo-k voltak?

(premature) optimization is the root of all evil

[...] 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... :)

A sebezhetőség a /dev/net/tun-ban van. Van neked egyáltalán ilyen (lsd: UNABLE TO OPEN THE DEVICE!)?

--
trey @ gépház

$ grep -c "^tun " /proc/modules

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

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

azt vagod, hogy putty-n keresztul mutatja be az exploitot? ;)

--
When in doubt, use brute force.

Az lenne a poen, ha netbsd -n mutatna be ? :)


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

compiz!

beindult a "gleipnir" project?
___
info

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ő" :)

> a frugalware is ha jól tudom szállít grseces kernelt.

Szallitott...

"...What happened to the kernel-grsec package? :( ... It got removed because we no longer provide custom patchsets as binary packages..."

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

"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"

Ez azért egy elég nyomós érv. :)

Nyilván az is, hogy a kernel része, meg az is, hogy az SELinux mellett nagyban megy a propaganda gépezet RedHat/NSA és a többi SELinux vendor részéről (diagram hegyek, hogy hogyan védi az alkalmazásokat és a kernelt... Nem véletlenül figurázta ki spender :)

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.

Sajnálattal hallom.

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."

elgondolkodtatóak a kommentek a kódban. tényleg ilyen sunyik ezek a linux fejlesztők?

--
joco voltam szevasz

nezz egy git-et ;)
___
info

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.

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

---
pontscho / fresh!mindworkz

parancsolj
Ha érdekel a dolog háttere is akkor meg itt olvass utána
____________________________________
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!"..

Melyikre gondolsz? Amelyet a disztrók már tegnap ki is javítottak?

http://lwn.net/Articles/341862/

--
trey @ gépház

disztrók == ubuntu ?
___
info

És a Mandriva ma:

http://lwn.net/Articles/341865/

--
trey @ gépház

igy mar okes
___
info

És a Gentoo tegnap:

http://www.gentoo.org/security/en/glsa/glsa-200907-13.xml

Tovább nem keresem. Akit érdekel keressen.

--
trey @ gépház

Amelyet a disztrók már tegnap ki is javítottak?

hűdegyorsak!

Nyilvánvalóan itt nem az volt a cél, hogy elmondjam, hogy hű, de gyorsak, hanem az, hogy ez már régen publikus.

--
trey @ gépház

2 napja. Persze nyilván attól függ, hogy hogyan definiáljuk a "publikus" fogalmat, mert lehet, hogy van, aki szerint több, mint 2 hete, de javítva max. csak 2 napja van a disztrokban... :)

Mit szeretnél mondani? Bekérdezte, mert azt hitte, hogy nem az. Ráfaragott, mert már nem hogy publikus, de még javították is. Mellényúlt, ezen most mit kell magyarázkodni?

--
trey @ gépház

Nem is arra reagáltam, hanem a te válaszodra. HTH

Erre. A szepsege csak az, h tobb hete, ha nem honapja (nem remlik pontosan mikor talalkoztam eloszor vele) ismert volt mar "egyeb" korokben, a tobbiben meg kitudja. :)

---
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

+1
Sőt még böngésző sem kell.
Elég egy távoli kódfuttatási hiba az adott gépen üzemelő szerveren (pl. bugos fórum, vagy CMS egy webszervren) és máris remote hole lett a localbol.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

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!"..

Természetesen ilyen is van. Ehhez azonban nem kell feltétlen local root exploit. Néha elég az is, hogy az illető Total Commander-t használ és elvégzi a munkát a támadó helyett :)

--
trey @ gépház

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. "

"A botnetek, a rendszer törések egy kicsi, de jól jövedelmező hányada."

Erre nézve valami adat jól jönne. Tekintve csak a nagyobb botnetek méretét ez elég vad állításnak hangzik.

--
trey @ gépház

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. "

+virtualuser
-shell

Volt már erről szó 100-szor, de azért újra. Érzékeny adatok ellopásához nem kell root/rendszergazda jog (hisz az user profiljában van minden), sem ahhoz, hogy a géppel valami olyasmit csinálj, ami miatt fel szokták törni (spammelés).

--
trey @ gépház

Tehát végülis nem is olyan nagy dolog ez a local root exploit.

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

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!"..

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.

Idézet:
This code looks perfectly ok, right?

No ide lehet egy kajan vigyort biggyeszteni! ;) Egyetertek, a koder egy slampos diszno. Erdekes mi lesz a slampossagbol, ha optimalizaljuk :)

A c nyelvvel ismerkedőnek egyik első dolga hogy az ilyen hibalehetőséget megtanulja tisztességesen kezelni. Ha ezt megszokja akkor legalább az ilyen slendriánság miatt nem kell hibát keresnie a kódban. (Ez persze minden olyan nyelvre igaz ami ismeri a mutató tipust.)

ki mondta, hogy figyelmetlensegbol kerult bele? ;)

--
When in doubt, use brute force.

No igen... Én olyan személyre gondoltam aki nem ártó szándékú. :-/

Szerintem felreertetted. Vagy ha te nem, akkor en igen ;)