Taking the control by abusing array index.

[Agustin Gianni <agustingianni () gmail com>]

Hello, this came up to my head while i was reading a traceroute 
implementation.
This traceroute has a similar bug, it refers to an array of pointers
and the int value that is acting as the array index is unsigned. The 
problem is
that it does something like this

pointer_array[unsigned_int] = malloc(....);

I can control unsigned_int value

My question is, has anybody seen this kind of programming bug?
Any ideas on how to exploit this?

The attached file has some ideas, but it is not directly applicable
to this bug.

Well thanks!

/*
  Copyright (c) 2005 by Agustin Gianni
  
  How do we exploit this? By placing the right value in argv[2].
  How is this? Well, we have array[256]
  and we can place any string supplied in argv[1] wherever we want inside the buffer.
  But there is a little mistake (or huge) We control the index of the array.
  This make us able to access wherever we want by passing a greater value at argv[2]. also note
  that atoi returns a int, not a u_int. This allows us to access memory before the buff.
    
  The concept is quite simple. You have to find in this case the address of ptr. It is located 
  on the stack. found it by debbuging and placing breakpoints and then do x/x $esp and
  look for 0xdeadbeef :)

  ptr is:
  (gdb) x/x $esp
  (gdb)
  0xbffff88c:     0xdeadbeef

  Now we have to choose the address of ptr. I choosed :) addr of argv[3] because it is
  the simpler way i can think =) heheheh
  The address of argv varies, the same way ptr addres do. So we have to find it debbugin again
  
  (gdb) x/s argv[3]
  0xbffffa3a:      "ls"
  
  Once we have the 2 addresses we are almost ready to exploit this thing.
  We must make ptr point to argv[3].
  But how? Well we control the arry index, so what if we get the address of array
  and see what is the offset between array and ptr? That will be or magic number.
    
  (gdb) x/x array
  0xbffff780:     0x40014c20

  |argv|ptr|array|
  
  Array is at a lower addres than pointer, so we must supply a positive value in argv[2]
  This number will be the difference between 0xbffff88c - 0xbffff780 = 268)Dec
  
  We are ready to exploit this thing!
  
  Now we have ptr ----> (argv[3] = "ls")  
  ________________
  _The poc (?)____
   
  kenny root # gdb arry
  GNU gdb 6.0
  
  (gdb) r `printf "\x3a\xfa\xff\xbf"` 268 ls
  Starting program: /mnt/slackware/root/arry `printf "\x14\xfa\xff\xbf"` 268 ls
  
  bin  boot  dev  etc  home  lib  mnt  opt  proc  root  sbin  sys  tmp  usr  var
  
  Program exited normally.
  (gdb)
  
  As you can see, this method sucks. We have too much things to find :S but. I will do
  a little more "research".
  
*/

#include <stdio.h>
#include <string.h>

int
main(int argc, char **argv)
{
        char *ptr = 0xdeadbeef;
        char array[256];
        
        strncpy(&array[atoi(argv[2])], argv[1], strlen(argv[1]));
        system(ptr);
        
        return 0;
}