Messages in this thread | | | From | Steve VanDevender <> | Date | Tue, 28 Dec 1999 12:20:15 -0800 (PST) | Subject | Re: Unexecutable stack |
| |
Horst von Brand writes: > Steve VanDevender <stevev@efn.org> said: > > > In theory it is possible to write executable code into a buffer > > in the data segment and overflow a buffer in the stack so that > > the stack frame contains a return address that points into that > > data. In practice it is much harder to create an exploit with > > this method as it requires quite detailed knowledge of the data > > segment layout. > > Yep, it is somewhat harder, and thus not done regularly by crackers today, > as this is rarely needed now. If/when this becomes common, the cracks will > become common too. Then we are where we started. Better than buying (false) > security is to fix the affected programs.
You are yet another person making the logically unsupportable argument that since a non-executable stack doesn't prevent all possible security compromises, it doesn't provide a real security benefit. It's true that when you cut off one avenue of attack, you cause attackers to concentrate on others. But cutting off avenues of attack does make it harder for attackers, and in practice making security attacks harder reduces the number of successful attacks, and that is a real benefit.
In this case a non-executable stack prevents a large and significant number of attacks, makes those attacks more noticeable ("what's that core file doing there?"), buys time to fix the vulnerable programs, and gives me some security now instead of wishful thinking that there will be perfect security later.
I know that making the stack non-executable is not a cure-all, and not a replacement for fixing programs that have buffer overflow problems. Even though the Solaris systems I work on have noexec_user_stack set, I still keep up with patches, disable nonessential daemons, remove unnecessary setuid permissions, and take all the other security precautions I can. Security is about defense in depth using many methods and layers of protection, and monitoring systems on the assumption that they _will_ be broken into, rather than assuming they're too secure to be penetrated.
- 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/
| |