1 / 57

Application Communities Phase II Overview

Application Communities Phase II Overview. Martin Rinard Computer Science and Artificial Intelligence Laboratory Massachusetts Institute of Technology. Computing Monoculture. Windows Office Firefox. Windows Office Firefox. Windows Office Firefox. Windows Office Firefox. Windows

benson
Download Presentation

Application Communities Phase II Overview

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related