Vulnerability Development mailing list archives
Re: Cannot access memory at address 0x90909090
From: ". npguy" <npguy () linuxmail org>
Date: Sat, 13 Sep 2003 10:23:48 +0800
isn't it possible (in linux) by overwriting retaddr with some address contains "jmp %esp" locates within process. this techniques might help in some condition the buffer avaialbe before ret is not sufficient for opcodes.? [NOPNOPNOPNOPNOP<SHELLCODE>][xxx][RET] ----- Original Message ----- From: DownBload <downbload () hotmail com> Date: 12 Sep 2003 09:11:14 -0000 To: vuln-dev () securityfocus com Subject: Re: Cannot access memory at address 0x90909090
In-Reply-To: <24403.1063282768 () www35 gmx net> hi, EIP is pointed to 0x90909090 because of wrong calculation. EIP is probably overwriten with 0x90909090 instead of valid return address where NOP's are in memory. Stack looks like this: [buffer][ebp][eip] - What you've done is this: buffer EBP EIP [NOPNOPNOPNOPNOPNOPNOP][NOP][NOP] When EIP is pop-ed from stack, EIP will point to instruction at memory address 0x90909090 and segfault signal will be delivered, because you can't access to 0x90909090. - What you should do is this: buffer EBP EIP [NOPNOPNOPNOPNOP<SHELLCODE>][xxx][RET] A | | | --------------------------- When EIP is pop-ed from stack, EIP will point to NOP array, and after NOP's, shellcode is executed.hi folks, little buffer overflow question, if i have a prog that segfaults like this: ------------------------------------------------./trapd -M `perl -e 'print "A" x 136'`Segmentation fault (core dumped)gdb ./trapd ./trapd.coreGNU gdb 4.18 (FreeBSD) . . . Core was generated by `trapd'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/local/lib/libsnmp.so.4...(no debugging symbols found)...done. Reading symbols from /usr/lib/libcrypto.so.3...(no debugging symbols found)...done. Reading symbols from /usr/lib/libkvm.so.2...(no debugging symbols found)...done. Reading symbols from /usr/lib/libz.so.2...(no debugging symbols found)...done. Reading symbols from /usr/lib/libm.so.2...(no debugging symbols found)...done. Reading symbols from /usr/lib/libdevstat.so.2...(no debugging symbols found)...done. Reading symbols from /usr/lib/libwrap.so.3...(no debugging symbols found)...done. Reading symbols from /usr/lib/libc.so.4...(no debugging symbols found)...done. Reading symbols from /usr/libexec/ld-elf.so.1...(no debugging symbols found)...done. #0 0x41414141 in ?? () (gdb) i reg eax 0xffffffff -1 ecx 0xe 14 edx 0xffffffff -1 ebx 0x280bcde8 671862248 esp 0xbfbff8a8 0xbfbff8a8 ebp 0x41414141 0x41414141 esi 0x8056100 134570240 edi 0x0 0 eip 0x41414141 0x41414141 eflags 0x246 582 cs 0x1f 31 ss 0x2f 47 ds 0x2f 47 es 0x2f 47 fs 0x2f 47 gs 0x2f 47 (gdb) ------------------------------------------------ ...and after that want to exploit it with a common stack smash exploit, why does it say: ------------------------------------------------ #0 0x6e692e2f in ?? () (gdb) bt #0 0x6e692e2f in ?? () #1 0x90909090 in ?? () Cannot access memory at address 0x90909090. (gdb) f 1 #1 0x90909090 in ?? () (gdb) i reg eax 0xffffffff -1 ecx 0xe 14 edx 0xffffffff -1 ebx 0x280bcde8 671862248 esp 0xbfbfd3f8 0xbfbfd3f8 ebp 0x90909090 0x90909090 esi 0x8055100 134566144 edi 0x0 0 eip 0x90909090 0x90909090 eflags 0x246 582 cs 0x1f 31 ss 0x2f 47 ds 0x2f 47 es 0x2f 47 fs 0x2f 47 gs 0x2f 47 (gdb) x/10i $pc 0x90909090: Cannot access memory at address 0x90909090. (gdb) x/10i $eax 0xffffffff: Cannot access memory at address 0xffffffff. (gdb) x/10i $eip 0x90909090: Cannot access memory at address 0x90909090. (gdb) x/10i $ebp 0x90909090: Cannot access memory at address 0x90909090. (gdb) x/10i $edi 0x0: Cannot access memory at address 0x0. (gdb) x/10i $ecx 0xe: Cannot access memory at address 0xe. (gdb) x/10i $esp 0xbfbfd3f8: fs 0xbfbfd3f9: gs 0xbfbfd3fa: js 0xbfbfd3fc 0xbfbfd3fc: (bad) 0xbfbfd3fd: aaa 0xbfbfd3fe: or (%eax),%ebp 0xbfbfd400: push %eax 0xbfbfd401: aam $0xffffffbf 0xbfbfd403: mov $0x2807a630,%edi 0xbfbfd408: call 0xe0e7dfda ------------------------------------------------ ...if i replace '\x41\x41\x41\x41' with a valid address in my NOP space? Shouldn't the prog run through the NOPS until it reaches and executes the shellcode? Why isn't that the case here? It seems to jump, but can't execute \x90...!? I have no kernel protection or gcc patch. thanks & kind regards Ingram -- COMPUTERBILD 15/03: Premium-e-mail-Dienste im Test -------------------------------------------------- 1. GMX TopMail - Platz 1 und Testsieger! 2. GMX ProMail - Platz 2 und Preis-Qualitätssieger! 3. Arcor - 4. web.de - 5. T-Online - 6. freenet.de - 7. daybyday - 8. e-Post------------------------------------ DownBload / Illegal Instruction Labs Security Research & Education http://www.ii-labs.org e-mail:downbload[at]hotmail.com
-- ______________________________________________ http://www.linuxmail.org/ Now with e-mail forwarding for only US$5.95/yr Powered by Outblaze
Current thread:
- Cannot access memory at address 0x90909090 Ingram (Sep 11)
- Re: Cannot access memory at address 0x90909090 fr0stman (Sep 11)
- <Possible follow-ups>
- Re: Cannot access memory at address 0x90909090 DownBload (Sep 12)
- Re: Cannot access memory at address 0x90909090 . npguy (Sep 13)
- openssh vulnerability Diode Trnasistor (Sep 16)
- Re: openssh vulnerability Przemyslaw Frasunek (Sep 16)
- Re: openssh vulnerability Robert A. Seace (Sep 16)
- openssh vulnerability Diode Trnasistor (Sep 16)