Just came across after a very trivial change..

#include <stdio.h>

void crash()
{
   char buf[20];
   char *p = "\xff\xff\xff\xff\xff\xff";

   sprintf(buf, "%02x:%02x:%02x:%02x:%02x:%02x",
                                          p[0],
                                          p[1],
                                          p[2],
                                          p[3],
                                          p[4],
                                          p[5]);

   printf("%s\n", buf);
}

int main()
{
   crash();

   return 0;
}

Compiled & Run

neo@sauron ~/documents/website/blog $ ./a.out
ffffffff:ffffffff:ffffffff:ffffffff:ffffffff:ffffffff
Segmentation fault
neo@sauron ~/documents/website/blog $ gdb ./a.out
GNU gdb 6.4
Copyright 2005 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1".

(gdb) r
Starting program: /home/neo/documents/website/blog/a.out
Failed to read a valid object file image from memory.
ffffffff:ffffffff:ffffffff:ffffffff:ffffffff:ffffffff

Program received signal SIGSEGV, Segmentation fault.
0x66666666 in ?? ()
(gdb) i r $eip
eip            0x66666666       0x66666666
(gdb)

Evident stack overflow!
But isnt ff:ff:ff:ff:ff:ff is what I expected?

A little fix

neo@sauron ~/documents/website/blog $ diff ~/junk/crash.c ~/junk/crash2.c
6c6
<    char *p = "\xff\xff\xff\xff\xff\xff";
---
>    unsigned char *p = "\xff\xff\xff\xff\xff\xff";
neo@sauron ~/documents/website/blog $   

Compiled & Run

neo@sauron ~/documents/website/blog $ gcc ~/junk/crash2.c
neo@sauron ~/documents/website/blog $ ./a.out
ff:ff:ff:ff:ff:ff
neo@sauron ~/documents/website/blog $    

So how many apps are vulnerable like this?
and no, -fstack-protector probably wont fully protect you.. but ofcourse it will pretty much obscure the exploitation path, got to look into it.. apparently looked like a canary based protection..

GCC Stack protector adds following:

In procedure prolog:

0x0804842d :   mov    %gs:0x14,%eax
0x08048433 :  mov    %eax,0xfffffff0(%ebp) 
0x08048436 :  xor    %eax,%eax

In procedure epilog:

0x080484c0 : mov    0xfffffff0(%ebp),%eax
0x080484c3 : xor    %gs:0x14,%eax 
0x080484ca : je     0x80484d1  
0x080484cc : call   0x8048330 <__stack_chk_fail@plt> 

In procedure prolog, a 32 bit cookie is placed at (SFP - 8) which is checked with the original at %gs:0x14 which if not matched, __stack_chk_fail overflow handler is trigger thus abort()'ing. So apparently there is no way of corrupting saved EIP without corrupting this cookie and hence the protection.

Bypassable?

Idea: I have a process (in memory execution context of a program.. remember?) that contains a function `do_something()`, can I at runtime patch this function or replace this function with a completely new externally supplied code? Patch GOT? Patch PLT? ptrace will help? google for ELF internals?

Thank god, feeling better :-)

posted at: 15:13 | path: / | permanent link to this entry