Mark Morrissey wrote:
>Or perhaps even just having Linux and MS make the stack non-executable.
>
>Is anyone here aware of valid reasons why linux, MS, et al. need an
>executable stack?
>
Patches are available for Linux, Windows, Solaris, and *BSD that make
the stack non-executable. IIRC, it is standard on OpenBSD, and it is
standard on Immunix Linux.
Why it is not standard on Linux: because Linus doesn't like it. Linus'
rationalle is that he believes that all problems that can be solved in
user-space should be solved in user-space, and not in the kernel, to
keep the kernel from bloating. Buffer overflows can be solved in
user-space, and so Linus rejects non-executable stacks. Is that valid?
Depends on your point of view.
The real impact of non-executable stacks is that:
* Some run-time code generation (think Lisp) doesn't work.
* The trampoline feature of GCC stops working. Perry Wagle has an
extensive rant :) on why this is evil, but he's one of the few
people I know who understands trampolines.
* Some hacking around signal delivery is required: to deliver
signals, the kernel deposits code on the user-space stack and
executes it. The non-executable stack feature has to be disabled
during signal delivery.
Why not on Windows: because unfortunate choices in how Windows uses the
Intel MMU, combined with unfortunate choices in how the Intel MMU works
in the first place (no separate Read and Execute bits per page) mean
that you have to do elaborate TLB munging to get a non-executable stack,
and that imposes a significant performance penalty (10% or so).
On Solaris, it is a standard feature, it is just turned off by default.
Turning it on is a one-line config edit.
Note: non-executable stack is *not* a secure defense against buffer
overflows. It will stop most stock stack smashing exploits, but these
exploits could be re-written to bypass the non-executable stack using
variations of the technique known as "return into libc"
http://community.corest.com/~juliano/non-exec-stack-sol.html You can in
fact turn off executability in *all* data segments, and buffer overflows
can still work, because the attacker can aim at code resident in the
program's text segment.
Crispin
--
Crispin Cowan, Ph.D. http://immunix.com/~crispin/
Chief Scientist, Immunix http://immunix.com
http://www.immunix.com/shop/
This archive was generated by hypermail 2b30 : Tue Oct 07 2003 - 13:26:32 PDT