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
