Date: Wed, 24 Nov 1999 11:10:01 +1100 From: Peter Jeremy <jeremyp@gsmx07.alcatel.com.au> To: mwlucas@gltg.com Cc: current@FreeBSD.ORG Subject: Re: FreeBSD security auditing project. Message-ID: <99Nov24.110310est.40331@border.alcanet.com.au> In-Reply-To: <199911232321.SAA03005@blackhelicopters.org> References: <Pine.BSF.4.21.9911231407200.46173-100000@hub.freebsd.org> <199911232321.SAA03005@blackhelicopters.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <aleph1@UNDERGROUND.ORG> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?99Nov24.110310est.40331>