Learning, Monitoring, and Repair in Application Communities

1. Learning, Monitoring, and Repair in Application Communities Martin Rinard Computer Science and Artificial Intelligence Laboratory Massachusetts Institute of Technology

2. Goal Structure of implemented system How it works Planned developments for future

3. 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

4. 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

5. 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)

6. 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)

7. 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

8. 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)

9. 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)

10. 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)

11. 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

12. 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

13. 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)

14. 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

15. 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

16. 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)

17. 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

18. 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

19. Using LiveShield Mechanism • Protection manager selects invariants to check • Generates C code that implements check • Passes C code to scripts • Compile the code • Generate patch • Sign it, convert to LiveShield format • Distribute LiveShields back to applications • Each application gets all LiveShields • Goal is to maximize checking information

20. 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

21. 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)

22. 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

23. 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

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

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

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

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

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

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

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

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

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

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

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

35. 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

36. Attack Surface Issues • Determina Runtime as attack target • Addressed with page protection policies • Also randomize placement • Runtime data • Runtime code, code cache

37. Communication Issues • What about forged communications? • Management console has certificate authority • Clients use password to get certificates • All communications • Signed, authenticated, encrypted • Revocation if necessary Management Console Certificate Authority Invariant Database

38. Status • Architecture implemented and tested • Components exist • Communication implemented, operational • Determina Memory Firewall as attack detector • One-of invariants on function pointers (demo)

39. Parameterized Architecture and Implementation • Parameterization points • Attack signal • Invariants • Inference • Enforcement mechanisms • Flexibility in implementation strategies • Invariant localization strategies • Invariant repair strategies

40. Class of Attacks Prerequisites for stopping an attack • Attack characteristics • Attack signal • Attack must violate invariants • Enforcing invariants must neutralize attack • Invariant characteristics • Daikon must recognize invariants • System must be able to successfully repair violations of invariants

41. Examples of Attacks We Can Stop • Function pointer • Attack signal – Determina Memory Firewall • Invariant • One-of invariant • Function pointer binary variable • Repair • Jump to previously seen function • Skip call

42. Examples of Attacks We Can Stop • Code injection attacks via stack overwriting • Attack signal – Determina Memory Firewall • Invariant • Less than invariant • Stack pointer binary variable • Repair • Skip writes via binary variable • Coerce binary variable back into range

43. Future Evolution • Exploit parameterization capabilities • More sophisticated invariants • Data structure inference • Sequences of program actions • More sophisticated repairs • More sophisticated attack signals • Detect more subtle attacks • Program keeps executing • Executes legitimate code only • Use invariant violation as attack signal