Re: [open-source] Re: Wish for 2002 ...

[Paul Eggert <eggert at twinsun dot com>]

> Date: Sat, 12 Jan 2002 00:45:46 +0200
> From: Valentin Nechayev <netch@iv.nn.kiev.ua>

> It can be even calculated why Paul Eggert printed the same this
> piece: it is most ugly in the whole code, and it is the code where
> strlcat() is used only for paranoia, not for real need.

I made no special attempt to find ugly code.  I simply did a text
search of OpenSSH_3.0.2p1 (egrep -n 'strlcpy|strlcat' `find * -type f
-print|sort`, to be precise) and reported the first use of
strlcpy/strlcat that I found, where the code was not obviously
questionable.  This just happened to be line 64 of auth-skey.c.

The obviously questionable uses of strlcpy/strlcat silently truncate
data, and this silent truncation could cause the code to misbehave.
For example, the very first use of strlcpy/strlcat (using the same
search algorithm as above) is in lines 138-139 of auth-krb4.c, as follows:

		strlcpy(phost, (char *)krb_get_phost(localhost),
		    sizeof(phost));

Now, phost is of size INST_SZ, which is 40 (on OpenBSD 2.9 at least; I
assume other krb4 implementations are similar).  So, if the Kerberos
ticket-granting instance name is 40 bytes or longer, this code
silently misbehaves.  Possibly this misbehavior can lead to a security
hole, and possibly not; I haven't checked.

I have not done an exhaustive search for problems with strlcpy/strlcat
in OpenSSH.  I've examined only their first use (where strlcpy is used
in a questionable way, and for all I know could be exploited by an
attacker), and on their first use that is not questionable (where the
strlcat calls are technically inferior to the standard alternatives).
However, my brief impression from briefly looking at the "egrep"
output is that these two examples are typical.  If so, OpenSSH
provides evidence against the use of strlcpy/strlcat.


> These functions were designed to be used in *real* world

They facilitate sloppy code.  They have little or no redeeming value.

True, there is a lot of sloppy code in the world -- but we don't have
to encourage more of it.