2010.07.10 13:27 "Re: [Tiff] strlcpy vs strncpy", by Kevin Myers

Actually the fact that strncpy zero fills the remainder of the array strongly suggests that it *was* intended to be used exactly as many people are (mis)using it. Zero filling the array automatically adds a null terminator, except in the case when string length = buffer length. If you did't want to automatically add a null terminator, then why zero fill the array???

With regard to strlcpy truncating the string, how can that possibly cause a security problem??? I don't see that at all. Seems like strlcpy is doing *exactly* what strcpy should have been doing for all these years to prevent buffer overfllows and assure that the string length does not exceed the buffer length. Is truncating the string with no indication that truncation has occured a (non-security) flaw? Perhaps, but not when serving as an essentially drop-in replacement for strcpy or strncpy in existing code. Having a truncation test would only be useful if you also add additional application code to decide what to do in the event that truncation was detected, which would definitely make for a non-drop-in replacement.

I tend to agree regarding the use of standard implementations rather than rolling your own whenever possible. However, Bob F. is well versed in portability issues because of his support for GraphicsMagick on multiple platforms. If he thinks there are enough compilers in widespread use that don't support strlcpy to justify rolling his own, then he may be right. Bob is also a very good programmer, so I suspect that his implementation would be quite good, and in any event it would be available for subsequent review, verification, and correction/optimization if necessary. But, couldn't this kind of thing (roll-your-own vs. standard implmentation) be handled by autoconf or something like that?

My 2 cents worth.

s/KAM

On Thu, Jul 8, 2010 at 12:25 PM, Bob Friesenhahn

I see that libtiff is using strncpy() as a safer strcpy() and

> strncat() as a safer strcat(). Unfortunately, strncpy() does include

a significant design flaw which causes it still to be insecure unless additional care is taken. occurs when the string to be The problem

copied exactly matches the buffer size, in which case the string will lack null termination.

That isn't a design flaw. You could argue that strncpy is a badly chosen name perhaps. The intended use is for character arrays, such as the one in wtmp and utmp files, which are not really strings in the normal C sense. Note how strncpy also zero-fills the remainder of the array; this behavior only makes sense for the intended purpose.

So strncpy isn't intended to do what you likely want, but strlcpy really does have a design flaw. It truncates the string. This can cause a security problem. To deal with that you'd need to check length and compare... but if you're going to do that then you've already written as much code as you'd need to write for doing things the standard and portable way: memcpy. Yep, that's right, memcpy is in <string.h> for a reason.

GraphicsMagick is using strlcpy() and strlcat() for secure string copies. be happy to contribute versions that I wrote myself I will

Many decent programmers have botched reimplementations of various str* and mem* functions. You might need two hands to count the number of tries it took to get strncpy right in the Linux kernel. Sun shipped a libc that got these functions wrong when crossing a page boundry. Well-optimized code often has failures with bytes 0x7f, 0x80, and/or 0xff.

You can expect a modern compiler and C library to cooperate to provide a regression-tested implementation of str* and mem* functions that takes full advantage of the hardware. (aware of cache lines, aliasing issues, special-purpose instructions, etc.) I strongly suggest using what the platform provides rather than writing your own.