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):
- A $ORIGIN a futtatható állományt tartalmazó könyvtár nevét tartalmazza.
- 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
- 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!
