lkml.org 
[lkml]   [1999]   [Dec]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:0.756 / U:0.740 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site