Many of the stack-smashing exploits I've seen pad the exploit
code with a large number of no-op instructions; the return then
has to point only somewhere into the no-op padding rather than
directly at the useful part of the exploit code. Making a
successful exploit in those cases takes less detailed knowledge
and a lot fewer attempts before finding a return address that
works, and it works in many more cases since the frame that gets
smashed can be located over a much larger range of addresses.
How much is a "large" number of no-op's? 4k? 8k? Usually it's a lot
less than that; a few hundred no-op's at most. Remember, you actually
have to send that many bytes down the network connection, and there may
be other things (such as the maximum UDP packet size) which may limit
how big you can make your "no-op runway".
In any case, I suspect that if something randomly added some random
value between 0 and 128k to the stack pointer at startup time, it would
also go a fairly long way towards thwarting overrun attacks --- but make
no mistake, it's still only papering over the problem.
- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/