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.