lkml.org 
[lkml]   [1999]   [Dec]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: Unexecutable stack
>> == Adam J. Richter <adam@yggdrasil.com>
> == Anton Ivanov <aivanov@eu.level3.net>

>> If the problem with making the stack unexecutable is a few
>> pieces of trampoline code, then how about just modifying the few
>> programs that use this code to mprotect the stack when they actually
>> need it to be executable?
[...]

>1. It is a stick with two ends. You become slow lame and lazy and forget to
>update (under the idea: whatever, nobody can exploit it anyway).
>Have a look at DGUX. It used to have a non-exec stack in the 3.x days. As a
>result most of the exploits (even elementary ones like lpd were not fixed). Then
>in 4.x the stack had to go executable again. And then it became fun (actually I
>am slightly incorrect here because the fun officially began after some kid
>posted general purpose shellcode for alpha).

DGUX is a closed source operating system with a developer base
that is a tiny fraction of GNU's (all of the free unix clones) or
Linux's alone. For GNU systems, there are so many developers that
stack overflows will continue to get enough attention. For example,
there are already coordinated code auditing efforts underway in the
free software community.

More generally, I think you are making the engineer's mistake
of concentrating so much on the means that you are losing track of the
real objective. Fixing stack overflow bugs is a means toward
preventing stack overflow exploits. Unlike bugs which can be reliably
caught by compilers, stack overflow bugs continue to crop up and
apparently will continue to in the future, creating real security
problems until they are detected and fixed. This window of
vulnerability is almost always a much bigger problem than the harm
caused by it taking a little longer for somebody to notice the bug
that has basically been made harmless.

In general, the tradeoff is as follows.

In the current executable stack situtation, stack overflow
bugs are usually discovered after many breakins have occurred and
finally one is detected. Vendors often have to deal with the news on
an emergency basis, requiring engineers to drop what they are doing
and switch to dealing with putting out a patch, and then it still
takes a long time for most customers to decide to apply the patch, so
many sites continue to be vulnerable. In some cases, this may have to
be done when it is a particularly difficult time to put out a new
release of the software. This is a really high cost.

With a nonexecutable stack, some stack overflow bugs might
last longer before being detected, but they would be detected through
more methodical processes (such as in the course of code auditing or
maintenance), and the changes would be propagated through the regular
release processes of these software components. A lot of engineering
time would be saved.

>2. Trampolines:
> A: the few programs are f.e. glibc itself or docs on solar
>designer patches are wrong.

Do you mean glibc does this in a way that has not already been
addressed by the users of Solar Designer's patches? If so, I would
appreciate a pointer to more information on this. If this is just a
rarely used subroutine in glibc, it would be simple enough to
reprotect the stack the first time any subroutine that needs an
executable stack is called. Programs that did you use these
subroutines, presuamably most programs, would still be made more
secure.

>3. If at least solar designer's and andrew tridgel's patches (pipes in
>proc, etc) will finally make it into the mainstream kernel it will be very very
>nice.

I want to emphasize that I think we basically agree. The
discussion on your points #1 and #2 a question of whether these
patches would do a little good or a lot of good.

Adam J. Richter __ ______________ 4880 Stevens Creek Blvd, Suite 104
adam@yggdrasil.com \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."

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

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:2.015 / U:0.912 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site