LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
July 2010
Previous Thread
Next Thread
Previous by Thread
Next by Thread
Previous by Date
Next by Date
Contact
The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems
Thread
2010.07.11 07:34 "Re: strlcpy vs strncpy", by Albert Cahalan
On Sat, Jul 10, 2010 at 9:27 AM, Kevin Myers <KevinMyers@austin.rr.com> wrote: > 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??? In times past, it was common to have text stored in a fixed-size place, padded out with NUL bytes, and no expectation that there would be a NUL at the end. I know this seems strange today. Perhaps it is for compatibility with some long-forgotten non-C language. Requiring a NUL byte would increase the size of a record, so maybe people were just trying to save space in a world where fixed-size records were the norm yet every byte was precious. > With regard to strlcpy truncating the string, how can that possibly cause a > security problem??? There are plenty of ways. Perhaps code later checks the new length, then ends up filling it with the old (longer) data. Perhaps the allocation is zero bytes, strlcpy thus fails to write the NUL byte, and ultimately you leak private data. Perhaps the allocation is zero bytes, strlcpy is buggy (wrongly writing the NUL byte), and a function pointer is trashed. There is more to security than buffer overflows of course; perhaps you turn filename.exe.tif into filename.exe when you truncate. Perhaps the truncation removes a closing quote or comment mark, leading to some critical script or config data being swallowed up. > 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 I'm not sure strcpy ever had a legitimate purpose. Use memcpy. Either you know the length (you can use memcpy) or you don't know the length (you have a bug, truncation or otherwise). > 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. I think Linux and Windows are in widespread use. :-) You can find strlcpy on *BSD and I think on recent Solaris. It has been rejected by the glibc maintainer.