Hi all,
I've played around a bit with C vulnerability checkers today, and ran a
few on them on the classpath code base, so I figured I'd tell you how to
it, too.
The first one I tried was pscan [1], which checks for format string
vulnerabilities. I've fixed all the pscan warnings today.
Running pscan is easy:
In the classpath directory, run
find . -name "*.[ch]" | xargs pscan
there should be no output now. ;)
The next one I looked at was flawfinder [2], which checks for general
potential security issues. It quantifies them in classes, according to
potential for mischief. 5 is the highest category, 0 the lowest.
In the classpath source directory, running
flawfinder .
results in a lot of output about potential security problems.
Next I fired up rats[3], which checks for similar problems that
flawfinder covers as well. It returned similar results, too, though
ordered by potentially vulnerable C function, which would make it easier
to fix all the issues at once.
To run rats, in the classpath source directory run
rats .
Finally, I ran splint[4]. Split is a static C checker. It produces
massive loads of output, and has some trouble parsing gcc-specific code,
which is why it breaks trying to analyze headers included from gtk,
java-net, etc. It also has trouble with C++ code, so I left the qt peers
out. I've ended up invoking it like this:
find native/jni/classpath/ native/jni/java-io/ native/jni/java-nio/
native/jni/java-util/ native/jni/xmlj/ -name "*.[ch]" | xargs splint
+posixlib -fileextensions -badflag -I include/
-I ../build-classpath/include/ -I native/jni/classpath/ -I
native/fdlibm/ -I /usr/include/gtk-2.0/ -I /usr/include/pango-1.0/
-I /usr/include/glib-2.0/ -I /usr/include/cairo/ -I native/jni/gtk-peer/
-I /usr/include/freetype2/ -I native/target/Linux/ -I
native/target/generic/ -D__i386__ -I /usr/include/libxml2/
-I /usr/include/ -weak
I'd say that pscan is fun to use to find format issues, flawfinder &
rats are both nice for finding places to audit, and splint is gcc
-WAnalyzeDeeply.
All the tools are pretty fast, and can analyze the code in less than a
minute. A quick scan of the results shows that splint detects some type
mismatch issues, and cases where we ignore the return values of
functions. Some of those are a little odd, for example it is not clear
to me what to do if JNI function call ThrowNew fails. rats and
flawfinder mostly ruffle their noses over the use *printf class of
functions without approriate protection, string manipulation functions,
and similar potential issues.
I'll be back at fixing the normal gcc warnings on Kaffe's code base, but
if someone wants to go ahead from here with a full scale security audit
of the C code, I hope this e-mail helps them get started.
cheers,
dalibor topic
[1] http://www.striker.ottawa.on.ca/~aland/pscan/
[2] http://www.dwheeler.com/flawfinder/
[3] http://www.securesw.com/rats
[4] http://splint.org
