[3469] in cryptography@c2.net mail archive
Medium-term real fix for buffer overruns
daemon@ATHENA.MIT.EDU (John Gilmore)
Wed Oct 14 21:03:26 1998
To: "Steven M. Bellovin" <smb@research.att.com>
cc: "Arnold G. Reinhold" <reinhold@world.std.com>, decius@ninja.techwood.org,
cryptography@c2.net, gnu@toad.com
In-reply-to: <199810141422.KAA02263@smb.research.att.com>
Date: Wed, 14 Oct 1998 17:43:59 -0700
From: John Gilmore <gnu@toad.com>
> But you're certainly right that that's not the primary vulnerability in
> most general-purpose computer systems. What is? Hint: of the 12 CERT
> advisories this year, 9 describe buffer overflows. And next month is the
> 10th anniversary of the Internet Worm. Sigh.
The C language does not require security holes when buffers overflow.
It's the implementations that fall down on the job.
I'm looking for someone who'll build a version of GCC (EGCS) that
fully checks C pointers (making sure that they point within the object
whose address was originally taken to create the pointer). The ANSI C
standard was very carefully written to permit such checking, and fully
checked pointers have already been successfully implemented in C
interpreters like Saber C, which many people have run major
applications through for debugging.
This would likely involve doubling the size of pointers, which changes
the calling sequence on that architecture, so programs built this way
can't just be dropped into existing systems. Instead, the next step
is to rebuild the complete Linux system -- kernel as well as libraries
and userland -- using the new compiler. Finally (or along the way)
convince the Linux developer community to move to the new compiler
(and adopt any source code fixes required, e.g. to eliminate
dependencies on the size of pointers, or to fix overrun problems that
the new checking makes obvious). Any spare time can be used in
optimizing the code EGCS generates to create, increment, and dereference
the new bounds-checked pointers.
This approx 1-year project should completely eliminate buffer overrun
security holes in Linux. (You could still crash programs that
contained buffer overrun bugs, but you couldn't exploit them to break
security.) Other OS's (the *BSD's, or even proprietary OS's) could
adopt the new EGCS whenever they wanted to close all the buffer
overrun holes at once. Contrast this to the current
fix-each-program-as-holes-are-found approach.
Any qualified folks want to do this job (for pay)? I'm sure I can find
or make funding for it. Any readers want to contribute major funding?
I don't see any reason why we can't kick this problem once and for all.
John
