"Secure coding" audit checkers and Kerberos

Ken Raeburn raeburn at MIT.EDU
Tue Oct 14 22:25:49 EDT 2008

On Oct 14, 2008, at 21:47, Luke Howard wrote:
>> * Instead of strcpy or strcat, use memcpy.  Remember to ensure that
>> the string is terminated if you are not copying a terminator.
> What about using strlcpy/strlcat (providing implementations for
> platforms that don't support them).

And then check for truncation, and add error paths or abort calls?  As  
Greg said, silent truncation can lead to security problems just as  
buffer overruns can.  If we skip the truncation tests on the grounds  
that we've verified the code is consistent and correct in its use of  
lengths, then either we can just use memcpy, or we're not *that*  
confident of our checks and should keep the truncation tests.  If we  
put in the tests, now we need error recovery for more than just failed  
allocation, or we have "assert" or "abort" calls littered through the  
code, which some coding standards would regard as rather ugly.

Personally, my preference is to use small building blocks that can be  
verified to be correct, and build on them.  The "strdup" function is  
an obvious example, which we already use in a lot of places;  
"asprintf"/"vasprintf" are hairier (to implement and verify) but also  
valid examples.  I haven't looked at many of the examples, but there  
are probably other simple things that could be implemented as helper  
functions, like "copy out krb5_data contents into a null-terminated C  
string, but (... do something) if there's a null byte in the content".

The GSS buffer handling is another issue; we've had a bunch of cases  
in the past where code used "%s" to print the buffer contents,  
ignoring the fact that the GSS-API C bindings don't guarantee null  
termination of strings stored in buffer handles, but "%.*s" can supply  
the length (when appropriately cast, after range checking) and pointer  
data together so as to avoid overrunning the buffer.  (Should check on  
this: I'm not certain *printf are required not to read past N bytes,  
though they are required not to output more than that.)


More information about the krbdev mailing list