Re: Stopping buffer-overflow security exploits using page protection

From: Gary Funck (gary@Intrepid.Com)
Date: Sat Jul 29 2000 - 13:26:15 EST


Oxy, excellent summary of the issues relating to the prevention
of exploits, thanks.

On Jul 29, 12:49pm, Oliver Xymoron wrote:
> Subject: Re: Stopping buffer-overflow security exploits using page protect
> On Fri, 28 Jul 2000, Bruce Perens wrote:
>
> > Please see http://technocrat.net/964824712/ . Is there any good
> > reason that we can not run Linux executables with the execute permission
> > turned off, by default, on all stack and data pages? Wouldn't this stop
> > buffer-overflow security exploits that try to inject executable code onto
> > the stack or into function tables? i386 won't support it, but other
> > architectures do.
>
>
> The problem isn't Intel's fault or any OS's, it's a problem in the C
> language and compiler. There are 5 fixes:
>
> a) write safe code (which has so far proved hard)
> b) compile with bounds-checking (big performance hit)

What is the level of performance hit, using bounds-checking?

> c) compile with StackGuard, etc. (doesn't stop exploits that corrupt
> other locals)
> d) separate the return address stack from the automatic variable stack
> (ditto)
> e) use another language (performance)

Might there also be an 'alternate universe' where the damage caused
by exploit-induced loss of control could be reduced/limited?

Most of the demons that are exploited are the ones that run with root
privileges (otherwise, it just isn't much fun). Should mountd, or
talkd _really_ be allowed to stomp /bin/login, modify /etc/passwd,
etc.? Would finer-grained access control via ACL's and/or capabilities
be the way to go? Is there a Linux kernel "roadmap" that is taking
development in that direction? In other words, is there a plan for the
Linux kernel to support mechanisms that would eliminate most of the
dangerous aspects of exploits, even if the did occur?

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



This archive was generated by hypermail 2b29 : Mon Jul 31 2000 - 21:00:30 EST