OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: Buffer Overflows
From: Crispin Cowan (crispinwirex.com)
Date: Thu Apr 27 2000 - 10:10:06 CDT

Jim Dennis wrote:

> > * be a HELL of a lot of work to build
>
> 1) Offer kernel support and an API
> 2) Implement a toolchain (compilers, linkers and libraries)
> that used this API.

I repeat, that's a hell of a lot of work.

> If done write it would be possible to port most existing
> apps with little or no effort.

That's funny. It's about 1 to 2 man-months of work just to cram all of a Linux
distro through StackGuard. Just *reading* all that code would take years.
Re-writing it to a new API would take many man-years. Re-writing it in a new
language would take man-decades.

> > Makes StackGuard look attractive, eh? :-)
>
> Crispin, I don't mean offense by this but I don't consider
> StackGuard a "solution." It is a workaround to a fundamental
> design flaw in the common UNIX kernel and toolchain implementations.

How would you characterize the difference between a "workaround" and a solution?

> I'm not sure but it might be better to re-implement most of the
> software that you've tested under StackGuard in Pike. It might
> offer roughly the same performance and benefits (and the
> process of porting it might actually dust some cruft off the
> involved code.

To quote the LIDS guys, you haven't been keeping up. We have recompiled ALL of
the code that comes with Red Hat Linux with StackGuard. It's not just a few test
programs, it is millions of lines of code. We've been running it in production on
our servers and workstations for years. The performance overhead is very close to
0. It is rather difficult to measure the performance overhead, and it is
impossible to notice the performance hit from using the machine.

Does it still sound like a "workaround"?

> (Have you looked at Pike? Have you done any performance comparisons
> of a Pike program vs the closest equivent C program with and w/o
> Stackguard?).

No, I haven't looked at Pike in particular, but I am familiar with a variety of
type-safe languages. Re-writing 10 million lines of code vs. re-compiling it is
an apples to oranges comparison. Think about re-writing the entire X Windows
system in Pike?

Let's guess that there are 10 million lines of code in the pile of stuff that
we've protected with StackGuard (basically, all of the user-land C and C++
programs that come with Red Hat Linux). Consider that the industry standard for a
good programmer is 4 lines of quality debugged code per day. Lets generously
multiply that by 10 because the programmer is re-writing the code in a new
language instead of writing code from scratch. That's 250,000 man-days, or 1000
man years of labor. StackGuard does the corresponding work in 1 man month.

> I'm not saying that people should avoid your package or approach
> for performance reasons.

Good. There are no performance reasons.
http://immunix.org/StackGuard/performance.html

> I am saying that this is more of a workaround
> than a solution. (A solution would be to fix the toolchain to
> make more robust code --- not glue in a canary and checks to see
> if the poor birdie has expired).

I think we did fix the toolchain to produce more robust code. StackGuard is a
hack to the code generator to produce failsafe code that fails safe under
particularly dire circumstances.

> As I say --- I really don't mean to give offense. That's just
> how I see it.

No offense taken. But I think that either you're not familiar with what we've
done with StackGuard, or you haven't really considered the enormous expense of
what you're proposing.

Crispin
-----
Crispin Cowan, CTO, WireX Communications, Inc. http://wirex.com
Free Hardened Linux Distribution: http://immunix.org
                  JOBS! http://immunix.org/jobs.html