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 <dbailey27at_private> 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
This archive was generated by hypermail 2b30 : Sun May 25 2003 - 20:44:02 PDT