Finding Vulnerability: Static and Dynamic Analysis

1
Finding Vulnerability Static and Dynamic
Analysis

• By Jeff Scaparra

2
Software Assurance

• Should programs that issue security patches be
  more "secure" than those that no vulnerabilities
  have been found?
• Should we say applications who regularly issue
  security patches are secure?

3
Software Assurance

• Should programs that issue security patches be
  more "secure" than those that no vulnerabilities
  have been found?
• Should we say applications who regularly issue
  security patches are secure?
•  
• If a certain type of car was known to have faulty
  brakes that if not fixed would fail would that
  car be seen as a safe car because a recall was
  issued on the brakes?

4
Teaching Secure Programming

• Has been taught for the last 25 years.
• Lots of information has been published on the
  internet.
• Still developers write code with the same bugs
  over and over
• SANS "TOP 25 Most Dangerous Programming Errors"

5
Automated Static Analysis

• Zheng, J. Williams, L. Nagappan, N. Snipes,
  W. Hudepohl, J.P. Vouk, M.A., "Onthe value of
  static analysis for fault detection in software,"
  Software Engineering, IEEETransactions on ,
  vol.32, no.4, pp. 240-253, April 2006
• Concluded that automated static anlysis was cost
  effective and the types of errors detected with
  static analysis have a high potential to cause
  security vulnerabilities.

6
Static Analysis

• Static analysis is an analysis that takes place
  without executing the program.
• It may use source code or the compiled binary.
• It is rule based and the tools are only as good
  as the rules that they use to make decisions.
• Because most security vulnerabilities are from
  known coding mistakes static analysis can be very
  helpful.

7
Methods of Static Analysis

• Simple Grep 
• doesn't have any context.
• doesn't understand a function call from  a
  comment.
• Lots of false positives.
• Lexical
• Preprocesses and tokenizes the source.
• Less false positives than grep but we can do
  better
• Abstract Syntax Trees
• Takes into account the semantics of the program.
• Can work with different scoping depending on
  resources.
• Local - a single function.
• Module - A single class or compilation unit.
• Global - Everything.

8
Problem with Static Analysis

• Today programs are delievered dynamically on
  demand.
• Programs are collections of dynamically linked
  libraries.
• Vendors don't always provide the source.
• Dynamic Analysis (while it can use the source)
  doesn't require access to the source and is
  fitting for these applications and more.

9
Dynamic Analysis

• Dynamic analysis involves running the program in
  order to evaluate the software. 
• Fuzzing, Blackbox testing, Whitebox fuzzing, are
  all examples of dynamic analysis.

10
Fuzzing

• "It started on a dark and stormy night" - An
  Empirical study of the Reliability of Unix
  Utilities
• A storm caused noise in the lines of a modem
  connection causing random characters to be
  inserted into the line which caused programs to
  crash.
• Fuzzing was born
• "Fuzzing is targeting input and delivering data
  that is handled by a target with the intent of
  identifying bugs" - Fuzzing for Fun and Profit

11
Possible targets of fuzzing (not a full list)

• Buffer Overflows
• Example sprintf( buf, "s", input )
• Format Strings
• Example printf( buf )
•  Integer Overflows
• non-exploitable unless we can control the size
  calculation of a buffer
• Example if(len gt 512) return -1 memcpy(buf,
  input, len)
•  Out-of-Bounds Breakage
•  can read, write, execute files... 
• Example system( input )  

12
Fuzzing An Introduction

• Fuzzing is hard to do by hand so it is normally
  automated. 
• Key elements to the fuzzer are
• A robust fuzzing oracle
• Specific data format to prepare for fuzzing
• Communication method with target

13
Types of Fuzzing

• Unix Utilities
• GUIs
• File Format Fuzzing
• APIs
• Network

14
Fuzzing An Example

• Taken from http//www.milw0rm.com/papers/288
• The first step is to see what can be fuzzed in
  our target
• fuzz_at_linux /opt/mbse/bin/mbuseraddmbuseradd
  commandlinembuseradd gid name comment
  usersdir
• Look for environmental variables
• fuzz_at_linux grep getenv audit/mbse//mbuseradd.
  csprintf(shell, "s/bin/mbsebbs",
  getenv("MBSE_ROOT"))fuzz_at_linux
• We found 5 inputs to fuzz.

15
Fuzzing an example code and debug

•  source found at http//www.milw0rm.com/papers/28
  8

16
Fuzzing verses Static Analysis

• Everything found with fuzzing was a bug. No false
  positives.
• Had to do extra work to find the bug.
• Finding bugs/security vulnerabilities is
  dependent on using a good oracle that finds a
  critical execution path that is vulnerable

17
Whitebox/Smart Fuzzing

• It is hard to generate an oracle that can provide
  100 code coverage.
• if( x 10 ) then
•  
• Has a one in 232 chance of running the then
  portion which may contain a bug.

18
Whitebox/Smart Fuzzing

• To improve the code coverage of fuzzing we can
  use concepts from static analysis to create a
  smarter oracle.
• By using the source we can create input
  constraints from the conditional statements in
  the program.
• This can lead to path explosion in large
  applications In these cases we must limit the
  scope and test functions in isolation storing the
  data from each run to compare against other runs.
• In order to do this we must be able to track and
  store the state of the system.

19
Whitebox/Smart Fuzzing

• One of the pros of fuzzing was the lack of need
  for source code
• We can still apply these methods when we don't
  have the source by using the conditional
  statements in the machine code.

20
Typical Rules for Critical Execution Paths

• Visit unexplored code regions of every
  conditional jump statement.
• Explore paths that involve memory assignments
  with non-constant target addresses.
• If loop analysis fails to reduce the number of
  iterations of a loop, push the loop through more
  iterations if it seems to write toward sensitive
  memory regions.
• Avoid dead-ends (things that exit).
• When statically one or more reaching definitions
  for the target address of an indirect control
  transfer (i.e. call eax) are identified, force
  section to be visited.

21
Conclusion Static Code Analysis

• Advantages
• Finds weaknesses in code at their exact location
• Allows for quicker turn around for patching
• Done quickly when automated
•  
• Weakness
• Time consuming to do manually
• Automated tools don't support all languages
• Tends to produce both false positives and false
  negatives
• Automated tools can lead to false sense of
  security
• Only as good as the rules that the tools use
• Approximating what the code will do is not always
  the same as running it

22
Conclusion Dynamic Code Analysis

• Advantages
• Identifies real bugs in a runtime environment
• Allows for analysis without source code
• Can identify thing that were false negatives in
  static analysis
• Provides validation of static analysis
• Can be conducted against any application
• Weakness
• Tends to produce both false positives and false
  negatives
• Automated tools can lead to false sense of
  security
• Only as good as the oracle that the tools use
• Tracing the vulnerability back to the exact code
  is harder
• Fixing problems takes longer

23
References

•  Fred B. Schneider, Greg Morrisett, Robert
  Harper. A language-based approach to security.
  Informatics 10 Years Back, 10 Years Ahead,
  Lecture Notes in Computer Science, Vol. 2000,
  Springer-Verlag, Heidelberg, 86-101 
• Zheng, J. Williams, L. Nagappan, N. Snipes,
  W. Hudepohl, J.P. Vouk, M.A., "On the value of
  static analysis for fault detection in software,"
  Software Engineering, IEEE Transactions on ,
  vol.32, no.4, pp. 240-253, April
  2006URL http//ieeexplore.ieee.org/stamp/stamp.j
  sp?arnumber1628970isnumber34170 
• Martin Bob, "Experts Announce Agreement on the 25
  Most Dangerous Programming Errors - And How to
  Fix ThemAgreement Will Change How Organizations
  Buy Software." http//www.sans.org/top25errors/,
  April 2009. M. Young and R. N. Taylor,
  "Rethinking the taxonomy of Fault Detection
  Techniues," Proc. Int'l Conf. Software Eng, pp.
  53-62, 1989 
• Mock Markus, "Dynamic Analysis from the Bottom
  Up", WODA 2003 ICSE Workship on Dynamic Analysis,
  pp. 13-16, 2003. 
•  Month of Browser Bugs, July 2006. Web Page
  http//browserfun.blogspot.com/. 
• Brown Jeremy, "Fuzzing for Fun and Profit",
  http//www.milw0rm.com/papers/288, February 11,
  2009.
•  
• Jackson William, "Static vs. Dynamic code
  analysis advantages and disadvantages",http//www
  .gcn.com/Articles/2009/02/09/Static-vs-dynamic-cod
  e-analysis.aspx?Page2, Feb 09, 2009.
• Lanzi Andrea, Martignoni Lorenzo, Monga Mattia,
  Paleari Roberto, "A Smart Fuzzer for x86
  Executables", 29th International Conference on
  Software Engineering Workshops, 2007.