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
This archive was generated by hypermail 2b30 : Sat May 24 2003 - 17:38:49 PDT