1. Program Analysis and Verification Spring 2013 Program Analysis and Verification Lecture 1: Introduction Roman Manevich Ben-Gurion University

2. December 31, 2008 30GB Zunes all over the world fail en masse 2

3. Zune bug 1 while (days > 365) { 2 if (IsLeapYear(year)) { 3 if (days > 366) { 4 days -= 366; 5 year += 1; 6 } 7 } else { 8 days -= 365; 9 year += 1; 10 } 11 } 3

4. Zune bug 1 while (366 > 365) { 2 if (IsLeapYear(2008)) { 3 if (366 > 366) { 4 days -= 366; 5 year += 1; 6 } 7 } else { 8 days -= 365; 9 year += 1; 10 } 11 } Suggested solution: wait for tomorrow 4

5. February 25, 1991 On the night of the 25 th of February, 1991, a Patriot missile system operating in Dhahran, Saudi Arabia, failed to track and intercept an incoming Scud. The Iraqi missile impacted into an army barracks, killing 28 U.S. soldiers and injuring another 98. Patriot missile failure 5

6. Patriot bug – rounding error Time measured in 1/10 seconds Binary expansion of 1/10: 0.0001100110011001100110011001100.... 24-bit register 0.00011001100110011001100 error of – 0.0000000000000000000000011001100... binary, or ~0.000000095 decimal After 100 hours of operation error is 0.000000095×100×3600×10=0.34 A Scud travels at about 1,676 meters per second, and so travels more than half a kilometer in this time Suggested solution: reboot every 10 hours 6

7. August 13, 2003 Billy Gates why do you make this possible ? Stop making money and fix your software!! (W32.Blaster.Worm) 7

8. Windows exploit(s) Buffer Overflow 8 void foo (char *x) { char buf[2]; strcpy(buf, x); } int main (int argc, char *argv[]) { foo(argv[1]); }./a.out abracadabra Segmentation fault Stack grows this way Memory addresses Previous frame Return address Saved FP char* x buf[2] … ab ra ca da br

9. Buffer overrun exploits int check_authentication(char *password) { int auth_flag = 0; char password_buffer[16]; strcpy(password_buffer, password); if(strcmp(password_buffer, "brillig") == 0) auth_flag = 1; if(strcmp(password_buffer, "outgrabe") == 0) auth_flag = 1; return auth_flag; } int main(int argc, char *argv[]) { if(check_authentication(argv[1])) { printf("\n-=-=-=-=-=-=-=-=-=-=-=-=-=-\n"); printf(" Access Granted.\n"); printf("-=-=-=-=-=-=-=-=-=-=-=-=-=-\n");} else printf("\nAccess Denied.\n"); } (source: “hacking – the art of exploitation, 2 nd Ed”) 9

10. (In)correct usage of APIs  Application trend: Increasing number of libraries and APIs – Non-trivial restrictions on permitted sequences of operations  Typestate: Temporal safety properties – What sequence of operations are permitted on an object? – Encoded as DFA e.g. “Don’t use a Socket unless it is connected” init connected closed err connect()close() getInputStream() getOutputStream() getInputStream() getOutputStream() getInputStream() getOutputStream() close() * 10

11. Challenges class SocketHolder { Socket s; } Socket makeSocket() { return new Socket(); // A } open(Socket l) { l.connect(); } talk(Socket s) { s.getOutputStream()).write(“hello”); } main() { Set set = new HashSet (); while(…) { SocketHolder h = new SocketHolder(); h.s = makeSocket(); set.add(h); } for (Iterator it = set.iterator(); …) { Socket g = it.next().s; open(g); talk(g); } 11

12. Testing is not enough Observe some program behaviors What can you say about other behaviors? Concurrency makes things worse Smart testing is useful – requires the techniques that we will see in the course 12

13. Static analysis definition Reason statically (at compile time) about the possible runtime behaviors of a program “The algorithmic discovery of properties of a program by inspection of its source text 1 ” -- Manna, Pnueli 1 Does not have to literally be the source text, just means w/o running it 13

14. Is it at all doable? x = ? if (x > 0) { y = 42; } else { y = 73; foo(); } assert (y == 42); Bad news: problem is generally undecidable 14

15. universe Central idea: use approximation Under Approximation Exact set of configurations/ behaviors 15 Over Approximation

16. Goal: exploring program states initial states bad states 16 reachable states

17. Technique: explore abstract states initial states bad states 17 reachable states

18. Technique: explore abstract states initial states bad states 18 reachable states

19. Technique: explore abstract states initial states bad states 19 reachable states

20. Technique: explore abstract states initial states bad states 20 reachable states

21. Sound: cover all reachable states 21 initial states bad states reachable states

22. Unsound: miss some reachable states 22 initial states bad states reachable states

23. 23 Imprecise abstraction initial states bad states 23 reachable states False alarms

24. A sound message x = ? if (x > 0) { y = 42; } else { y = 73; foo(); } assert (y == 42); Assertion may be violated 24

25. Avoid useless result Low false alarm rate Understand where precision is lost Precision UselessAnalysis(Program p) { printf(“assertion may be violated\n”); } 25

26. Runtime vs. static analysis RuntimeStatic analysis EffectivenessCan miss errors Finds real errors Can find rare errors Can raise false alarms CostProportional to program’s execution Proportional to program’s complexity No need to efficiently handle rare cases Can handle limited classes of programs and still be useful 26

27. Driver’s Source Code in C Precise API Usage Rules (SLIC) Defects 100% path coverage Rules Static Driver Verifier Environment model Static Driver Verifier

28. Bill Gates’ Quote "Things like even software verification, this has been the Holy Grail of computer science for many decades but now in some very key areas, for example, driver verification we’re building tools that can do actual proof about the software and how it works in order to guarantee the reliability." Bill Gates, April 18, 2002. Keynote address at WinHec 2002 Keynote addressWinHec 2002

29. The Astrée Static Analyzer Patrick Cousot Radhia Cousot Jérôme Feret Laurent Mauborgne Antoine Miné Xavier Rival ENS France

30. Objectives of Astrée Prove absence of errors in safety critical C code ASTRÉE was able to prove completely automatically the absence of any RTE in the primary flight control software of the Airbus A340 fly-by-wire system – a program of 132,000 lines of C analyzed

31. Objectives of Astrée Prove absence of errors in safety critical C code ASTRÉE was able to prove completely automatically the absence of any RTE in the primary flight control software of the Airbus A340 fly-by-wire system – a program of 132,000 lines of C analyzed By Lasse Fuss (Own work) [CC-BY-SA-3.0 (http://creativecommons.org/licenses/by-sa/3.0)], via Wikimedia Commons

32. A little about me History – Studied B.Sc., M.Sc., Ph.D. at Tel-Aviv University Research in program analysis with IBM and Microsoft – Post-doc in UCLA and in UT Austin – Joined Ben-Gurion University this year Example research challenges – What’s a good algorithm for automatically discovering (with no hints) that a program generates a binary tree where all leaves are connected in a list? – What’s a good algorithm for automatically proving that a parallel program behaves “well”? – How can we automatically synthesize parallel code that is both correct and efficient? 32

33. Why study program analysis? Challenging and thought provoking – An approach for dealing with computationally hard (usually undecidable) problems – Treat programs as mathematical objects Understand how to systematically – Design optimizations – Reason about correctness / find bugs (security) Some techniques may be applied in other domains – Computational learning – Analysis of biological systems 33

34. What do you get in this course? Learn basic principles of static analysis – Understand jargon/papers Learn a few advanced techniques – Some principled way of developing analysis – Develop one in a small-scale project Put to practice what you learned in logic, automata, programming 34

35. My role Teach you theory and practice Teach you how to think of new techniques E-mail: romanm@cs.bgu.ac.il Office hours: Wednesday 13:00-15:00 Course web-pageweb-page – Announcements – Forum – … 35

36. Requirements 1.Summarize one lecture: 10% of grade – Submit initial summary – Get corrections/suggestions – Submit revised summary 2.Theoretical assignments and programming assignments: 50% – About 8 (some very small) – Must submit all – Must solve all questions – Otherwise re-submit (and get a lower grade) 3.Final project: 40% – Implement a program analyzer for a given component 36

37. How to succeed in this course Attend all classes Make sure you understand material in class – Engage by asking questions and raising ideas Be on top of assignments – Submit on time – Don’t get stuck or give up on exercises – get help – ask me – Don’t start working on assignments the day before Be ethical 37 Joe (a day before assignment deadline): “I don’t really understand what you want from me in this assignment, can you help me/extend the deadline”?

38. The static analysis approach Formalize software behavior in a mathematical model (semantics) Prove properties of the mathematical model – Automatically, typically with approximation of the formal semantics Develop theory and tools for program correctness and robustness 38

39. Kinds of static analysis Spans a wide range – type checking … up to full functional verification General safety specifications Security properties (e.g., information flow) Concurrency correctness conditions (e.g., absence of data races, absence of deadlocks, atomicity) Correct usage of libraries (e.g., typestate) Underapproximations useful for bug-finding, test-case generation,… 39

40. Static analysis techniques Abstract Interpretation Dataflow analysis Constraint-based analysis Type and effect systems 40

41. Static analysis for verification program specification Abstract counter example Analyzer Valid 41

42. Relation to program verification Fully automatic Applicable to a programming language Can be very imprecise May yield false alarms Requires specification and loop invariants Program specific Relatively complete Provides counter examples Provides useful documentation Can be mechanized using theorem provers Static AnalysisProgram Verification 42

43. Verification challenge main(int i) { int x=3,y=1; do { y = y + 1; } while(--i > 0) assert 0 < x + y; } main(int i) { int x=3,y=1; do { y = y + 1; } while(--i > 0) assert 0 < x + y; } Determine what states can arise during any execution Challenge: set of states is unbounded 43

44. Abstract Interpretation main(int i) { int x=3,y=1; do { y = y + 1; } while(--i > 0) assert 0 < x + y; } main(int i) { int x=3,y=1; do { y = y + 1; } while(--i > 0) assert 0 < x + y; } Recipe 1)Abstraction 2)Transformers 3)Exploration Challenge: set of states is unbounded Solution: compute a bounded representation of (a superset) of program states Determine what states can arise during any execution 44

45. 1) Abstraction main(int i) { int x=3,y=1; do { y = y + 1; } while(--i > 0) assert 0 < x + y; } main(int i) { int x=3,y=1; do { y = y + 1; } while(--i > 0) assert 0 < x + y; } concrete state abstract state (sign)  : Var  Z  # : Var  {+, 0, -, ?} xyi 317 xyi +++ 326 xyi … 45

46. 2) Transformers main(int i) { int x=3,y=1; do { y = y + 1; } while(--i > 0) assert 0 < x + y; } main(int i) { int x=3,y=1; do { y = y + 1; } while(--i > 0) assert 0 < x + y; } concrete transformer abstract transformer xyi ++ 0 xyi 31 0 y = y + 1 xyi 32 0 xyi ++ 0 +- 0 +? 0 + 00 ++ 0 +? 0 +? 0 46

47. 3) Exploration ++ ? ++ ? xyi main(int i) { int x=3,y=1; do { y = y + 1; } while(--i > 0) assert 0 < x + y; } main(int i) { int x=3,y=1; do { y = y + 1; } while(--i > 0) assert 0 < x + y; } ++ ? ++ ? ?? ? xyi ++ ? ++ ? ++ ? ++ ? ++ ? ++ ? 47

48. Incompleteness  main(int i) { int x=3,y=1; do { y = y - 2; y = y + 3; } while(--i > 0) assert 0 < x + y; } +? ? +? ? xyi +? ? ++ ? ?? ? xyi +? ? +? ? +? ? 48

49. Parity abstraction challenge: how to find “the right” abstraction while (x !=1 ) do { if (x % 2) == 0 { x := x / 2; } else { x := x * 3 + 1; assert (x %2 ==0); } 49

50. How to find “the right” abstraction? Pick an abstract domain suited for your property – Numerical domains – Domains for reasoning about the heap – … Combination of abstract domains Another approach – Abstraction refinement 50

51. Following the recipe (in a nutshell) 1) Abstraction Concrete state Abstract state x t n n n x t n 2) Transformers n x t n t n x n t->n = x 51

52. Example: shape (heap) analysis t x n x t n x t n n x t n n x t t x n t t n t x t x t x emp void stack-init(int i) { Node* x = null; do { Node  t = malloc(…) t->n = x; x = t; } while(--i>0) Top = x; } assert(acyclic(Top)) t x nn x t n n x t n n n x t n n n x t n n n top 52

53. x t n n t x n x t n x t n n x t t x n t t n t x t x t x emp x t n n x t n n n x t n t n x n x t n n 3) Exploration x t n Top n n t x t x x t n n void stack-init(int i) { Node* x = null; do { Node  t = malloc(…) t->n = x; x = t; } while(--i>0) Top = x; } assert(acyclic(Top)) 53

54. Example: polyhedra (numerical) domain proc MC(n:int) returns (r:int) var t1:int, t2:int; begin if (n>100) then r = n-10; else t1 = n + 11; t2 = MC(t1); r = MC(t2); endif; end var a:int, b:int; begin b = MC(a); end What is the result of this program? 54

55. McCarthy 91 function proc MC (n : int) returns (r : int) var t1 : int, t2 : int; begin /* (L6 C5) top */ if n > 100 then /* (L7 C17) [|n-101>=0|] */ r = n - 10; /* (L8 C14) [|-n+r+10=0; n-101>=0|] */ else /* (L9 C6) [|-n+100>=0|] */ t1 = n + 11; /* (L10 C17) [|-n+t1-11=0; -n+100>=0|] */ t2 = MC(t1); /* (L11 C17) [|-n+t1-11=0; -n+100>=0; -n+t2-1>=0; t2-91>=0|] */ r = MC(t2); /* (L12 C16) [|-n+t1-11=0; -n+100>=0; -n+t2-1>=0; t2-91>=0; r-t2+10>=0; r-91>=0|] */ endif; /* (L13 C8) [|-n+r+10>=0; r-91>=0|] */ end var a : int, b : int; begin /* (L18 C5) top */ b = MC(a); /* (L19 C12) [|-a+b+10>=0; b-91>=0|] */ end if (n>=101) then n-10 else 91 55

56. Some things that should trouble you Does a result always exist? Does the recipe always converge? How “optimal” is the result? How do I pick my abstraction? How do come up with abstract transformers? Other practical issues – Efficiency – How does it do in practice? 56

57. Change the abstraction to match the program Abstraction refinement program specification Abstract counter example abstraction Abstraction Refinement   counter example Verify Valid 57

58. Recap: program analysis Reason statically (at compile time) about the possible runtime behaviors of a program use sound overapproximation of program behavior abstract interpretation – abstract domain – transformers – exploration (fixed-point computation) finding the right abstraction? 58

59. Next lecture: semantics of programming languages 59

60. References Patriot bug: – http://www.cs.usyd.edu.au/~alum/patriot_bug.html http://www.cs.usyd.edu.au/~alum/patriot_bug.html – Patrick Cousot’s NYU lecture notes Zune bug: – http://www.crunchgear.com/2008/12/31/zune-bug-explained-in- detail/http://www.crunchgear.com/2008/12/31/zune-bug-explained-in- detail/ Blaster worm: – http://www.sans.org/security- resources/malwarefaq/w32_blasterworm.php http://www.sans.org/security- resources/malwarefaq/w32_blasterworm.php Interesting CACM article – http://cacm.acm.org/magazines/2010/2/69354-a-few-billion-lines-of- code-later/fulltext http://cacm.acm.org/magazines/2010/2/69354-a-few-billion-lines-of- code-later/fulltext Interesting blog post – http://www.altdevblogaday.com/2011/12/24/static-code-analysis/ http://www.altdevblogaday.com/2011/12/24/static-code-analysis/ 60