Time to add strlcpy/strlcat FINALLY

["David A. Wheeler" <dwheeler at dwheeler dot com>]

I said:
> > So... would a high-quality strlcpy/strlcat patch be (FINALLY!) accepted?

On Wed, 13 Aug 2014 20:55:49 +0000, "Joseph S. Myers" <joseph@codesourcery.com> wrote:
> I think it would be reasonable to consider.

That's a start.

A common REPEATED complaint about glibc is that it fails to support strlcpy/strlcat and other functions like them to counter buffer overflows.  The lack of such functions has been *repeatedly* raised as a problem since 2000 and at least through 2012.  Currently people have to keep re-implementing them, but these tend to be slower since they're not optimized.

The general consensus of people who have *studied* how to develop secure software generally recommend strlcpy/strlcat, annex K, or either when dealing with statically-sized buffers in C.  A few examples:
* OpenBSD developers, esp. Todd C. Miller and Theo de Raadt, who CREATED strlcpy/strlcat and use it. Usenix paper here: http://www.openbsd.org/papers/strlcpy-paper.ps.  Some glibc people may not like Theo personally, but that is *not* a reason to reject their work.
* Robert Seacord (SEI), who wrote the book "Secure Coding in C and C++". e.g., http://www.informit.com/articles/article.aspx?p=2036582&seqNum=4
* Michael Howard (Microsoft), who co-authored the book "Writing Secure Code".  The list of "banned functions" (http://msdn.microsoft.com/en-us/library/bb288454.aspx) that are no longer permitted in Microsoft code include both strcpy and strncpy, because programs with many of them tend to have buffer overflows.  They recommend annex K, but also note strlcpy/strlcat as an honorable mention and useful alternatives.
* David A. Wheeler (me); you can blame me for "Secure Programming for Linux and Unix HOWTO" (http://www.dwheeler.com/secure-programs).
* John Viega and Matt Messier, who wrote "Secure Programming Cookbook for C and C++: Recipes for Cryptography ...", recommend strlcpy/strlcat as one possible approach (they even provide a sample implementation when your system doesn't include one).

It's true that "strlcpy/strlcat" don't prevent all buffer overruns.  So what?  No one said they did.  But they do reduce the likelihood.  If you use strlcat/strlcpy or strcpy_s/strcat_s incorrectly, the likely result is silent data truncation.  Not good, but it's way better than "grant total control over machine to attacker" that strcpy and strncpy provide.  People often fail to compute the length correctly in strncpy, which is one reason why it's not an effective countermeasure for buffer overflows.

Please don't tell me "just switch to dynamic buffers".  In many environments these are forbidden, and in many others they're not worth it or are not worth switching to.  We need mechanisms that are easily used, and can in some cases be easily switched to.

Many other measures don't really work.  Managed languages are great, but sometimes you need C or are modifying an existing program in C.  The -D_FORTIFY_SOURCE option can be helpful, but it only works when the compiler knows the size of the destination buffer (often it cannot figure that out, but you know it and can tell the compiler).  Mechanisms like electric fence or Address sanitizer (ASan) are nice, but their overheads make them impractical in many cases (if overhead didn't matter, why are you using C?).

--- David A. Wheeler