[31232] in bugtraq
Re: Buffer overflow prevention
daemon@ATHENA.MIT.EDU (Tom 7)
Fri Aug 15 17:46:49 2003
Date: Fri, 15 Aug 2003 14:41:10 -0400 (EDT)
From: Tom 7 <twm@andrew.cmu.edu>
To: bugtraq@securityfocus.com
In-Reply-To: <1060942458.5313.ezmlm@securityfocus.com>
Message-ID: <Pine.LNX.4.55L-032.0308151422380.12432@unix48.andrew.cmu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Crispin Cowan <crispin@immunix.com> wrote:
> Array bounds checking offers greater protection than any of these
> protections (StackGuard, ProPolice, PointGuard, W^X, PAX/ASLR, etc.) The
> problem is that the very fastest array bounds protection for C (Bounded
> Pointers) imposes a 5X slowdown on performance, where as these other
> techniques impose overheat somewhere between noise and 20%.
This may be true. Doing "safe" pointers in C is difficult because of
pointer arithmetic. But I think this is a bit unfair to bounds checking in
general--type safe compiled languages like ML achieve array bounds
checking (and other checks) at a much smaller penalty (less than 20% for
array-oriented code in my experience). These languages also provide
protection against other common sources of holes, like integer overflow,
double-frees (most are garbage collected) and printf formatting attacks.
This protection is automatic and absolute; the only thing left to worry
about is bugs in the compiler, system library, and kernel (things that C
programmers already need to worry about, anyway).
In my opinion these languages are utterly practical for Unix network
daemons. Of course, this is a bit more work because you don't just
recompile the program, you have to rewrite it from scratch! But there are
other benefits to maintaining code in a modern, safe, high-level language.
- Tom
[ http://www.cs.cmu.edu/~tom7/ ]
