system function actually executes
/bin/sh -c command (see the man page). An
sh: 1 something means that you have successfully called
system but with the wrong parameter. Whatever follows the
sh: 1 is what you have tried to execute... that may be non-printable garbage.
Said that, at first glance, it looks like everything is in place except the pointer to
/bin/sh. To get it you can either do as @IoTh1nkN0t did (add it into the stack as part of the string you are entering and then push the appropriate pointer in your payload) or use the trick that @_py indicated to get the string from libc at a fixed offset. I have to said that, just using
strings, didn't work for me. The offset I need is different of the one reported by
strings (strings reports the file offset depending how your sections are mapped it may be different to the memory offset... that does not happen with code whose file offset is usually 0).
So I wrote a small program to get the data I need for my current setup:
// FIXME: Get size from the ELF
// Actually it should be fine to just search the .rodata section
#define SIZE 0x1fffff
int main ()
unsigned char *ptr, *ptr2;
printf ("Libc base address: ");
scanf ("%p", &ptr);
ptr2 = ptr;
printf ("Looking for '/bin/sh'...");
for (;ptr < ptr2 + SIZE; ptr++)
if (!strncmp (ptr, "/bin/sh\0", 7))
printf("Found at %p %x (%s)\n", ptr, ptr - ptr2, ptr);
For this post, that uses 32bits binaries I compiled with:
gcc -m32 -o slibc slibc.c
The output from this tool on my system is: (
0xf7e0d000 comes from
Libc base address: 0xf7e0d000
Looking for '/bin/sh'...Found at 0xf7f4ecec 141cec (/bin/sh)
$ strings -a -t x /lib/i386-linux-gnu/libc.so.6 | grep "/bin/sh"
Then using the address reported by the tool should work. At least, it worked for me.
Also note that you are running a PIE which may have a slightly different stack layout. In my tests I had to add 4 bytes to the 'A' strings to get the exploit working with the PIE version. You can disable pie with the flag '-no-pie'. Check with
file to be sure you disabled it.