Re: N00b questions :\

From: Janus N. (janus_at_bananus.dk)
Date: 05/25/03

  • Next message: Janus N.: "Re: [Vuln-dev Challenge] Challenge #2" 
    To: Diode Trnasistor <ffddfe@yahoo.com>
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

  • Next message: Janus N.: "Re: [Vuln-dev Challenge] Challenge #2"