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/