From owner-freebsd-current Tue Nov 23 16:10:18 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 2FCF114D96 for ; Tue, 23 Nov 1999 16:10:14 -0800 (PST) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40331>; Wed, 24 Nov 1999 11:03:10 +1100 Content-return: prohibited Date: Wed, 24 Nov 1999 11:10:01 +1100 From: Peter Jeremy Subject: Re: FreeBSD security auditing project. In-reply-to: <199911232321.SAA03005@blackhelicopters.org> To: mwlucas@gltg.com Cc: current@FreeBSD.ORG Reply-To: peter.jeremy@alcatel.com.au Message-Id: <99Nov24.110310est.40331@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0pre3i Content-type: text/plain; charset=us-ascii References: <199911232321.SAA03005@blackhelicopters.org> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 1999-Nov-24 10:21:17 +1100, mwlucas@gltg.com wrote: >a) This is what an unsafe function call looks like Without checking a lot of the call context, it is very difficult to categorically state that a particular function call is safe or not. As an example, consider the following: foo(const char *ibuf, ...) { char buf[MYBUFSIZ]; ... strcpy(buf, ibuf); ... } In general, this call is unsafe because there's no apparent restriction on the size of ibuf, but in the particular program, it may be quite safe because the length of ibuf has been checked previously. In this case, it's probably safer to change the strcpy() to a strlcpy() or similar - the cost (and risk) of making the change is probably less than the cost of checking all the places where foo() is called. Now consider the case where `buf' is also passed as an argument - now you don't immediately know the length of either the source _or_ destination buffers. And the unsafe code may not be a function call at all. It's quite easy to have an off-by-one error when working with arrays. If you want to look at standard library functions used unsafely, I think there's a range you need to consider. At one end you have "virtually impossible to use safely" (ie [v][f]scanf("...%s..."), gets(), system() and popen()). At the other end, you have "fairly easy to use without introducing buffer overflows" (ie fgets(), [v]snprintf(), strlcpy()). The other string functions, [v]sprintf() and [v]sscanf("...%s...") fall somewhere in the middle. Note that the range does not extend to "can't be used unsafely" or even "difficult to use unsafely" (at least in C). >In fact, I'll go further: If someone can point out a reliable resource >on the Net for a) and b), I'll be happy to write up a first draft of >"The FreeBSD Security Audit for Beginners". I'm sure that any number >of programmers out there would be happy to review it for technical >accuracy before putting it into circulation. A good start would be to read the general `secure programming' information on the web and look for things that are being done differently. Aleph One posted a good summary in BUGTRAQ last December as Message-id: <19981217112144.B872@underground.org> Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message