"Secure coding" audit checkers and Kerberos

[Russ Allbery]

Ken Raeburn <raeburn at MIT.EDU> writes:

> 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.

It sounds like one of the root problems is not so much what functions you
use as having a uniform error handling method.  Every approach requires
error handling.  If you find a general solution to error handling, then
you can take that out of the set of things you have to worry about, and
more options come into play (such as using asprintf/vasprintf everywhere
you have variable-length output instead of trying to decide on a static
buffer size).

Perhaps standardizing on an error handling strategy in all functions would
help?  Then you could do things such as using macros for common actions
that check errors and use goto to jump to a cleanup and exit label (sort
of an exception method implemented in C).

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>