On Wed, 26 Apr 2000, Derek Martin <[EMAIL PROTECTED]> wrote:
>
> Despite this, and as much as I respect Linus, I think the non-excecutable
> stack patch should be incorporated into the kernel proper. His argument
> is something like "adding it is like inviting people to write bad
> code, and leaving it out encourages better code."
>
> I think this is unrealistic. Lots of people write code; some good, some
> not so good. No one can analyze every peice of code ever written, and
> after all people, we all have a job to do. So it's inevitable that
> someone is going to run code that has buffer overflows, and probably lots
> of someones. We should have some protection from this, other than to
> simply say "well go write code that works better."
Here is a good post by Ted Ts'o on this issue:
| fa.linux.kernel
|
| From: Steve VanDevender <[EMAIL PROTECTED]>
| 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
| available.
|
| 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
| smashed.
|
| 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 mail to
[EMAIL PROTECTED] with the following text in the
*body* (*not* the subject line) of the letter:
unsubscribe gnhlug
**********************************************************
