do_mremap() exploit failed /Linux hack gyakorlat 2. resz :))

Fórumok

do_mremap() exploit failed /Linux hack gyakorlat 2. resz :))

Hozzászólások

A két proof of concept exploit (az egyik Christophe Devine és Julien Tinnes munkája, a másik Angelo Dell'Aera átirata) után megjelent az igazi shellcode exploit is, köszönhetően az iSEC csapatnak.

A do_brk() exploit fórumon lévő tanakodás után már okosan -static opcióval fordítottam az exploitot, ami talán működik is, de baromi sokáig tart kivárni és rendkívül nagy loadot okoz...

[code:1:18a64e1fb2]hunger@xxxxxxx:~$ uname -a
Linux xxxxxxx 2.4.22 #4 Fri Oct 31 12:20:22 CET 2003 i686 unknown
hunger@xxxxxxx:~$ ./mremap-static

[+] Please wait...HEAVY SYSTEM LOAD!
15273 of 1114129 [ 1 % ETA 16548.0 s ][/code:1:18a64e1fb2]

Az új kerneleknél már végtelen ciklusba megy át a dolog...

[code:1:18a64e1fb2]hunger@mail:~$ uname -a
Linux mail 2.4.24-grsec #2 SMP Wed Jan 7 12:09:42 CET 2004 i686 unknown
hunger@mail:~$ ./mremap-static

[-] ERROR remapping
remap1: Invalid argument

entering endless loop[/code:1:18a64e1fb2]

És régi Suse Linux 7.2-es kernelnél megállt az első fázisban...
[code:1:18a64e1fb2]hunger@yyyyyyy:/tmp > ./mremap-static

[+] Please wait...HEAVY SYSTEM LOAD!
1 of 1114129 [ 0 % ETA 10027152.0 s ] [/code:1:18a64e1fb2]

Kinek mi a tapasztalata? cstamas_ where are you? :D

http://www.securityfocus.com/archive/1/349488/2004-01-13/2004-01-19/0

ize, nem artana olvasni elotte:) majd legkozelebb

Ez most a tipikus megtaláltam-az-exploitot-én-is-benyomom-a-linket-és-okosnak-próbálok-látszani hozzáállás volt. A leírás már jóideje olvasható, az exploit viszont csak most került kiadásra, de azért köszönjük a mélyreható kommentet kedves handler, okosabbak lettünk tőle.

[quote:73f53fc354="hunger"]A két proof of concept exploit (az egyik Christophe Devine és Julien Tinnes munkája, a másik Angelo Dell'Aera átirata) után megjelent az igazi shellcode exploit is, köszönhetően az iSEC csapatnak.

A do_brk() exploit fórumon lévő tanakodás után már okosan -static opcióval fordítottam az exploitot, ami talán működik is, de baromi sokáig tart kivárni és rendkívül nagy loadot okoz...

[code:1:73f53fc354]hunger@xxxxxxx:~$ uname -a
Linux xxxxxxx 2.4.22 #4 Fri Oct 31 12:20:22 CET 2003 i686 unknown
hunger@xxxxxxx:~$ ./mremap-static

[+] Please wait...HEAVY SYSTEM LOAD!
15273 of 1114129 [ 1 % ETA 16548.0 s ][/code:1:73f53fc354]

Az új kerneleknél már végtelen ciklusba megy át a dolog...

[code:1:73f53fc354]hunger@mail:~$ uname -a
Linux mail 2.4.24-grsec #2 SMP Wed Jan 7 12:09:42 CET 2004 i686 unknown
hunger@mail:~$ ./mremap-static

[-] ERROR remapping
remap1: Invalid argument

entering endless loop[/code:1:73f53fc354]

És régi Suse Linux 7.2-es kernelnél megállt az első fázisban...
[code:1:73f53fc354]hunger@yyyyyyy:/tmp > ./mremap-static

[+] Please wait...HEAVY SYSTEM LOAD!
1 of 1114129 [ 0 % ETA 10027152.0 s ] [/code:1:73f53fc354]

Kinek mi a tapasztalata? cstamas_ where are you? :D

Vizsgázom....
Most megelégszem azzal hogy módosítottam egy exploitot ami *rebootolta volna* a gépet (hard reset) és strace-szel megnézem mit ad vissza a remap függvény ha nem invalid argument akkor sebezhető.

Látom azért rájöttél mit értettem a "kedvenc oldalad" alatt :-P

2.4.22 xfs-grsec + mmap patch

./mremap_test

[+] Please wait...HEAVY SYSTEM LOAD!
43379 of 1114129 [ 3 % ETA 9601.9 s ] w
1113801 of 1114129 [ 99 % ETA 3.0 s ]
[+] overflow done, the moment of truth...
[+] parent unprotected PTE
fopen: Permission denied

entering endless loop
Segmentation fault

kern.log-ban:
Jan 16 20:47:15 kernel: kernel BUG at memory.c:377!
Jan 16 20:47:15 kernel: invalid operand: 0000
Jan 16 20:47:15 kernel: CPU: 0
Jan 16 20:47:15 kernel: EIP: 0010:[zap_page_range+52/592] Tainted: P
Jan 16 20:47:15 kernel: EFLAGS: 00010246
Jan 16 20:47:15 kernel: eax: c4d54000 ebx: f6c90480 ecx: 00002000 edx: c4d54000
Jan 16 20:47:15 kernel: esi: f6c90480 edi: 00002000 ebp: 00000000 esp: d7f8de84
Jan 16 20:47:15 kernel: ds: 0018 es: 0018 ss: 0018
Jan 16 20:47:15 kernel: Process mremap_test (pid: 27311, stackpage=d7f8d000)
Jan 16 20:47:15 kernel: Stack: e0c90740 f6c90480 00002000 00000000 00000000 00000000 00000000 00000000
Jan 16 20:47:15 kernel: 00000000 00000000 00000000 00000000 00002000 c01ef675 f6c90480 00002000
Jan 16 20:47:15 kernel: 00000000 f6c90480 d7f8c000 d7f8c000 00000002 e0c90f40 c01ddb6a f6c90480
Jan 16 20:47:15 kernel: Call Trace: [exit_mmap+181/288] [mmput+74/112] [do_exit+161/592] [sig_exit+154/160] [do_signal+497/608]
Jan 16 20:47:15 kernel: [__switch_to+54/192] [schedule+758/800] [sys_pause+18/24] [signal_return+20/24]
Jan 16 20:47:15 kernel:
Jan 16 20:47:15 kernel: Code: 0f 0b 79 01 6e 24 3b c0 8d 74 26 00 89 cf 89 44 24 28 8b 44

[quote:4fa4dc52c4="cstamas_"]Vizsgázom....
Most megelégszem azzal hogy módosítottam egy exploitot ami *rebootolta volna* a gépet (hard reset) és strace-szel megnézem mit ad vissza a remap függvény ha nem invalid argument akkor sebezhető.

Látom azért rájöttél mit értettem a "kedvenc oldalad" alatt :-P

Jaja ;)
Jó vizsgázgatást, ilyenkor nem is szabad a gép elé ülni, mert ottragad az ember... :D

[quote:b0432619af="handler"]2.4.22 xfs-grsec + mmap patch

./mremap_test

Na ez már jobb, köszi.
Én egy 2.4.23-grsec kernelnél néztem és 8% körül segfaultolt a stuff...
A lényeg, hogy do_brk() veszélyesebb hiba volt, az élet fintora, hogy pont annál nem cselekedett időben Tosatti...

[code:1:17a6bbedf9]hunger@xxxxxxx:~$ ./mremap-static
[+] Please wait...HEAVY SYSTEM LOAD!
1114008 of 1114129 [ 99 % ETA 1.8 s ]
[+] overflow done, the moment of truth...
[+] parent unprotected PTE
depopulate SLAB #1
depopulate SLAB #2
depopulate SLAB #3
depopulate SLAB #4
depopulate SLAB #5
depopulate SLAB #6
depopulate SLAB #7
depopulate SLAB #8
depopulate SLAB #9
[!] parent check race... SUCCESS, cought SLAB page!
[+] PID 15002 GOT UID 0, enjoy!

root@xxxxxxx:~# id
uid=0(root) gid=0(root) groups=1006(hunger)
root@xxxxxxx:~# uname -a
Linux xxxxxxx 2.4.22 #4 Fri Oct 31 12:20:22 CET 2003 i686 unknown
root@xxxxxxx:~# tail -40 /var/log/kern.log
Jan 16 20:58:50 xxxxxxx kernel: kernel BUG at memory.c:377!
Jan 16 20:58:50 xxxxxxx kernel: invalid operand: 0000
Jan 16 20:58:50 xxxxxxx kernel: CPU: 0
Jan 16 20:58:50 xxxxxxx kernel: EIP: 0010:[zap_page_range+52/568] Not tainted
Jan 16 20:58:50 xxxxxxx kernel: EFLAGS: 00010246
Jan 16 20:58:50 xxxxxxx kernel: eax: d4f28000 ebx: c94d9be0 ecx: 00002000 edx: d4f28000
Jan 16 20:58:50 xxxxxxx kernel: esi: c94d9be0 edi: 00002000 ebp: 00000000 esp: d3c27e84
Jan 16 20:58:50 xxxxxxx kernel: ds: 0018 es: 0018 ss: 0018
Jan 16 20:58:50 xxxxxxx kernel: Process mc (pid: 9460, stackpage=d3c27000)
Jan 16 20:58:50 xxxxxxx kernel: Stack: d68bc480 c94d9be0 00002000 00000000 ffffffff d3c26000 ffff037f ffff0020
Jan 16 20:58:50 xxxxxxx kernel: ffffffff 08066c23 051c0023 00000000 00002000 c011f735 c94d9be0 00002000
Jan 16 20:58:50 xxxxxxx kernel: 00000000 c94d9be0 d3c26000 d3c26000 0000000f d68bc420 c011000e c94d9be0
Jan 16 20:58:50 xxxxxxx kernel: Call Trace: [exit_mmap+181/280] [mmput+74/96] [do_exit+133/560] [sig_exit+146/148] [do_sign
Jan 16 20:58:50 xxxxxxx kernel: [do_sigaction+156/212] [do_fork+1577/1816] [sys_clone+30/40] [signal_return+20/24]
Jan 16 20:58:50 xxxxxxx kernel:
Jan 16 20:58:50 xxxxxxx kernel: Code: 0f 0b 79 01 c0 2a 23 c0 89 cd 89 44 24 28 8b 44 24 30 89 44
Jan 17 01:01:21 xxxxxxx kernel: kernel BUG at vmscan.c:239!
Jan 17 01:01:21 xxxxxxx kernel: invalid operand: 0000
Jan 17 01:01:21 xxxxxxx kernel: CPU: 0
Jan 17 01:01:21 xxxxxxx kernel: EIP: 0010:[swap_out+290/1116] Not tainted
Jan 17 01:01:21 xxxxxxx kernel: EFLAGS: 00010246
Jan 17 01:01:21 xxxxxxx kernel: eax: 00002000 ebx: 00002000 ecx: 00002000 edx: ca493000
Jan 17 01:01:21 xxxxxxx kernel: esi: dfcc59e0 edi: 00000001 ebp: d6a16000 esp: c1597efc
Jan 17 01:01:21 xxxxxxx kernel: ds: 0018 es: 0018 ss: 0018
Jan 17 01:01:21 xxxxxxx kernel: Process kswapd (pid: 4, stackpage=c1597000)
Jan 17 01:01:21 xxxxxxx kernel: Stack: 00000000 c12ef03c 00000002 ffffffff c03fb000 c0000000 0a1ce045 00000001
Jan 17 01:01:21 xxxxxxx kernel: c0000000 d8a9ec00 c0000000 c0000000 00002000 ca493000 defa98c0 00000010
Jan 17 01:01:21 xxxxxxx kernel: c1596000 dfcc59e0 c027dc54 0022c400 c0126858 00000002 000001d0 00000002
Jan 17 01:01:21 xxxxxxx kernel: Call Trace: [shrink_cache+636/760] [shrink_caches+88/136] [try_to_free_pages_zone+60/92] [k
Jan 17 01:01:21 xxxxxxx kernel: [kswapd+153/188] [arch_kernel_thread+40/56]
Jan 17 01:01:21 xxxxxxx kernel:
Jan 17 01:01:21 xxxxxxx kernel: Code: 0f 0b ef 00 87 30 23 c0 8d b6 00 00 00 00 89 4c 24 2c 89 fb[/code:1:17a6bbedf9]

A lényeg, hogy az exploit működik, csak több órát kell várni rá...
[/img]