[lkml]   [2000]   [Jul]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Stopping buffer-overflow security exploits using page protection
On Sat, 29 Jul 2000, Gary Funck wrote:

> Oxy, excellent summary of the issues relating to the prevention
> of exploits, thanks.
> > 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?

Depends very much on the application. Can be 100% or more. It's actually
probably more of a hit than rewriting something in eg Perl or Python, as
those languages are designed around bounded arrays where in C it's an
afterthought. Oh, and in C, there's the whole issue of pointer aliasing
which means it's only a partial fix.

(C is a stupid language to write large applications in. The vast majority
of bugs in C programs simply don't exist in newer languages. For most of
the things people use computers for today, it's much more important that
something works well than that it work fast.)

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

Capabilities are a start. But this is an orthogonal problem. If someone
hacks just my account rather than root, to me it's just as bad, no?

"Love the dolphins," she advised him. "Write by W.A.S.T.E.."

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:57    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean