An interesting piece of software -- should help us: >Date: Mon, 21 Feb 2000 10:35:00 -0800 >From: John Viega <[EMAIL PROTECTED]> >Subject: Announcement of the ITS4 software security scanner > > [This is a nifty piece of work, and presents one more argument for > open-source software -- although I suppose proprietary software purveyors > might prefer to apply it themselves to closed-source systems! But it is > noteworthy that this analytic tool is itself open source. PGN] > >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 >[EMAIL PROTECTED] > >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.
