From owner-freebsd-current Tue Nov 23 15:20: 9 1999 Delivered-To: freebsd-current@freebsd.org Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id D90B21540D; Tue, 23 Nov 1999 15:19:52 -0800 (PST) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40341>; Wed, 24 Nov 1999 10:12:50 +1100 Content-return: prohibited Date: Wed, 24 Nov 1999 10:19:37 +1100 From: Peter Jeremy Subject: Re: FreeBSD security auditing project. In-reply-to: <19991123142626.D49964@dragon.nuxi.com> To: David O'Brien Cc: current@FreeBSD.ORG Reply-To: peter.jeremy@alcatel.com.au Message-Id: <99Nov24.101250est.40341@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0pre3i Content-type: text/plain; charset=us-ascii References: <99Nov24.075703est.40331@border.alcanet.com.au> <19991123142626.D49964@dragon.nuxi.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 1999-Nov-24 09:26:26 +1100, David O'Brien wrote: >> > A 'grep | wc' equivalent over the source tree gives: >> > >> > gets 110 >> > strcat 2860 >> > strcpy 4717 >> > strncat 167 >> > strncpy 1514 >> > sprintf 6839 >> > vsprintf 133 >> >> *ouch* :-) > >This means nothing out of context. I hope we don't go on a witch hunt. Agreed. I wasn't suggesting that all these occurrences are examples of unsafe use. They just give an order-of-magnitude indication of the number of places they are used. That said, I'm not sure that going through the code and checking every call to strcpy() (for example) is the right way to go about things. It _is_ possible to use strcpy() safely, at the same time, it is possible to use strlcpy() or snprintf() _unsafely_ (mainly mis- interpreting the return value when the result is larger than the destination buffer). In any case, you still miss the case where someone has implemented their own string copy function and is using it incorrectly. I believe the correct way is a line-by-line audit of all the code, checking for the various security problems. One thing that would help with this task is a list of code patterns that indicate security problems. This list will make it easier for auditors (and will expand over time). I suspect that a 'cvs diff' of the OpenBSD code tree is the best starting point. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message