OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Buffer Overflows and DoS
From: Crispin Cowan (crispinwirex.com)
Date: Wed Apr 26 2000 - 23:34:00 CDT

Horst von Brand wrote:

> Crispin Cowan <crispinwirex.com> said:
> > Buffer overflows are largely a result of:
> > * the C idiom of null-terminated strings
> I got the same results in FORTRAN and Pascal just by wandering off the end
> of arrays...

Sure, but you have to work harder to get those kinds of bugs in FORTRASH^H^H N and
Pascal. To be really safe, you need a type-safe language that does bounds
checking. The C null-termination idiom just aggrevates the problem.

Note that Bernstein has also implemented a strings library that dumps the C
null-termination idiom in favor of a base+bounds idiom. He (correctly) feels that
this idiom is less vulnerable to potential buffer overflow attacks.

> > * the unfortunate coincidence that stacks grow down and strings grow up
> It is certainly possible to smash a upward-growing stack. Just use a buffer
> in one of the functions in the call chain instead of a local buffer.

Correct. But it's harder to craft such an attack.

> > * the wide spread use of poorly typed languages that don't do strong array
> > bounds checking
>
> Array bounds checking is quite costly (some 3 or 4 extra instructions for
> the 1 instruction doing the access on the fast path). Most Pascal compilers
> (the language specifies array bounds checking for each access!) I know had
> a flag to turn it off, just because of this.

I agree. That's why we feel that StackGuard has long-term viability. Function
call returns are far less frequent than array references, so StackGuard's overhead
will always be lower than bounds checking.

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