Re: [PATCH] Implement strlcpy, strlcat [BZ #178]

[Florian Weimer <fweimer at redhat dot com>]

On 05/20/2016 07:21 PM, Paul Eggert wrote:
> Two thoughts.
>
> First, the September 2014 thread motivated strlcpy/strlcat in part by
> saying that Fedora has over 60 packages which define strlcpy/strlcat[1],
> the implication being that moving strlcpy/strlcat into glibc would fix
> more bugs than it would cause and would be worth the effort's cost.
> Skeptics like me can reasonably counter that the effort would likely
> just be security theater, in that it would not be of any real help but
> would merely exhibit activity in the security area, and possibly would
> even cause more problems than it fixes.

I'm not sure if it is possible to easily quantify the security benefits 
that strlcpy/strlcat bring.  Any project we start in this area would 
prevent us from working directly on glibc improvements, due to the 
resource constraints we face.

Back in 2014, I at least wasn't aware how widely strlcpy had been 
adopted by libcs.  Since then, I have done some research, and all Linux 
libcs I know of except glibc provide it, but it's available well beyond 
that:

  https://sourceware.org/glibc/wiki/strlcpy

The major omissions are glibc and MSVC.  Most of the other libcs in the 
ânoâ camp are legacy implementations to various degrees.

The compatibility doubts raised in 2015/earlier this year do not appear 
as significant as we assumed.

> Data could help assuage skeptics' concerns. Although it's impossible to
> count bugs that are not discovered yet, we *do* now have twenty months'
> worth of data since September 2014. So: how many user-visible bugs
> and/or vulnerabilities have been discovered or reported in these 60-odd
> Fedora packages, bugs that would have been prevented by moving
> strlcpy/strlcat into a better-maintained library?

At present, Fedora deliberately does not use libbsd widely (we 
eliminated the dependency from the Samba packages, for instance).  As a 
result, the data you are asking for is scattered across the entire 
distribution.  I don't know a good way to obtain it.

> Second, the September 2014 thread said that another way to fortify
> strlcpy/strlcat, assuming we still want to do it, would be to use
> libbsd's strlcpy/strlcat implementation and add fortification to it.
> However, it was argued that this would be a Fedora-only effort and that
> libbsd contains functions like fgetln that are awkward. But isn't the
> point of libbsd to provide BSD functions that are awkward or
> questionable from the glibc point of view?

fgetln is not questionable at all by itself (except when reading lines 
from a read-only mapping or in-memory source, so that the non-const 
return value is incorrect).  Its awkwardness is the result of the 
implementation in libbsd, on top of stdio interface (and not libio 
internals).

Once we have a clear picture of the vtable/ABI situation of libio, we 
can implement fgetln in glibc quite easily (with the caveat that writing 
to the returned buffer may not be allowed, depending on the underlying 
stream, but the BSDs have the same problem).  But that's a separate 
discussion.

> And I don't see how work in
> libbsd would be Fedora-only, as other distributions like Debian also use
> libbsd, and whatever methods Fedora uses to merge strlcpy/strlcat into
> string.h would be methods that other distributions could use as well.

I might be misremembering things, but I think back in 2014, libbsd 
maintainership in Debian languished a bit, and the upstream situation 
was rather unclear.

> The Fedora bug report that corresponds to strlcpy/strlcat
> fortification[2] says that this is "Priority low Severity low", and from
> the above it appears that this is mainly a packaging problem instead of
> being a necessary addition to the core libc API.

We did not invest in libbsd development because the right place to offer 
widely-implemented libc APIs in Fedora is glibc.

Florian