Messages in this thread | | | Date | Fri, 31 Dec 1999 04:29:55 -0800 (PST) | From | Robert Dinse <> | Subject | Re: linux-kernel-digest V1 #4993 |
| |
On Thu, 30 Dec 1999 Theodore Y. Ts'o <tytso@MIT.EDU> wrote: > > Look, making the stack non-executable purports to solve a generic class > of problems involving stack overruns. The fact is, it doesn't.
I don't know who purports this, except yourself. I don't, I haven't seen anybody arguing for this capability advocating that it will solve a generic problem.
What has been said is that it will make it more difficult to exploit, and it will. It's another layer, not a complete solution.
> 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.
I agree, fundamentally that is the problem. It's kind of like when you want to go to the moon, fundamentally the problem is gravity, and you have to expend huge amounts of energy to overcome it. But fundamentally, you don't have the option of turning it off so that's what you have to do.
Fundamentally, software authors will continue to write buggy code that can be exploited, so we need protections that make that exploit more difficult.
> 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.
This is a more difficult problem though, because ANY change in the binary will change that location and you can't pad it with 8k of nulls to make an approximation adequate.
> 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!
No, but it made it CONSIDERABLY more difficult. Now instead of being within 8k (or potentially more with TCP attacks) of the target, you've got to be right on, to the byte. ANY change in the binary that moves that instruction by one byte will make the attack fail.
In all likelihood, the conventional attack is going to be tried first because it's easiler. And that, with the non-executable stack in place, will be logged, so you know you're being attacked and have an opportunity to deal with it.
Look, if you're going to demand that any security fix be a 100% fix, nothing will EVER progress in the arena of security because nothing is 100%. You can only make it harder, more difficult to penetrate. That is all you CAN do. That's life, that's reality. Maybe it bites or bytes... But that's it.
To argue that we shouldn't we shouldn't make it better because we can't make it perfect is ludicrous.
- 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/
| |