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

[Bruce Ediger]

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