hacking-the-art-of-exploitation

functions are shared, so any program that uses the printf() function directs
execution into the appropriate location in libc. An exploit can do the exact
same thing and direct a program’s execution into a certain function in libc.
The functionality of such an exploit is limited by the functions in libc, which
is a significant restriction when compared to arbitrary shellcode. However,
nothing is ever executed on the stack.
0x6b2
Returning into system()
One of the simplest libc functions to return into is system(). As you recall, this
function takes a single argument and executes that argument with /bin/sh.
This function only needs a single argument, which makes it a useful target.
For this example, a simple vulnerable program will be used.
vuln.c
int main(int argc, char *argv[])
{
char buffer[5];
strcpy(buffer, argv[1]);
return 0;
}
Of course, this program must be compiled and setuid root before it’s truly
vulnerable.
reader@hacking:~/booksrc $ gcc -o vuln vuln.c
reader@hacking:~/booksrc $ sudo chown root ./vuln
reader@hacking:~/booksrc $ sudo chmod u+s ./vuln
reader@hacking:~/booksrc $ ls -l ./vuln
-rwsr-xr-x 1 root reader 6600 2007-09-30 22:43 ./vuln
reader@hacking:~/booksrc $
The general idea is to force the vulnerable program to spawn a shell,
without executing anything on the stack, by returning into the libc function
system(). If this function is supplied with the argument of /bin/sh, this should
spawn a shell.
First, the location of the system() function in libc must be determined.
This will be different for every system, but once the location is known, it will
remain the same until libc is recompiled. One of the easiest ways to find the
location of a libc function is to create a simple dummy program and debug it,
like this:
reader@hacking:~/booksrc $ cat > dummy.c
int main()
{ system(); }
reader@hacking:~/booksrc $ gcc -o dummy dummy.c
reader@hacking:~/booksrc $ gdb -q ./dummy
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
Countermeasures 377