"Secure coding" audit checkers and Kerberos
raeburn at MIT.EDU
Tue Oct 14 22:59:39 EDT 2008
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.
More information about the krbdev