CIS 4615 meeting -*- Outline -*-

* analysis tools for detecting vulnerabilities

  Based in part on chapter 6 of the book by John Viega and Gary McGraw. 
  Building Secure Software: How to Avoid Security Problems the Right
  Way. Addison-Wesley Professional, 2002. 

** goals
------------------------------------------
     GOALS OF VULNERABILITY CHECKERS

- Report all potential vulnerabilities
   (100% recall, no false negatives)
   for 


- Order warnings by severity


------------------------------------------
     ... known types of vulnerabilities

*** examples
    These all use the files from Homework 3 from Fall 2015
    found in the subdirectory hw3 here.

**** flawfinder
------------------------------------------
         FLAWFINDER 

Simple static analysis for C/C++
   security vulnerabilities

See http://www.dwheeler.com/flawfinder/

Can install on a PC
   using cygwin (if has python)

run by giving it a directory name
   containing code:

  flawfinder --context --html hw3 \
     > flawfinder-output.html

------------------------------------------
        The makefile does this with the flawfinder target:

            make flawfinder

        Have a look at the output...
             firefox flawfinder-output.html

        Q: Does the output match what you found in homework 3?
        Yes, and more!

------------------------------------------
        LIMITATIONS OF FLAWFINDER

Mostly looks for dangereous function names

Will this have false positiives?


Consider:

 void testfmt() {
   const char *name = "my name";
   printf(name);
 }

What does flawfinder say?

 testfmt.c:3 [4] (format) printf: 
   If format strings can be influenced
    by an attacker, they can be exploited
    (CWE-134). Use a constant ...

   printf(name);

From the manual:
   "Not every hit is 
   actually a security vulnerability, and 
   not every security vulnerability 
   is necessarily found."
------------------------------------------
        ... Yes

        Q: Do we still need a trained human to look at the ouput?
        Yes, to determine which really needs fixing.

        The following is from the flawfinder web page:
         http://www.dwheeler.com/flawfinder/
------------------------------------------
      CAREFUL WITH DISABLING WARNINGS

Actual flaw in RealNetworks code:

 char tmp[256]; /* Flawfinder: ignore */
 strcpy(tmp, pScreenSize); /* Flawfinder: ignore */


When should warnings be disabled?
   - if 


------------------------------------------
     Comment about the RealNetworks code on the flawfinder web page:
     "This means that flawfinder did find this vulnerability, but
     instead fixing it, someone added the "ignore" directive to the
     code so that flawfinder would stop reporting the
     vulnerability. But an "ignore" directive simply stops flawfinder
     from reporting the vulnerability - it doesn't fix the
     vulnerability!"

     ... "the reviewer has determined the code 
          is definitely a false positive"

**** CodeSonar
------------------------------------------
       CODE SONAR FROM GRAMMATECH

UCF has a license for this software
Download from shared drive:

   \\lorentz.cs.ucf.edu\Shared\

When you start it, 
  it will ask for the server's location. 
  Use 
     10.173.215.113:7340
  From outside UCF, must use the VPN

------------------------------------------
        Try this on the hw3 directory,
            you have to first go to the directory and run
                make

       See
         http://10.173.215.113:7340/analysis/3.html
       for sample output on homework 3

       Note that there is no report about testfmt.c (fewer false positives!)

**** Clang
------------------------------------------
          CLANG STATIC ANALYZER

Finds problems in C/C++/Objective-C

Works on Macs, and with Xcode!

See http://clang-analyzer.llvm.org/


------------------------------------------

**** SPLINT
------------------------------------------
     SPLINT - SECURE PROGRAMMING LINT

See http://splint.org/
   There is a windows installer

Uses annotations that give specifications

Able to state and check:
 - pre-conditions
 - post-conditions
 - invariants

Looks for bugs in:
 - bounds of array accesses
 - bad use of functions (gets, printf, etc.)
 - memory usage (malloc and free)
 - improper use of abstract data types
 - suspicious statements (with no effects)
 - unused declarations
 
------------------------------------------

** summary of advice for using audit tools
------------------------------------------
      ADVICE FOR USING AUDIT TOOLS

Remember the limits of static analysis:
 - there will be false positives
 - vulnerabilities identified are only
   possible ones
 
Don't skim the output too lightly
 - high priority warnings need attention
 - consider as many warnings as possible
 - learn about problems before:
     fixing them or
     dismissing them
 - don't just turn off warnings

It will take time
 - experts more efficient, but still slow
   
Overall tools can help find real bugs

------------------------------------------