Re: N00b questions :\

From: Diode Trnasistor (ffddfe_at_yahoo.com)
Date: 05/25/03

  • Next message: Murat Balaban: "Re: Abo3 (can someone help me?)" 
    Date: Sun, 25 May 2003 02:39:02 -0700 (PDT)
To: northern snowfall <dbailey27@ameritech.net>, "Janus N. Tøndering" <janus@bananus.dk>

    Thanx for responses, it's slightly clearer now. A few
    more clarifications:

    Memory alignment is clear, but word aligned this
    number should be 20 (5 byte buffer gets padded to 8
    and 12 stays at 12). I write this off to gcc behaving
    erratically.

    The enormous number being "added" to the stack makes
    sense if interpreted as two's compliment, question is,
    how did you know to interpret it as two's compliment
    :]

    And finally, strcpy causing a segfault at seemingly
    unrelated adress is still not clear to me. The given
    explonation was that i indeed do overwrite the saved
    EIP on the stack, but due to return never being
    called, process never jumps to that adress. Now
    correct me if i'm wrong but here's how i imagine the
    memory layout of vulndev2.c

    stack top [buff][base pointer][saved eip] stack bottom

    So now we call strcpy, strcpy writes way past buff,
    overwriting the bp, and eip. Then strcpy called
    return and that works fine since strcpy's stack frame
    is closer to the stack top than the buff, and the mess
    we made. Then execution keeps going untill the
    function main calls return (i modified vulndev2.c to
    call return instead of exit). Now when this return is
    called, what i think should happen, is the piece of
    memory i labeled saved eip should get poped into eip
    register, and voila, the process should try to execute
    instructions at adress 0x41414141 causing a
    segmentation fault. Instead, i get this:
    0x40085013 in _IO_getline_info () from /lib/libc.so.6

    and i'm confused. Halp.

    ps: someone else suggested that grsecurity patch may
    be applied to my kernel. It indeed is not, i am
    running standard-run of the mill-off the
    shelf-vanilla-kernel.org supplied 2.4.20 unmodified
    linux kernel. Any pointers would be most helpfull.
    Also if anyone else is getting the same results, or
    even different results, do let me know. Thanx.

    --- northern snowfall <dbailey27@ameritech.net> wrote:
    > >
    > >
    > >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.
    > >
    > FYI, compilers (are supposed to) align memory to the
    > requirement of the
    > underlying architecture. Most processors will throw
    > an alignment_error
    > exception if an opcode attempts to pass an unaligned
    > address to it.
    > This is done simply by padding the stack so that
    > each auto variable is
    > given a properly aligned memory address.
    > Don
    > http://deadchildren.org/~north_
    >
    >
    >

    __________________________________
    Do you Yahoo!?
    The New Yahoo! Search - Faster. Easier. Bingo.
    http://search.yahoo.com

  • Next message: Murat Balaban: "Re: Abo3 (can someone help me?)"