- 2010.07.08 18:03 "Re: [Tiff] strlcpy vs strncpy", by Lee Howard
-
2010.07.08 18:06 "Re: [Tiff] strlcpy vs strncpy", by Olivier Paquet
- 2010.07.11 17:36 "Re: [Tiff] strlcpy vs strncpy", by Edward Lam
-
2010.08.06 18:21 "Re: [Tiff] tiff4 on 32-bit Windows", by Toby Thain
-
2010.08.06 15:05 "[Tiff] tiff4 on 32-bit Windows", by John
- 2010.08.06 15:21 "Re: [Tiff] tiff4 on 32-bit Windows", by Bob Friesenhahn
- 2010.08.06 15:37 "Re: [Tiff] tiff4 on 32-bit Windows", by Olivier Paquet
- 2010.08.07 06:34 "[Tiff] tiffcp crashes on planar to strip conversion for < 8 bit", by Andreas Kleinert
-
2010.08.06 15:05 "[Tiff] tiff4 on 32-bit Windows", by John
- 2010.07.10 11:04 "Re: [Tiff] strlcpy vs strncpy", by Albert Cahalan
- 2010.07.12 17:34 "Re: [Tiff] strlcpy vs strncpy", by Dmitry V. Levin
- 2010.08.02 19:47 "Re: [Tiff] BigTIFF Support in LibTiff", by Gajera Tejas
- 2010.08.19 17:18 "[Tiff] tiff2ps page sizing options", by Richard Nolde
2010.07.11 08:18 "Re: [Tiff] strlcpy vs strncpy", by Albert Cahalan
On Sat, Jul 10, 2010 at 9:39 AM, Bob Friesenhahn
<bfriesen@simple.dallas.tx.us> wrote:
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.
I tend to agree except for the fact that strlcpy() does absolutely assure null termination, even if the programmer made an error.
Uh oh. You have failed to consider the case of a zero-sized buffer. If your strlcpy overflows with a NUL byte, then it may corrupt a function pointer. If it doesn't, but you rely on getting a NUL byte, your app code may leak data by read-overflowing as the 0-byte "string" gets copied elsewhere.
GraphicsMagick-1.3.12 has two strlcpy implementations that I could find. Both use assert for this case, which is not what strlcpy is supposed to do. Also you are either paying the cost of compiling code with assertions enabled or you are running without them and being subject to having things possibly depend on input that an attacker might control.
If compiled without assertions, your strlcpy seems to turn into strcpy when size is 0. You underflow from 0 to 0xffffffff or 0xffffffffffffffff for the right side of the (length < size-1) comparison.