Re: WuFTPD: Providing *remote* root since at least1994

[kragen () POBOX COM (Kragen Sitaker)]

Hudin Lucian writes:
> Actually many people blame sprintf usage as a potential source
> for buffer overflow exploits, yet :
>
> char buff[BUFSIZ];
> sprintf(buff, "%.*s", BUFSIZ, "string");
>
> avoids the overflow ... IMHO it's very easy to avoid buffer overflows when
> writing critical programs just by keeping in mind the 5th of "the ten C
> commandments" . . .

If your sprintf format string is merely "%.*s", then yes, it's easy to
avoid an overflow.  The problem is when your sprintf format string is
something like "%d:%d:%d: problem at %.20s with %.20s: %d".  Figuring
out how many characters the output can consume is error-prone, even if
you use %.20d instead of %d.  (And, 32-bitters, don't think %d can't
expand to more than 11 characters.  On an Alpha . . .)

The use of sprintf above can be better accomplished by Todd Miller's
strlcpy (or, on systems that don't have it, by writing your own
function).  strlcpy --- and, even more, strlcat --- have the advantage
that they make it fairly easy to determine whether you have just
truncated your string, which can, in itself, be a source of security
holes.

Simple, portable, audited, well-tested implementations of strlcpy and
strlcat, under a BSD license, are available from
ftp://ftp.openbsd.org/pub/OpenBSD/src/lib/libc/string/.  Theo de Raadt
posted a portable, audited, well-tested implementation of snprintf to
BUGTRAQ in 1997; unfortunately, his link to
http://theos.org/~deraadt/snprintf.c is now broken.

Today, there is no excuse for using strcpy or strcat in preference to
strlcpy or strlcat in code handling untrusted data in security-critical
software.

Any slightly prudent person aware of the dangers of buffer overflows
and the existence of strlcpy and strlcat would use them in preference
to using strcpy and strcat in multiple places, when handling untrusted
data in security-critical software, in order to avoid injury to those
who rely on the software.

Any person not aware of the dangers of buffer overflows and the
existence of strlcpy and strlcat is not competent to write
security-critical software in C or C++, and in order to avoid injury to
those who rely on the software, even slight prudence would require them
to refuse to attempt to do so, unless they were deluded into thinking
they were competent to do so.

Any slightly prudent person aware of the dangers of buffer overflows
and the existence of strlcpy and strlcat would refuse to employ
software using strcpy or strcat in multiple places to handle untrusted
data in a security-critical role, unless they believed that someone
else competent had already verified that the software was at least
slightly safe for such use and therefore did not bother to so verify
themselves, in order to avoid injury to those who would be exposed to
injury from the software's vulnerabilities.

Any person not aware of the dangers of buffer overflows and the
existence of strlcpy and strlcat is not competent to determine whether
software written in C or C++ is safe to employ in a security-critical
role.  Unless they are deluded into thinking they are competent to so
determine, or believed that someone else so competent had verified that
the software was at least slightly safe for such use, even slight
prudence would require them not to decide to employ such software in a
security-critical role.

Likewise for snprintf versus sprintf.

A reasonable case could be made that using strncpy and strncat instead
constitutes reasonable prudence, but strlcpy and strlcat are safer (you
can easily verify that you didn't truncate the string when using
them) and more efficient.  A reasonable case could also be made for
using your own home-brewed functions which checked the length, in which
case you could reasonably call strcpy and strcat in one place each.
And there are probably a few cases where strlcpy is too slow, and must
be replaced with strcpy to meet performance requirements; strcpy is
typically a highly-optimized assembly routine that copies data several
bytes at a time if possible.

Does anyone disagree with the above statements?  Please send me email.

I think criminal liability should attach to the folks who injure others
by such gross negligence.  I think that the law in most of the U.S.
allows at least civil liability.

--
<kragen () pobox com>       Kragen Sitaker     <http://www.pobox.com/~kragen/>
The Internet stock bubble didn't burst on 1999-11-08.  Hurrah!
<URL:http://www.pobox.com/~kragen/bubble.html>
The power didn't go out on 2000-01-01 either.  :)