Sorry, sure you're right, I was a bit confused yesterday and didn't
understood what you meant.
thx for the help :)
> 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.
