[lkml]   [1999]   [Dec]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Unexecutable Stack / Buffer Overflow Exploits...
   From: Steve VanDevender <>
Date: Thu, 30 Dec 1999 17:58:09 -0800 (PST)

1. Most buffer overrun exploits are simple stack smashes that
would be prevented by a nonexecutable stack. Arguing that this
would provide no real protection because it will force crackers
to develop on other methods of attack is bogus, because you could
make the same argument for almost any other built-in OS security
protection, i.e. restricting file permissions forces crackers to
find ways to gain the privileges needed to write to the files
they want, so restricting file permissions is only a temporary
solution too by that logic. The point is that something that was
available and easily exploitable to bypass security is no longer

People keep making this argument, but it's not a valid one.

Look, making the stack non-executable purports to solve a generic class
of problems involving stack overruns. The fact is, it doesn't.
Fundamentally, the real problem is the fact that the program allows an
automatic array variable to be overrun, and allow the stack to be

Suppose an attacker find a stack overrun in sendmail and the stack is
executable; he just simply sends data which overwrites the return
location on the stack, and contains the code to run execv("/bin/sh").
If the stack is made non-executable, then all the attacker needs to do
is find some place in the sendmail text where the instruction "call
execv" lives. He then overwrites the arguments area of the stack with
the desired arguments of execv, makes the return address point to the
"call execv" instruction, and then when the function returns, control is
transfered to the "call execv" instruction, which then in turn transfers
control to the execv code in libc, and we're off to the races.

So making the stack non-executable didn't stop the attack! It changed
the method by which the attacker might need to exploit a stack smash,
but that's about it. And once someone writes a tool to automatically
analyze a binary to find vulnerable places where a stack smashing attack
can transfer control into a victim program's text area, then any
advantage making the stack non-executable is well and truely gone. At
best, making the stack non-executable is really only a
security-through-obsecurity kind of thing. It will stop stupid
hackers.... temporarily.... until they adapt their methods to attack the
very same holes they are attacking today.

It's like putting antibiotics into chicken feed. It might temporarily
decrease the spread of certain types of bacteria in improperly cooked
food, but in the long run, the bacteria develop resistance, and then
we're back where we're started. And you'll notice that scientists have
made the argument that it's better not to put antibiotics in chicken
feed if it isn't going to stop the bacteria in the long run. This is a
similar situation.

- Ted

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

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