Application Communities Phase II Overview

1. Application Communities Phase IIOverview Martin Rinard Computer Science and Artificial Intelligence Laboratory Massachusetts Institute of Technology

2. Computing Monoculture Windows Office Firefox Windows Office Firefox Windows Office Firefox Windows Office Firefox Windows Office Firefox Windows Office Firefox Windows Office Firefox Windows Office Firefox Windows Office Firefox

3. Computing Monoculture Issue • Every machine vulnerable to same attack • Single attack could compromise entire computing infrastructure

4. Application Communities Vision • Turn monoculture into community • Cooperate to detect and defend against attacks • Community themes • Learn from attacks • Try different defenses • Obtain (eventually) successful defenses • Key aspect • Willing to sacrifice some members • If sacrifices produce information that enables survival of community as whole

5. Phase I Team • MIT is prime • Determina (MIT startup) is sub • Key component: Determina Memory Firewall • x86 binary managed execution system • Heavily engineered, production quality • Other components • Daikon Invariant Inference system • Detection/Repair Generation subsystem • Communication/Management subsystem

6. Phase I Attacks • Injected code attacks • Stack buffer overflow • Heap out of bounds accesses • Javascript function pointer redirection • Enabled by universal errors (errors program should NEVER have) • Important Phase I Goal • Enable survival in face of attack • Not just detect attack and kill program

7. Phase I Resolution • Successful system development • Successful Red Team exercise • VMWare acquires Determina

8. Phase II Team • MIT is prime • BAE Systems is sub (connection with Phase I via Greg Sullivan) • VMWare releases (some of) Determina technology, available for Phase II • But other components may be more appropriate for Phase II

9. Phase II Attacks • Application-specific errors • Examples • Attack tricks system into sending out file containing sensitive data • Attack tricks system into overwriting a key binary file • Attack tricks system into destroying data • Focus on intercepting system calls • Goals • Eliminate negative consequences of attacks • Enable application to survive

10. Beyond Phase II • COTS software has too much functionality • MS Word executes embedded scripts • Cross-site scripting vulnerabilities • Not errors, but make systems vulnerable • In general, don’t even know full functionality! • Functionality Elimination • Exercise desired functionality during training • Eliminate other functionality • Can make COTS software safe for sensitive uses

11. Phase I Technical Overview

12. Basic Idea • Community learns invariants that are always true in successful executions • Community is attacked • Find a set of invariants that are violated when attack happens • Deploy several alternative repairs that enforce violated invariants • Community tries the different repairs, recognizes which ones work • Successful repairs distributed across community

13. System Operational Modes • Invariant Learning Mode • Monitoring Mode (detecting attacks) • Invariant Localization Mode (detecting which invariants are violated) • Protection Mode (deploying and evaluating repairs) • Modes can be temporally and spatially overlapped

14. Invariant Learning Mode Architecture Community Machine Server Machine Invariant Database Application Invariant Updates Determina MPEE Client Library Tracing Central Daikon Trace Data Invariants Local Daikon Management Console Invariants Node Manager Invariants (https/ssl)

15. What Is Trace Data? • Information about variables in program • Array/buffer index values • Function pointer values • Examples • c = buffer[i]; /* value of i, c */ • (*f)(a); /* value of f */ • Complications because working at binary level • Work with registers, memory locations

16. What Is Trace Data? • Sequence of observations <basic block, binary variable, value> • Binary variables • Variable at binary (not source) level • Type determined by use • Example 1: mov edx, [eax] 2: cmp edx, [ecx+4] • Five binary variables – • 1:eax (ptr) 1:[eax] (int) • 2:edx (int) 2:ecx (ptr) 2:[ecx+4] (int)

17. Determina MPEE andClient Library Application (binary) Code Cache Checked, Transformed Basic Block Basic Block Basic Block Checking And Transformation PC • In learning mode • Basic blocks are transformed to print out trace data

18. Invariant Learning Mode Architecture Community Machine Server Machine Invariant Database Application Invariant Updates Determina MPEE Client Library Tracing Central Daikon Trace Data Invariants Local Daikon Management Console Invariants Node Manager Invariants (https/ssl)

19. What Does the Local Daikon Do? • Local Daikon • Reads trace data • Performs invariant inference • Standard set of invariants • One of (var = one of {val1, …, valn}) • Not null (var != null) • Less than (var1 - var2 < c) • Many more (75 different kinds) • Variables from same basic block (for now)

20. Invariant Learning Mode Architecture Community Machine Server Machine Invariant Database Application Invariant Updates Determina MPEE Client Library Tracing Central Daikon Trace Data Invariants Local Daikon Management Console Invariants Node Manager Invariants (https/ssl)

21. What Does Central Daikon Do? • Takes invariants from Local Daikons • Logically merges invariants into Invariant Database • Each kind of invariant has merge rules • For example • x = 5 merge x = 6 is x one-of {5, 6} • x > 0 merge x > 10 is x > 10 • x = 5 merge no invariant about x is no invariant about x • x = 5 merge no data yet about x is x = 5

22. Application Community Issues • Lots of community members learning at same time • Each community member instruments a (randomly chosen) subset of basic blocks • Minimizes learning overhead • While obtaining reasonable coverage • Learning takes place over successful executions (without attacks) • Controlled environment • A posteriori judgement

23. Monitoring Mode Architecture Community Machine Server Machine Application Determina MPEE Client Library Attack Detection Attack Information Protection Manager Attack Information Management Console Node Manager (https/ssl)

24. Community Machine • Detects attack signal • Determina Memory Firewall • Fatal error (invalid address, divide by zero) • In principle, any indication of attack • Attack information • Program counter where attack occurred • Stack when attack occurred • Sent to server as application dies

25. Invariant Localization Overview • Goal: Find out which invariants are violated when program is attacked • Strategy: • Find invariants close to attack • Make running applications check for violations of these invariants • Correlate invariant violations with attacks

26. Invariant Localization Mode Architecture Community Machine Server Machine Invariant Database Application Determina MPEE Client Library LiveShield Installation Invariants LiveShield Generation Attack & Invariant Violation Detector Protection Manager LiveShields Attack & Invariant Information LiveShields Attack & Invariant Information Management Console Node Manager LiveShields (https/ssl)

27. Finding Invariants Close to Attack • Attack Information • PC of instruction where attack detected (jump to invalid code) (instruction that accessed invalid memory) (divide by zero instruction) • Call stack • Duplicate stack • Preserved even for stack smashing attacks • Find basic blocks that are close to involved PCs • Find invariants for those basic blocks

28. Detecting Invariant Violations • Add checking code to application • Check for violations of selected invariants • Log any violated invariants • Use Determina LiveShield mechanism • Distribute code patches to basic blocks • Eject basic blocks from code cache • Insert new version of basic block with new checking code • Updates programs as they run

29. Correlating Invariant Violations and Attacks • Protection manager fed two kinds of information • Invariant violation information • Attack information • Correlates the information • If invariant violation is followed by an attack • Then invariant is a candidate for enforcement

30. Protection Mode Architecture Community Machine Server Machine Invariant Database Application Determina MPEE Client Library LiveShield Installation Invariants LiveShield Generation Attack Detector & Invariant Enforcement Protection Manager LiveShields Attack & Invariant Information LiveShields Attack & Invariant Information Management Console Node Manager LiveShields (https/ssl)

31. Invariant Enforcement • Given an invariant to enforce • Protection manager generates LiveShields that correspond to different repair options • Current implementation for one-of constraints • Variable is a pointer to a function • Constraint violation is a jump to function previously unseen at that jump instruction • Potential repairs • Call one of previously seen functions • Skip call • Return immediately back to caller

32. Selecting A Good Repair • Protection manager generates a LiveShield for each repair option • Distributes LiveShields across applications • Random assignment, biased as follows • Each LiveShield has a success number • Invariant enforcement followed by continued successful execution increments number • Attack or crash decrements number • Probability of selection is proportional to success number • Periodically reassign LiveShields to applications

33. Management Console Protection Manager Invariants Invariant Database Server Machine System in Action - Learning Community Machines Invariants

34. System in Action - Monitoring Community Machines Management Console Protection Manager Invariant Database Server Machine

35. System in Action - Monitoring Community Machines Attack Information Management Console Protection Manager Invariant Database Server Machine

36. System in Action – Invariant Localization Community Machines Invariant Checks in LiveShields Management Console Protection Manager Invariants Invariant Database Server Machine

37. System in Action – Invariant Localization Community Machines Invariant Violation Information Attack Information Management Console Protection Manager Invariant Database Server Machine

38. System in Action – Protection Community Machines Repair Distribution Management Console Protection Manager Invariant Database Server Machine

39. System in Action – Protection Community Machines Invariant Violation Information Attack Information Management Console Protection Manager Invariant Database Server Machine

40. System in Action – Protection Community Machines Repair Redistribution Management Console Protection Manager Invariant Database Server Machine

41. System in Action – Protection Community Machines Repair Redistribution Management Console Protection Manager Invariant Database Server Machine

42. System in Action – Protection Community Machines Management Console Protection Manager Invariant Database Server Machine

43. System in Action – Protection Community Machines Management Console Protection Manager Invariant Database Server Machine

44. System in Action – Concrete Example • Learning mode • Key binary variable is target of jsri instruction • Learn a one-of constraint (target is one-of invoked functions) • Monitoring mode • Memory Firewall detects attempt to execute unauthorized function • Invariant localization mode • Attack information identifies jsri instruction as target of attack • Correlates invariant violation with attack • Protection Mode • Distribute range of repairs (skip call, call previously observed function) • Check that they successfully neutralize attack

45. Red Team Exercise • SPARTA is Red Team • Firefox web browser as test application • Attack by loading pages

46. Success Metrics

47. Exploits and Firefox Baseline

48. Single Exploit, Repeated

49. Single Exploit, Multiple Variants After Repair

50. Single Exploit, Multiple Variants During Logging and Repair