[CLUE-Tech] OT: C code security - what to look for?

[Dennis J Perkins]

On Sun, 2003-08-10 at 14:01, Bruce Ediger wrote:
> >   What kinds of problems should I watch for (I know about buffer
> >     overruns ... what else?)?
> 
> Look for a book "C Traps and Pitfalls" by Andrew Koenig.  It's a good
> read, and it has all the mistakes.
> 
> Kernighan and Pike's "The Practice of Programming" has some good stuff
> in it, too.
> 
> I think that not developing and rigorously following a personal coding
> standard (including indentation and braces style) causes a lot of
> problems.  If you do certain things by habit, you won't screw them up
> very often.  Since you're an OCaml type, you should consider writing C as
> "functional" as possible.
> 
> Avoid "Hungarian Notation".
> 
> >   What kinds of coding errors cause those problems?
> 
> Unfortunately the things that make C so interesting and so versatile:
> pointer arithmetic, complicated data structures and dynamic memory
> allocation.
> 
> >   What kinds of tools and procedures are most useful for evaluating
> >     the safety of my code?
> 
> Electric Fence malloc, Dmalloc (http://dmalloc.com/).  I recommend
> compiling and testing with both - they check different things.  Do
> branch coverage tests - I forget how to do this with GCC, but it can
> be done.  To get anywhere about 50% code coverage, you will have to
> write some pretty interesting test cases.
> 
> If you can, get a 2nd C compiler: Hanson and Frasiers's "lcc"
> (http://www.cs.princeton.edu/software/lcc/) is a good freebie.
> Use gcc for a while, then switch to lcc for a while.
> 
> Compile with all error warnings (for gcc "-Wall" at least, look at the
> "Warning Options" section of the gcc man page) turned on, every time
> you compile.  At least understand why the compiler warns about things.
> Some things just aren't fixable, or make your code look really stupid
> (i.e. putting "(void)" in front of all calls to fprintf()).  DO NOT
> fiddle with compiler flags to make a warning or an error message go
> away.
> 
> Compile and test on a different hardware architecture - SPARC, or Alpha or
> (heaven forbid!) HP's PA-RISC if you can.  Writing code on x86 hardware
> only can cause you to do dopey things - do silly casts, or assuming a
> particular structure member packing.
> 
> Write code so that you can put together unit test "harness" programs
> to exercize modules as thoroughly as possible without compiling and
> running a giant monolithic program.


I saw a book at Softpro on secure programming that probably covers some
programming mistakes, i.e., buffer overruns.