Messages in this thread | | | From | "Adam J. Richter" <> | Date | Tue, 28 Dec 1999 11:54:33 -0800 | Subject | Re: 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/
| |