Tweets by @buherablog
profile for buherator at IT Security Stack Exchange, Q&A for IT security professionals

A BitBetyár Blog

Túljártál a nagyokosok eszén? Küldd be a mutatványodat! (e-mail a buherator gmailkomra jöhet)

Full-Disclosure / Névjegy / Coming out


Promó

H.A.C.K.

Címkék

0day (110) adobe (87) adobe reader (21) anonymous (26) apple (60) az olvasó ír (49) blackhat (20) botnet (22) bug (200) buherablog (44) buhera sörözés (39) bukta (49) deface (38) dns (22) dos (29) esemény (82) facebook (26) firefox (64) flash (33) gondolat (31) google (59) google chrome (36) hacktivity (37) hírek (117) incidens (224) internet explorer (88) iphone (35) java (50) jog (22) kína (21) kriptográfia (68) kultúra (21) linux (24) malware (43) microsoft (142) móka (48) mozilla (23) office (26) oracle (40) os x (43) patch (197) php (20) politika (31) privacy (58) programozás (22) safari (34) sql injection (62) windows (85) xss (77) Címkefelhő

Licensz

Creative Commons Licenc

Bitvadászat - "Cry For Help" edition

2010.10.27. 21:53 | buherator | Szólj hozzá!

Nagyon hálás lennék, ha valaki kommentben vagy e-mailben mindenki okulására kifejtené a glibc legújabb sebezhetőségének hátterét, különös tekintettel az exploitnál alkalmazott file-descriptoros trükkre vonatkozóan. Én eddig háromszor futottam neki, de beletört a bicskám... :(

Frissítés:

Beszélgettünk GHosttal a problémáról és úgy tűnik, hogy a megoldás egyszerűbb, mint vártam (ettől függetlenül az eredeti leírás alapos áttanulmányozása erősen ajánlott): 

  1. A $ORIGIN a futtatható állományt tartalmazó könyvtár nevét tartalmazza.
  2. Az LD_AUDIT-ban a betöltendő shared library-k (direkt az angol változatot használom, hogy ne legyen kavarodás...) listáját tartalmazhatja
  3. A $ORIGIN DSO csak akkor kerül kibontásra, ha ő szerepel egyedül és elsőként az LD_AUDIT-ban. (glibc forrást tanulmányozni öröm és boldogság...)

Ugyebár az ELF specifikáció azt ajánlja, hogy ne hagyjuk kibontani $ORIGIN-ben tárolt útvonalat SUID állományok esetén, mert egy sima user a saját könyvtárából rálinkelhet egy ilyen fájlra, a saját könyvtárába meg berakahatja a saját gonosz libjeit, amik a set-UID-os binárisokba fognak betöltődni. 

Jelen esetben a dolog bonyolultabb a 3-as pont miatt, mivel nem mondhatom azt, hogy LD_AUDIT="$ORIGIN/evil", mert az is_dst() elkaszál.

A sejtés az, hogy a fájlleíró létrehozásakor a $ORIGIN értéke már kiszámítódik: /tmp/exploit lesz. Az exploit könyvtár törlésekor, majd ennek a helyén a payload létrehozásakor a fájlleíró változatlanul (a hozott jogosultságokkal együtt) megmarad, tehát amikor megpróbáljuk lefuttatni az általa mutatott állományt a $ORIGIN által hivatkozott könyvtár helyén egy shared library lesz. A loader az LD_AUDIT-ban megadott "$ORIGIN" kifejezést (mivel megfelel a 3. pontnak) ki fogja bontani, és a kibontott érték egy dlopen() számára értelmes függvénykönyvtár lesz, aminek a konstruktora le is fut.

A fentiek részben feltételezések, várom a konstruktív kritikát!

Címkék: bug glibc bitvadászat

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

Nincsenek hozzászólások.