Today, Jamie Blondin gleaned this insight:
> The way I understand it, eliminating the use of executable code in the stack
> would not make it necessarily harder to exploit, but just requires the
> exploiter to use a different method. Changing the way the stack works would
> cause some script writers to have to rewrite their scripts, and all the
> script kiddies would be confused for a couple months. In a way, that's
> similar to bacteria adapting to a restrictive environment, the exploits
> would all eventually be changed to use a different method of taking
> advantage of bad code.
Based on Ted's description of what you'd have to do to get around a
non-executable stack: Every C program that has a local variable (virtually
all of them) has a stack, where only programs that call other programs
have a call to execv, so right there it is harder to implement an attack
on a non-executable stack system.
It's probably also a little harder to determine where in memory the exec
call is, since you don't have a handy register (like the stack pointer) to
tell you where it is. So there again, it's still harder. The real
question is to what degree. I don't have the answer to that, but in my
mind, it doesn't really matter, as long as there's something to be gained,
no matter how small. I have yet to see anyone describe what would be LOST
by implementing this.
> In addition, not having exploitable code in the stack could cause
> programmers to gain a false sense of security, and not keep track of
> possible stack overrun exploits, thinking that since the stack is
> non-executable, the attacker cannot exploit it. (Programmers are lazy
> folk.) It was mentioned that Linus uses this as a reason not to make the
> stack non-executable - he doesn't want to encourage bad code-writing. If
> the change is made so that the stack is non-executable, then we could have a
> situation where you will end up in worse shape than if you had done nothing,
> because people could be writing less secure code. So the analogy with the
> antibiotics is fairly accurate, even up to the case where overuse of
> antibiotics (i.e. the adoption of a non-executable stack) could cause more
> harm than good.
Based on what I've said above alone, I'd have to refute this argument in
support of the analogy, but the analogy is far less important than the
argument against using non-writable stacks, which I also refute.
Programmers who know how to write secure code generally do. It's those
who don't that we have to worry about. As I've already said earlier in
this thread, no system administrator has time to analyze every line of
code that gets run on their system, even if they have the ACCESS and the
KNOWLEDGE to do so, which is by far the minority of cases. Anti-stack
smashing may not solve the problem, but it DOES HELP protect us from bad
code that we are running (often because we have no choice). Therefore it
should be included in the kernel, unless other compelling reasons dictate
otherwise. I am not aware of any other arguments.
--
PGP/GPG Public key at http://cerberus.ne.mediaone.net/~derek/pubkey.txt
------------------------------------------------------
Derek D. Martin | Unix/Linux Geek
[EMAIL PROTECTED] | [EMAIL PROTECTED]
------------------------------------------------------
**********************************************************
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
**********************************************************
