"Secure coding" audit checkers and Kerberos

[Ken Raeburn]

On Oct 14, 2008, at 21:06, ghudson at MIT.EDU wrote:
> * Instead of using sprintf to convert an integral type into a string,
>  use snprintf with an 80-byte buffer.

If you want to make it explicit, define a macro that computes the size  
using LOG10_OF_256*nbytes, rounding up, adding in the extra bytes.   
Looks a bit more complicated, but not as arbitrary.  We could also  
trivially apply it to the maximum size of "long long", "size_t",  
"uintmax_t", etc., and use much less space on our current platforms.   
I think we already have something along these lines in one or two  
places; look for "log10".


> * We already have a mechanism to ensure that snprintf and asprintf
>  exist.  We do not currently have a mechanism to ensure that strlcpy
>  and strlcat exist, and we don't use those in our code base
>  currently.  We could add them if we decide we want to allow their
>  use, of course.

Actually, we require snprintf currently except on Windows; asprintf we  
can fudge easily enough.

I looked at some implementations of snprintf floating around, but they  
were pretty much all full implementations, not something cleverly (or  
not so cleverly) layered on top of the support already present in the  
OS, and that seemed a bit heavy-weight.  We could probably fudge it  
(open /dev/null, fprintf to it, check the returned length, if it's  
bigger than the supplied length allocate a temporary buffer, call  
sprintf); it's not very pretty and it imposes a performance penalty on  
the older platforms that don't have snprintf, but it's lighter-weight  
than carrying a full *printf implementation.

> * I haven't addressed the rand-type functions above.  Obviously, using
>  krb_c_random_* is ideal and we already do that in most places.  We
>  don't use random/lrand48/rand often and it's generally in a test
>  functions which may not have a krb5 context (although I haven't
>  checked).  I think I can just handle these on a case by case basis.

If we're using rand-type functions, consider whether reproducibility  
is desirable in those cases; that's a significant difference between  
them and the Yarrow-based PRNG we've got, the latter will get data  
from /dev/urandom and results won't be easily reproducible.

Ken