Empirical Vulnerability Analysis Tool Unification


Ashima Gupta, Ryan Iwahashi, Eric Thomas

Problem Statement

Average programmers often write programs that have bugs, and sometimes these buggy programs end up being distributed to other computers to be exploited by malicious users. There are several tools programmers can use to analyze their code to help reduce the bugs, but few programmers use these tools. Even if some tools are used, the coverage of bug analysis is rather poor. The problem is two-fold: 1) average programmers are not aware of the tools available, and 2) average programmers don't want to learn the ins and outs of the different tools.

Solution

Consider a single tool that could check for all of the vulnerabilities for which current tools check. A programmer would only have to learn the interface - command line arguments, output, annotations, and specifications - for one tool. Of course, the interface would need to incorporate the intracacies of each tool, but could be designed in such a way that there is a uniform format and style. While coding, the programmer could add the appropriate annotations and specifications in a similar fashion as commenting the code, speeding up the vulnerability checking process.

The process of combining these tools into one is called unification and is a very difficult task, particularly when you consider that new tools are being developed all the time. Our first goal is to take a small set of tools and design a tool that merges them into one tool that provides a single interface. Second, we will use this experience and literature on previous related research to recommend guidelines that tool creators could follow to make their tools more usable (in terms of working with them and unifying them).

Milestones

MilestoneIntended DateActual Date
Create webpage; Define metrics; Compile initial set of tools October 17th October 19th
Take a deeper look into the set of tools; Select some tools to merge October 19th October 21st
Design the wrappers, the interface, the annotation unification, and anything else November 9th
Midterm Report November 16th
Create recommendations for future tools to facilitate unification December 2nd
Create Report December 13th

Project Details

Our group has recognized that this project is a fairly large undertaking for a quarter-long project. The milestones are iterative and the part we plan to focus on most is the Design phase. We reason that if we create a good design for unifying the different tools, we have accomplished the biggest and most challenging part of our project. If it happens that our timeline is too ambitious, we will at least be proud of our design and will be able to report our work.

References

  • David Evans and David Larochelle. Splint Manual Version 3.1.1-1. http://www.splint.org/manual. June 5, 2003.
  • David Evans and David Larochelle. Improving Security Using Extensible Lightweight Static Analysis. IEEE Software, Jan/Feb 2002.
  • David Larochelle and David Evans. Statically Detecting Likely Buffer Overflow Vulnerabilities. http://www.splint.org/pubs.html.
  • David Evans. Static Detection of Dynamic Memory Errors. PLDI May 1996.
  • Junfeng Yang, Tek Kremenek, Yichen Xie, and Dawson Engler. MECA: an Extensible, Expressive System and Language for Statically Checking Security Properties. In Proceedings of the 10th ACM conference on Computer and Communications Security (ACM CCS) 2003.
  • Yichen Xie, Andy Chou, and Dawson Engler. ARCHER: Using Symbolic, Path-sensitive Analysis to Detect Memory Access Errors. FSE 2003.

Less Formal References

  • PREfix - A Static Analyzer for Finding Dynamic Programming Errors - William Bush, Jonathan Pincus, and David Sielaff.
  • FlawFinder - http://www.dwheeler.com/flawfinder/
  • RATS - http://www.securesw.com/rats/
  • ITS4 - http://www.cigital.com/its4/
  • BOON - http://www.cs.berkeley.edu/~daw/boon/
  • A Comparison of Publicly Available Tools for Static Intrusion Prevention - John Wilander and Miriam Kamkar.