Messages in this thread | | | From | Steve VanDevender <> | Date | Thu, 30 Dec 1999 16:26:02 -0800 (PST) | Subject | Re: Unexecutable Stack / Buffer Overflow Exploits... |
| |
Theodore Y. Ts'o writes: > The classic stack buffer overrun (smash the stack with code to be > executed on the stack) is always going to be easier to construct > than trickier buffer overruns that try to return into locations > outside the stack, because the stack is mapped at a fixed easily > determined location in all programs, while the location of data > buffers and library routines vary greatly. And since it is > easier to construct, _and_ if systems continue to permit it, then > it will continue to be deployed. > > Actually, that's not true. In order for a stack-smash to be developed, > you need to know exactly where in the stack you're going to be, so you > can set the return address appropriately. In general, a particular > exploit only works against a specific binary executable. At MIT Project > Athena, because we used a modified fingerd binary, the stack smash attack > used by the Internet Worm didn't affect us. The return address branched > to the wrong location (since we had extra stuff on the stack) and the > program core dumped instead of executing the attack code.
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.
- 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/
| |