Re: Unexecutable stack

Steve VanDevender (stevev@efn.org)
Tue, 28 Dec 1999 12:20:15 -0800 (PST)


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/