Ruby-pcap is a pretty neat ruby binding for the pcap library.

While working with ruby-pcap, I found the lack of support for pcap_findalldevs API in the binding..
so Here is a small patch to add it into the ruby-pcap extension libary.

Here is the test case.

posted at: 18:24 | path: / | permanent link to this entry

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

Weirdly enough, a small apparently elegant looking code working fine on my box and when statically compiled on my box works fine on all others boxens I tested. But trouble striked when of my colleague svn co'd my code and tried writing some plugin. The blue sky turned grey for me as it began crashing in bootstrapping of the app itself, apparently in a linked list implementation of circular queue.

After considerable amount of fiddling with..

neo@sauron ~/ROOT/work/v2/production $ cat > gdb
break *(start_loader+116)
command 1
p entry
p entry->name
p entry->func
p entry->next
p entry->prev
continue
end

(gdb) source ./gdb
Breakpoint 1 at 0x80ca831: file ra_loader.c, line 128.
(gdb) r
.
.
Breakpoint 1, 0x080ca831 in start_loader () at ra_loader.c:128
128           if(strncmp(entry->name, "bootstrap", strlen("bootstrap")) == 0)
{
$141 = (struct load_entry_t *) 0x828d8f0
$142 = 0x4fe1 

$143 = (void (*)()) 0x4fe1
$144 = (struct load_entry_t *) 0xb7ee552c
$145 = (struct load_entry_t *) 0x0

Program received signal SIGSEGV, Segmentation fault.
0x080ca831 in start_loader () at ra_loader.c:128
128           if(strncmp(entry->name, "bootstrap", strlen("bootstrap")) == 0)
{

Initially looked like heap overflow somewhere which resulted in pointer overwrites, but after considerable effort, found its the same common flaw in pointer link/unlink of list blocks.

Lesson learned: try not to write up a quick queue/list implementation playing with malloc'd ptrs, prefer using well tested ones.. probably `man queue` (sys/queue.h) and rtfm helps..

http://www.gnu.org/software/libc/manual/html_node/Tracing-malloc.html#Tracing-malloc

posted at: 18:17 | path: / | permanent link to this entry