From: Trano <Trano@gmx.net>
> > Yes. You need to return from the current function for the return address
> > to be used.
> Hum, sorry I don't understand you completely.
> Could you show me how the stack looks like in the example with the
> exit-call?
> In a 'normal' case it would look like this:
>
> [100 byte buf][4 byte EBP][4 byte EIP]
>
> If you now start the program with more than 108 chars as argument it
> should exit with "Segmentation fault [...] in address 0x41414141",
> shouldn't it?
> But I can't see why it sould behave in another way when exit is
> used... :-/
Polluting the stack with your chosen values does not give you instant
control of the program. Instead it leaves a value in memory for later use
that you hope will get you control *when the current function returns*.
If it never returns because the whole program has exited don't expect to
see the effect of the overflow. (Not that effect anyway. A function ending
in exit() might still have vulnerabilities affecting the way data is handled,
but the traditional attack is to alter the return address.)
The core dumps often arising from overflows are often because execution
at 0x41414141 is impossible and a different value needs to be used in
that part of the overflow string. Beginning with your shellcode in an
environment variable (as in one of the P49-14 examples) seems simplest
to me.
Bruce Schneier in "Secrets and Lies" compares a buffer overflow to a
delivery man in a shop with dim staff who follow an instruction manual.
If the delivery man puts a bogus sheet of instructions on the bottom of
his pile of forms and doesn't take it back again he's managed to transfer
a sheet of his onto the top of the instruction manual. *Next time the
shopkeeper consults it* he might find something like "help driver remove
all beer from shop".
------------------------------------------------------------------------
To unsubscribe email security-discuss-request@linuxsecurity.com
with "unsubscribe" in the subject of the message.
