From owner-freebsd-security  Wed Aug 28 01:06:37 1996
Return-Path: owner-security
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id BAA10810
          for security-outgoing; Wed, 28 Aug 1996 01:06:37 -0700 (PDT)
Received: from salsa.gv.ssi1.com (salsa.gv.ssi1.com [146.252.44.194])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id BAA10796
          for <security@FreeBSD.org>; Wed, 28 Aug 1996 01:06:34 -0700 (PDT)
Received: (from gdonl@localhost) by salsa.gv.ssi1.com (8.7.5/8.7.3) id BAA00284; Wed, 28 Aug 1996 01:06:05 -0700 (PDT)
From: Don Lewis <Don.Lewis@tsc.tdk.com>
Message-Id: <199608280806.BAA00284@salsa.gv.ssi1.com>
Date: Wed, 28 Aug 1996 01:06:04 -0700
In-Reply-To: Zach Heilig <zach@blizzard.gaffaneys.com>
       "Re: Vulnerability in the Xt library (fwd)" (Aug 28,  2:08am)
X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95)
To: Zach Heilig <zach@blizzard.gaffaneys.com>,
        newton@communica.com.au (Mark Newton)
Subject: Re: Vulnerability in the Xt library (fwd)
Cc: gene@starkhome.cs.sunysb.edu, security@FreeBSD.org
Sender: owner-security@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk

On Aug 28,  2:08am, Zach Heilig wrote:
} Subject: Re: Vulnerability in the Xt library (fwd)
} newton@communica.com.au (Mark Newton) writes:
} 
} > Zach Heilig wrote:
} 
} > Really, strcpy isn't all such a program would need to look for.
} > There are many C library routines which perform no bounds checking
} > (sprintf(), gets(), strcpy() to name a few) and, even worse, there
} > are countless home-grown memory to memory copy routines which have
} > been written in ignorance of the possible consequences of poor range
} > checking and the assumption that if a buffer overflows the program
} > will crash and it's the stupid user's own fault.  Essentially, your
} > rebadged "lint" would end up attempting to be a program which tests
} > the "correctness" of code, and if you can write one of them then I
} > suspect you'll end up richer than Bill Gates :-)
} 
} Actually, you can get away a bit cheaper than that.  The compiler
} could simply complain if a block of memory were passed to a function
} without first checking its length.  There are ways to subvert this
} method, but a utility like that should catch most such errors.
} 
} If I can find my notes, I've come up with a way to do range checking,
} without stepping on the programmers toes too badly (though it would
} have a noticeable impact on performance).  The basic idea is to keep a
} table of all the blocks of memory in a program (the beginning and
} ending addresses), and check to make sure that all pointers are within
} one of these blocks whenever they are changed (pointers are usually
} changed less often than they are dereferenced).

This has already been done as an addon to gcc.  Check out:
	ftp://dse.doc.ic.ac.uk/pub/misc/bcc

			---  Truck