[LWN Logo]

Date:         Mon, 21 Feb 2000 12:54:17 -0800
From: John Viega <viega@RSTCORP.COM>
Subject:      ITS4 software security scanner
To: BUGTRAQ@SECURITYFOCUS.COM

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
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.