server side analysis
play

SERVER-SIDE ANALYSIS Ben Livshits, Microsoft Research Overview of - PowerPoint PPT Presentation

SERVER-SIDE ANALYSIS Ben Livshits, Microsoft Research Overview of Todays Lecture 2 Static analysis for Runtime analysis bug finding Fuzzing Pen testing Tainting Scripting languages Symbolic execution analyzed


  1. SERVER-SIDE ANALYSIS Ben Livshits, Microsoft Research

  2. Overview of Today’s Lecture 2  Static analysis for  Runtime analysis bug finding  Fuzzing  Pen testing  Tainting  Scripting languages  Symbolic execution analyzed (UsenixSec ‘05 paper)

  3. Compilers Under the Hood 3

  4. Stages of Compilation 4 Source code Lexing Parsing IR Analysis Code generation Executable code

  5. Stages of Compilation 5 Source code Lexing Parsing IR Analysis Code generation Executable code

  6. Stages of Compilation 6 Source code Lexing Parsing IR Analysis Code generation Executable code

  7. Stages of Compilation 7 Source code Lexing Parsing IR Analysis Code generation Executable code

  8. Stages of Compilation 8 Source code Lexing Parsing IR Analysis Code generation Executable code

  9. Stages of Compilation 9 Source code Lexing Parsing IR Analysis Code generation Executable code

  10. Static Analysis 10  Pros?  Cons?

  11. Static Analysis Tool for Bug Finding: Plan 11 Read the program 1. Transform into an Intermediate Representation 2. (IR) Do analysis on the IR 3. Output results 4.

  12. Dimensions of Analysis 12  Intraprocedural vs. interprocedural  Flow sensitive vs. flow-insensitive  Context sensitive vs. context-insensitive

  13. Cost vs. Effectiveness 13 overhead • interprocedural • flow-sensitive • context-sensitive • hard to implement • intraprocedural • flow-insensitive • context-insensitive • not too hard to build grep or grep++ like LCLink bugs found

  14. Historical background 14  Intrinsa  1997-200?  paved way for MS  Coverity  Out of Stanford  Commercial static analysis tools  Fortify  Tools for security  Klockwork

  15. Paper Contributions 15  Interprocedural static analysis algorithm  Address dynamic language features  Hash table use  Regular expression matching  Features  Symbolic execution inside basic blocks  Basic block summaries

  16. Paper Contributions 16  Focus  SQL injection vulnerabilities. Why? Good idea?  XSS – claim to handle with minor modifications  Experiments  6 PHP apps  Finds 105 previously unknown vulnerabilities

  17. PHP Language Features 17  Natural SQL integration  $rows = mysql_query( “UPDATE users SET pass=‘$pass’ WHERE userid =‘$ userid ’”);  Dynamic types and implicit casts  If ($userid < 0) exit;  $query = “SELECT * from users WHERE userid =‘$ userid ’”;  Global environment  $_GET[‘name’] or $ name  $ used with register_globals = on? Attacker may provide arbitrary value for $superuser by inserting something like $superuser=1 into HTTP request

  18. Analysis Steps (Section 3) 18

  19. Basic blocks: Simulation 19  Build up a model mapping labels -> values  Special treatment of strings. Why?  Special treatment of (some) booleans. Why?

  20. Various Data Types: Representation 20

  21. Basic Block Summary 21 Set Symbol Description Error set Input variables which must be sanitized before E entering this basic block Return value Representation for return value R Untaint set Sanitized locations for each successor U Termination Block contains exit() or calls another T predicate termination function Value flow Set of location pairs (l 1 , l 2 ) where l 1 is a F substring of l 2 on exit Definitions Defined memory locations D

  22. Function Summary 22 Set Symbol Description Error set Input variables which must be sanitized before E entering this basic block Memory location that can flow to database inputs Return value Representation for return value R for main function, this cannot include Sanitized Sanitized locations for each successor S $_GET[…] or $_POST[…] values Program exit Block contains exit() or calls another X termination function

  23. Function Summary 23 Set Symbol Description string-typed parameters or globals that might be Error set Input variables which must be sanitized before E returned, either fully or as part of a longer string entering this basic block function make query($user, $pass) { Return value Representation for return value R global $table; Sanitized Sanitized locations for each successor S return "SELECT * from $table ". values "where user = $user and Program exit Block contains exit() or calls another X pass = $pass"; termination function } R = { $table, $arg#1, $arg#2 }

  24. Function Summary 24 Set Symbol Description the set of parameters or global variables that are Error set Input variables which must be sanitized before E sanitized on function exit entering this basic block Return value Representation for return value R function is_valid($x) { Sanitized Sanitized locations for each successor S if (is numeric($x)) return true; values return false; } Program exit Block contains exit() or calls another X termination function S = (false => {}, true => {arg#1})

  25. Function Summary 25 Set Symbol Description Error set Input variables which must be sanitized before E entering this basic block Return value Representation for return value R Sanitized Sanitized locations for each successor S a Boolean which indicates whether values the current function terminates Program exit Block contains exit() or calls another X program execution on all paths termination function

  26. Interprocedural Analysis 26

  27. Why On Demand? 27  PHP Fusion  version 7-02-03  about 52K lines of code  But really only about 16,000 matter

  28. Checker Input 28  We seed the checker with a small set of query functions (e.g. mysql_query ) and sanitization operations (e.g. is_numeric ).  The checker infers the rest automatically

  29. Checker Output 29  Errors  Variables controlled by the attacker $_GET[…] and $_POST[…]  Warnings  Other environment-define variables at the level of main

  30. Result Summary 30

  31. question of the day 31 Are the techniques in the paper sound, i.e. do they find all SQL injection bugs?

  32. Runtime Analysis Overview 32 Black-box analysis White-box analysis • • Fuzzing Tainting • • Penetration testing Symbolic execution • •

  33. Fuzzing: A Definition 33 “Fuzz testing or fuzzing is a software testing technique that provides invalid, unexpected, or random data to the inputs of a program. If the program fails (for example, by crashing or failing built-in code assertions), the defects can be noted .” Wikipedia

  34. Why Fuzz in General?  Another point of view of testing  If its automated, why not?  Some Fuzzing Successes:  Apple Wireless flaw DoS (MOKB-30-11-2006)  Month of Browser Bugs in 2006, many found with input fuzzing:  IE: 25  Safari: 2  Firefox: 2  Opera: 1  Konquerer: 1

  35. Need a Fuzzing Specification 35 What do they look for? Fuzz testing of web applications, Hammersland and Snekkenes

  36. Penetration Testing Overview 36 Web Application DB !@#$ HTML Secret Data! White Hat Servlets Tester Other Systems

  37. Penetration Testing: Phases Information Attack Attacks Gathering Generation Information Web Target Application Selection HTML Analysis Feedback Servlets White Hat Tester Responses Response Report Analysis

  38. Tainting 38 Negative tainting String s =   Mark or taint untrusted req.getParameter (“ userName ”); input data at runtime String s2 = “hello” + s;  Stop execution when output.println (“<div>”); untrusted input reaches “sinks” output.println(s2); output.println (“</div>”); Positive tainting   Taint trusted data such as constant strings only  Stop execution when data reaching “sinks” is not tainted Propagate the taint through  at the application executes

  39. Questions About Tainting 39  How do we identify all sources in negative tainting?  How do we remote taint?  What is the runtime overhead?

  40. Symbolic Execution 40 String s;  Treat input values if (!P) { symbolically s = req.getParameter (“ userName ”);  Propagate symbolic } else { s = “”; values through }  When encountering a conditional, consider String s2 = “hello” + s; if (P) { both branches output.println (“<div>”);  Use a theorem prover to output.println( s2 ); eliminate infeasible paths output.println (“</div>”); } else { output.println (“hello”); }

  41. Summary 41  Static analysis for  Runtime analysis bug finding  Black-box  Scripting languages  Fuzzing analyzed (UsenixSec  Pen testing ‘05 paper)  White-box  Tainting  Symbolic execution

Recommend


More recommend