Messages in this thread | | | Date | Thu, 30 Dec 1999 21:39:28 -0500 | From | "Theodore Y. Ts'o" <> | Subject | Re: Unexecutable Stack / Buffer Overflow Exploits... |
| |
From: Steve VanDevender <stevev@efn.org> 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 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/
| |