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: http://www.rstcorp.com/its4/ 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: http://www.list.org/mailman/listinfo/its4. John Viega Software Security Group Co-founder Reliable Software Technologies viegaat_private 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.
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:36:29 PDT