Vulnerability Development mailing list archives
Re: N00b questions :\
From: "Janus N." Tøndering <janus () bananus dk>
Date: 25 May 2003 02:34:47 +0200
On Sun, 2003-05-25 at 01:52, Diode Trnasistor wrote:
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?
0xfffffffc should be interpreted using 2's complement. So this is actually a negative number (-4).
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...
GCC sometimes allocates more memory for each variable on the stack than is actually requested. I have no idea exactly why and what is does -- but I assume it is some small optimization.
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!
You do actually overwrite the return address but the return address will only be jumped to by a call to return. exit does _not_ use the return address. Hope this helps a little. Janus N. Tøndering
Current thread:
- Re: [Vuln-dev Challenge] Challenge #2, (continued)
- Re: [Vuln-dev Challenge] Challenge #2 Jose Ronnick (May 24)
- Re: [Vuln-dev Challenge] Challenge #2 Janus N. (May 24)
- Re: [Vuln-dev Challenge] Challenge #2 Diode Trnasistor (May 26)
- Re: [Vuln-dev Challenge] Challenge #2 Janus N. (May 26)
- Re: [Vuln-dev Challenge] Challenge #2 Robert Hogan (May 30)
- Re: [Vuln-dev Challenge] Challenge #2 Janus N. (May 30)
- Re: [Vuln-dev Challenge] Challenge #2 Diode Trnasistor (May 26)
- Gera's Insecure Programing abo7 sin (May 30)
- N00b questions :\ Diode Trnasistor (May 24)
- Re: N00b questions :\ Janus N. (May 24)
- Re: N00b questions :\ northern snowfall (May 24)
- Re: N00b questions :\ Janus N. (May 24)
- Re: N00b questions :\ northern snowfall (May 24)
- Re: N00b questions :\ Diode Trnasistor (May 25)