Re: Unexecutable Stack / Buffer Overflow Exploits...

Steve VanDevender (stevev@efn.org)
Sun, 2 Jan 2000 12:33:48 -0800 (PST)


Gregory Maxwell writes:
> On Thu, 30 Dec 1999, Horst von Brand wrote:
>
> [snip]
> > Get the patch and apply it. I prefer not to rely on papering over the
> > holes.
>
> must resist reply....argh
>
> Thank you for offering to work 24hours a day patching my systems at a cost
> I can afford. I'll be looking forward to reciving your info so I can get
> you on the payroll.
>
> Seriously, no one here would dare replace a real fix with a stack
> paperbag.

I continue to find it frustrating that there are people who
believe that a theoretical possibility negates a concrete,
demonstrable benefit from having a non-executable stack.

A non-executable stack doesn't protect against all possible
overrun exploits -- but it makes the remaining cases much harder
to construct, particularly from a remote location, as approximate
methods no longer work. This means fewer successful exploits and
a higher chance of detecting programs with exploitable overflows
_before_ they are successfully exploited, so they can be fixed
sooner.

Buffer overrun exploits are best fixed by fixing the
badly-written code -- but despite widespread knowledge of good
coding techniques and the existence of tools that detect and warn
against them during developement, programs whose buffers can be
overrun are being written every day. I still see a
non-executable stack as being no different in principle than the
other protections and sanity checks OSes already include to
defend themselves against poorly-behaved users and programs, and
perfectly in line with the security principle of minimum
exposure, and not just "papering over a bug."

The weightiest, but to me still not prohibitive, argument is that
the kernel code to implement a non-executable stack is just more
bloat. This only really makes sense from an i386-centric point
of view, where the architecture is not capable of making
individual pages non-executable. On many other architectures
this is as simple as _not_ setting the execute bit when creating
stack pages.

-
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/