Secure Coding mailing list archives
Re: New Microsoft Security Tool for developers
From: "Dana Epp" <dana () vulscan com>
Date: Tue, 16 Dec 2003 01:10:08 +0000
I cannot find supporting documentation for the claim "and nullify the rest of the buffer of dest". IIRC, strncpy will copy a null byte from src to dst, but it does not nullify the rest of dst.
Hey Crispin, This would be dependant on the implimentation of strncpy. For most implementations on Unix it will indeed copy null chars in the rest of the buffer up the size requested. Doing a 'man strncpy' gives me this in the description: DESCRIPTION `strncpy' copies not more than LENGTH characters from the the string pointed to by SRC (including the terminating null character) to the array pointed to by DST. If the string pointed to by SRC is shorter than LENGTH characters, null characters are appended to the destination array until a total of LENGTH characters have been written. Looking at MSDN, Microsoft's implimentation states: The strncpy function copies the initial count characters of strSource to strDest and returns strDest. If count is less than or equal to the length of strSource, a null character is not appended automatically to the copied string. If count is greater than the length of strSource, the destination string is padded with null characters up to length count. As such, it will clean out the buffer correctly. However, if there is a concern, doing a quick memset will give you that assurance you would like. Your point about the fact it can copy without the NULL is correct if the max size and size match, which is why in my example last week I set the last byte in the array to NULL BEFORE the actual call to strncpy. In this way, you can tell if you are trampling the memory with a potential overflow or not, and can ensure that there is no use of an unterminated string... leading to the information leakage observation you pointed out. Although in this particual case it may be desired to have exactly that effect (a string without a terminating null) it is typically better to have a sentry like what I suggested and check the return code SPECIFICALLY so you don't use puts/printfs and the like when you have a string that doesn't conform to your wishes. Loved your hamlet-like quote. Tis so true. Made me laugh. :) --- Regards, Dana M. Epp [Blog: http://silverstr.ufies.org/blog/]
Current thread:
- RE: New Microsoft Security Tool for developers, (continued)
- RE: New Microsoft Security Tool for developers Tegels, Kent (Dec 09)
- RE: New Microsoft Security Tool for developers Lewis, Todd (Dec 12)
- RE: New Microsoft Security Tool for developers Chris Richards (Dec 12)
- Re: New Microsoft Security Tool for developers der Mouse (Dec 13)
- RE: New Microsoft Security Tool for developers Gene Spafford (Dec 13)
- Re: New Microsoft Security Tool for developers Mark Graff (Dec 13)
- RE: New Microsoft Security Tool for developers Jannie Hanekom (Dec 14)
- Re: New Microsoft Security Tool for developers der Mouse (Dec 15)
- Re: New Microsoft Security Tool for developers Dana Epp (Dec 15)
- Re: New Microsoft Security Tool for developers Crispin Cowan (Dec 15)
- Re: New Microsoft Security Tool for developers Dana Epp (Dec 15)
- RE: New Microsoft Security Tool for developers Örjan Petersson (Dec 16)
- strncpy (was: Re: New Microsoft Security Tool for developers) David A. Wheeler (Dec 16)
- Re: strncpy (was: Re: New Microsoft Security Tool for developers) Florian Weimer (Dec 17)
- Re: New Microsoft Security Tool for developers Dave Aronson (Dec 15)
- Re: New Microsoft Security Tool for developers Gene Spafford (Dec 17)
- Re: New Microsoft Security Tool for developers Mikey (Dec 17)