hacking-the-art-of-exploitation

aslr_demo.c
#include
int main(int argc, char *argv[]) {
char buffer[50];
printf("buffer is at %p\n", &buffer);
if(argc > 1)
strcpy(buffer, argv[1]);
}
return 1;
This program has an obvious buffer overflow vulnerability in it. However,
with ASLR turned on, exploitation isn’t that easy.
reader@hacking:~/booksrc $ gcc -g -o aslr_demo aslr_demo.c
reader@hacking:~/booksrc $ ./aslr_demo
buffer is at 0xbffbbf90
reader@hacking:~/booksrc $ ./aslr_demo
buffer is at 0xbfe4de20
reader@hacking:~/booksrc $ ./aslr_demo
buffer is at 0xbfc7ac50
reader@hacking:~/booksrc $ ./aslr_demo $(perl -e 'print "ABCD"x20')
buffer is at 0xbf9a4920
Segmentation fault
reader@hacking:~/booksrc $
Notice how the location of the buffer on the stack changes with every
run. We can still inject the shellcode and corrupt memory to overwrite the
return address, but we don’t know where the shellcode is in memory. The
randomization changes the location of everything on the stack, including
environment variables.
reader@hacking:~/booksrc $ export SHELLCODE=$(cat shellcode.bin)
reader@hacking:~/booksrc $ ./getenvaddr SHELLCODE ./aslr_demo
SHELLCODE will be at 0xbfd919c3
reader@hacking:~/booksrc $ ./getenvaddr SHELLCODE ./aslr_demo
SHELLCODE will be at 0xbfe499c3
reader@hacking:~/booksrc $ ./getenvaddr SHELLCODE ./aslr_demo
SHELLCODE will be at 0xbfcae9c3
reader@hacking:~/booksrc $
This type of protection can be very effective in stopping exploits by the
average attacker, but it isn’t always enough to stop a determined hacker. Can
you think of a way to successfully exploit this program under these conditions?
0x6c1
Investigations with BASH and GDB
Since ASLR doesn’t stop the memory corruption, we can still use a bruteforcing
BASH script to figure out the offset to the return address from the
380 0x600