Re: Implement C11 annex K?

[Rich Felker <dalias at libc dot org>]

On Thu, Aug 14, 2014 at 06:53:51PM +0200, Andreas Schwab wrote:
> Rich Felker <dalias@libc.org> writes:
> 
> > On Thu, Aug 14, 2014 at 12:12:59PM +0200, Andreas Schwab wrote:
> >> Florian Weimer <fweimer@redhat.com> writes:
> >> 
> >> > On 08/14/2014 12:02 PM, Andreas Schwab wrote:
> >> >> Florian Weimer <fweimer@redhat.com> writes:
> >> >>
> >> >>> Here's a security bug which resulted from the incorrect use of strlcpy:
> >> >>>
> >> >>>    <http://www.samba.org/samba/security/CVE-2014-3560>
> >> >>>    <https://git.samba.org/?p=samba.git;a=commitdiff;h=e6a848630d>
> >> >>
> >> >> This only proves that strlcpy isn't any better at preventing security
> >> >> bugs.
> >> >
> >> > It also shows that there is a real cost to not providing strlcpy in glibc.
> >> 
> >> No, you got it backwards.  Had samba used the standard string functions
> >> it would have been "protected" by fortification.  Of course,
> >> fortification is just a workaround for sloppy programming anyway.
> >
> > Except that we don't have any control over what Samba does, much less
> > any control over what every single broken app out there does.
> 
> There's a lot of ways to screw things up.
> 
> > Unless you want to go audit them all, file bug reports, and work
> > through the fights with their maintainers to get them to fix things,
> > the practical way to improve security is to provide a correct,
> > fortify-compatible strlcpy/strlcat in glibc so that these bugs can be
> > caught automatically. That's something the glibc team _can_ actually
> > do.
> 
> What is really neded is a high-performance, high-level string library.
> Something of the expressiveness of std::string.  Then kludges like
> strlcpy wouldn't be needed.

I disagree strongly here. If you want that, you should be using a
language where it's idiomatic. Doing it in C just gets you the worst
of both worlds: (1) C's lack of syntax to express it concisely and
lack of exceptions to handle allocation failures, which are a horrible
pain to handle when they can happen at each operation rather than at
isolated resource-allocation points, and (2) the HLL style loss of
fail-safety (all operations can fail because they do allocation under
the hood), massive overhead in memory usage and memory fragmentation,
load on malloc/free, etc.

The right way to solve this problem is either not to use C, or to use
the tools you have in C (mainly, snprintf) to make string handling
safe while not sacrificing the only values C has: efficiency and
fail-safety in the form of the ability to control where and when you
do allocation and write functions that don't depend on allocation.

Rich