Messages in this thread | | | From | Steve VanDevender <> | Date | Wed, 29 Dec 1999 12:23:36 -0800 (PST) | Subject | Re: Unexecutable Stack / Buffer Overflow Exploits... |
| |
Horst von Brand writes: > Where do you think script kiddies get their exploit scripts from? They > don't write them themselves: The real crackers share them with the > community. Just like the hacker community shares patches and cool > programs. So you can keep out 99.99% only until one of the 0.01% finds out > a way around it. The danger of "nonexecutable stack" is that it creates a > sense of security, which might be justified as long as it is rare. Once it > becomes widespread, it will be useless in short time, and _everybody_ will > have to pay the cost for nothing at all, while feeling smugly secure.
Anyone who thinks that a non-executable stack can replace other security measures is a fool. But arguing that a non-executable stack is not real protection because the widespread use of systems with non-executable stacks will only cause crackers to concentrate on other holes is also foolish. You may as well argue that file permissions are unnecessary becase well-behaved programs and users won't mess with files they're not supposed to, and the existence of restrictive file permissions merely causes crackers to find ways around them.
In reality, many programs still exist with exploitable buffer overflows and people are writing more. Code auditing and better software technology are not going to fix all of these programs. Just as you protect your files to prevent unwanted reading and writing, I want global protection against unwanted code execution that doesn't depend only on the competence of every coder.
I agree that any non-executable stack support should be an option. If you don't want it, you don't have to have it. I would love to have it for any Linux server system I set up.
Ultimately, saying that we shouldn't have protection against an existing security problem that shows no signs of going away because other kinds of security problems will occur in the future is a ridiculous argument.
- 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/
| |