John Viega posted the following message to bugtraq announcing a new security auditing tool. "I've put together a command-line tool for statically scanning C and C++ source code for security vulnerabilities. The tool is . . .
John Viega posted the following message to bugtraq announcing a new security auditing tool. "I've put together a command-line tool for statically scanning C and C++ source code for security vulnerabilities. The tool is called ITS4. ITS4 scans through source code for potentially dangerous function calls that are stored in a database. Anything that is in the database gets flagged. ITS4 tries to automate a lot of the grepping usually done by hand when performing security audits.

The tool is available from:
Also on this site is a research paper on ITS4 submitted to this year's
Usenix Security conference.

ITS4 is open source software. The license puts some minor
restrictions on commercial use. In essence, you can't use this tool
to make money (such as by reselling it, or by using it in a consulting
practice). However, you are encouraged to run the tool on your own
product in order to make it better.

ITS4 does more than just grep-type work. It allows for arbitrary
handlers to refine the initial analysis. This version of ITS4 comes
with some simple handlers. Some of these handlers check for uses of
common string operations that often are not significant problems. For
example:

strcpy(buf, "\n");
sprintf(buf, "%d", i);

In the first case, ITS4 will look at the second argument to a strcpy.
If it is a string constant, the severity of the problem site is
reduced to the lowest possible level. The tool will not output this
kind of problem in its standard mode. In the second case, a similar
reduction in severity occurs, since the sprintf format string contains
no %s's.

The tool also has handlers that scan for file access race conditions,
similar to the prototype tool discussed in [BD96]. We slightly
improve on their tool by allowing for interprocedural and intermodular
problems.

There are some technical limitations to this tool, many of which we
hope to improve in the future. We'd like to have the help of the
security community. I'm personally dedicated to improving this tool,
and Reliable Software Technologies is willing to put some resources
towards doing so. Changes from the community will certainly be
considered for inclusion in future ITS4 releases.

Currently, the weakest area of ITS4, where the input of the security
community is most important, is the vulnerability database, which was
largely taken from some very preliminary work done by Tom O'Connor.
It's perhaps a good start, but far from complete. Many new things
could be added, and the entries that do exist can likely be improved
substantially. For each database entry, we have a description, a
default severity, and a recommended alternative. Generally, the
descriptions are pretty scant, and the severities are not overly well
thought out.

The next area for improvement is the handlers. It would be great to
see people writing some good handlers, or even suggesting good
handlers, and then we could write them.

Beyond that we're interested in the following:

1) Flagging the allocation mechanism used on important variables
(i.e., stack-allocated buffers are usually easier to exploit than
heap-allocated buffers if there is an overflow).

2) Performing much better static analysis. We'd probably like to
start by building some sort of heuristic alias analysis, and then
doing something similar to the analysis done in [WF+00].

We do have plans to ultimately do these things, but if other people
want to code them up and contribute to the project, that's great.

I've set up a mailing list for people who are interested in helping
out in any capacity. Hopefully we can get a good discussion going
that will improve the vulnerability database, and make ITS4 a far more
useful tool. The mailing list signup is available at:
.

John Viega
Software Security Group Co-founder
Reliable Software Technologies
viega@rstcorp.com

References:

[BD96] M. Bishop and M. Dilger. Checking for race conditions in file
accesses. Computing Systems, 9(2):131-152, Spring 1996.

[WF+00] D. Wagner, J. Foster, E. Brewer, and A. Aiken. A first step
towards automated detection of buffer overrun vulnerabilities. In
Proceedings of the Year 2000 Network and Distributed System Security
Symposium (NDSS), pages 3-17, San Diego, CA, 2000.