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 Tracing Client Library Determina MPEE Application Local Daikon Node Manager Central Daikon Management Console Invariant Database Trace Data Invariants Invariant Updates (https/ssl) Community MachineServer Machine

6. What Is Trace Data? Sequence of observations 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 and Client Library Application (binary) Basic Block Checking And Transformation Basic Block Checked, Transformed Basic Block Code Cache PC In learning mode Basic blocks are transformed to print out trace data

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

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

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

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 Client Library Determina MPEE Application Node Manager Protection Manager Management Console Attack Information (https/ssl) Community MachineServer Machine Attack Detection

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 Attack & Invariant Violation Detector Client Library Determina MPEE Application Node Manager Protection Manager Management Console Invariant Database Attack & Invariant Information Invariants (https/ssl) Community MachineServer Machine LiveShield Generation LiveShield Installation LiveShields

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 Client Library Determina MPEE Application Node Manager Protection Manager Management Console Invariant Database Attack & Invariant Information Invariants (https/ssl) Community MachineServer Machine LiveShield Generation LiveShield Installation LiveShields Attack Detector & Invariant Enforcement

22. 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. System in Action - Learning Community Machines Invariants Invariant Database Protection Manager Management Console Server Machine Invariants

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

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

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

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

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

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

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

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

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

34. System in Action – Protection Community Machines Invariant Database Protection Manager Management Console 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 Page TypeRuntime ModeApplication Mode App codeRR App dataRW Runtime codeRER Code CacheRWRE Runtime dataRWR

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 Invariant Database Management Console Certificate Authority

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