Self-defending software:                 g    Automatically patching  errors in deployed software               Michael Er...
Problem: Your code has bugs      and vulnerabilities        d   l    bili i• Attack detectors exist  – Code injection, mem...
ClearView:    Security for legacy software    S    it f l           ftRequirements:1. Protect against unknown vulnerabilit...
1. Unknown vulnerabilities• Proactively prevent attacks via unknown  vulnerabilities  – “Zero day exploits”     Zero-day e...
2. Preserve functionality• Maintain continuity: application  continues to operate despite attacks• For applications that r...
3. Commercial/legacy software• No modification to source or executables• No cooperation required from developers  –CCannot...
Learn from success and failure• Normal executions show what the application  is supposed to do• Each attack (or failure) p...
all executions   Detect, learn, repair                                                      [Lin Ernst                    ...
A deployment of ClearView                                                   Community machines         Server   (Server ma...
Learning normal behavior                                                Community machines  Observe normal behavior  Gener...
Attack detection & suppression                                              Community machines     ServerDetectors used in...
Learning attack behavior                                                           Community machines    What was the effe...
Repair                                     Community machines Propose a set of patches for each behavior that predicts the...
Repair                                      Community machinesDistribute patches to the community     ServerRanking:Patch ...
Repair                                                    Community machines  Evaluate patches  Success = no detector is t...
Repair                                           Community machinesRedistribute the best patches     ServerRanking:Patch 3...
Outline•   Overview•   Learning normal behavior•   Learning attack b h i    L    i    tt k behavior•   Repair: propose and...
Learning normal behavior                                                Community machines  Generalize observed behavior  ...
Dynamic invariant detection• Daikon generalizes observed program executions   Candidate constraints:                   Rem...
Quality of inference results• Not sound  – Overfitting if observed executions are not representative• Not complete  – Temp...
Outline•   Overview•   Learning normal behavior•   Learning attack b h i    L    i    tt k behavior•   Repair: propose and...
Detecting attacks (or bugs)Goal: detect problems close to their sourceCode injection (Determina Memory Firewall)  –T i   T...
Learning from failuresEach attack provides information about the underlying vulnerability  – That it exists  – Where it ca...
Attack detection & suppression                       Community machines  Server                   Detector collects inform...
Learning attack behavior                                                Community machines  Where did the attack happen?  ...
Learning attack behavior                                                         Community machines   Extra checking in at...
Learning attack behavior                                                            Community machines    What was the eff...
Correlating attacks & constraintsCheck constraints only at attack sites  – Low overheadA constraint is predictive of an at...
Outline•   Overview•   Learning normal behavior•   Learning attack b h i    L    i    tt k behavior•   Repair: propose and...
Repair                                        Community machines  Distribute patches to the community  Success = no detect...
Attack example• Target: JavaScript system routine (written in C++)  – C t it argument to a C++ object, calls a virtual met...
Repair exampleif (! ( py_len ≤ buff_size))   ( (copy                ))   copy_len = buff_size;• The repair checks the pred...
Example constraints & repairsv1 ≤ v2   if (!(v1≤v2)) v1 = v2;v≥c   if (!(v≥c)) v = c;v ∈ { c1, c2, c3 }   if (!(v==c1 || v...
Evaluating a patch• In-field evaluation   – No attack detector is triggered   – No other behavior deviations      • E g cr...
Outline•   Overview•   Learning normal behavior•   Learning attack b h i    L    i    tt k behavior•   Repair: propose and...
Red Team• Red Team attempts to break our system  – Hired by DARPA; 10 engineers• Red Team created 10 Firefox exploits  – E...
Rules of engagement• Firefox 1.0  – ClearView may not be tuned to known    vulnerabilities  –FFocus on most security-criti...
ClearView was successful• Detected all attacks prevented all exploits               attacks,• For 7/10 vulnerabilities, ge...
3 un repaired vulnerabilities    un-repairedConsequence: Application crashes when  attacked. No exploit occurs.1. ClearVie...
Outline•   Overview•   Learning normal behavior•   Learning attack b h i    L    i    tt k behavior•   Repair: propose and...
LimitationsClearView might fail to repair an error:  – Only fixes errors for which a detector exists  – Daikon might not l...
Related work• Attack detection: ours are mostly standard  – Distributed: Vigilante [Costa], live monitoring    [Kıcıman], ...
Credits•   Saman Amarasinghe      •   Jeff Perkins•   Jonathan Bachrach      •   Martin Rinard•   Michael Carbin         •...
ContributionsClearView: framework for patch generation  – Pluggable detection, learning, repair1.1 Protects against unknow...
Upcoming SlideShare
Loading in …5
×

Self-defending software: Automatically patching errors in deployed software (SOSP 2009)

845
-1

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
845
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Self-defending software: Automatically patching errors in deployed software (SOSP 2009)

  1. 1. Self-defending software: g Automatically patching errors in deployed software Michael Ernst University of Washington Joint work with: Saman Amarasinghe, Jonathan Bachrach,Michael C bi Sung Ki SMi h l Carbin, S Kim, Samuel Ll Larsen,Carlos Pacheco, Jeff Perkins, Martin Rinard, Frank Sh F k Sherwood, St li Sidi l d Stelios Sidiroglou, G Greg Sullivan, Weng-Fai Wong, Yoav Zibin
  2. 2. Problem: Your code has bugs and vulnerabilities d l bili i• Attack detectors exist – Code injection, memory errors (buffer overrun)• Reaction: – Crash the application • Loss of data • Overhead of restart • Attack recurs • Denial of service – Automatically patch the application
  3. 3. ClearView: Security for legacy software S it f l ftRequirements:1. Protect against unknown vulnerabilities2. Preserve f2 P functionality ti lit3. Commercial & legacy software
  4. 4. 1. Unknown vulnerabilities• Proactively prevent attacks via unknown vulnerabilities – “Zero day exploits” Zero-day exploits – No pre-generated signatures – No hard-coded fixes hard coded – No time for human reaction – W k for bugs as well as attacks Works f b ll tt k
  5. 5. 2. Preserve functionality• Maintain continuity: application continues to operate despite attacks• For applications that require high availability – Important for mission-critical applications – Web servers, air traffic control, communications• Technique: create a patch ( p (repair the application) pp ) – Patching is a valuable option for your toolbox
  6. 6. 3. Commercial/legacy software• No modification to source or executables• No cooperation required from developers –CCannot assume b ilt i survivability f t t built-in i bilit features – No source information (no debug symbols)• x86 Windows binaries
  7. 7. Learn from success and failure• Normal executions show what the application is supposed to do• Each attack (or failure) provides information about the underlying vulnerability• R Repairs i i improve over ti time – Eventually, the attack is rendered harmless – Similar to an immune system• Detect all attacks (of given types) – Prevent negative consequences – First few attacks may crash the application
  8. 8. all executions Detect, learn, repair [Lin Ernst [Li & E t 2003] Pluggable detector, Attack does not depend on learning detector normal attacksexecutions (or bugs) • Learn normal behavior (constraints) Learning from successful runs • Check constraints during attacks predictive • True on every good run constraints • False during every attack Repair • Patch to re-establish constraints • Evaluate and distribute patches patch Restores normal behavior
  9. 9. A deployment of ClearView Community machines Server (Server may be replicated, distributed, etc.)Threat model does not (yet!)include malicious nodes Encrypted, authenticated communication
  10. 10. Learning normal behavior Community machines Observe normal behavior Generalize observed behavior Server … copy_len ≤ buff_size …Server generalizes Clients send(merges results) inference results Clients do local inference
  11. 11. Attack detection & suppression Community machines ServerDetectors used in our research: – Code injection (Memory Firewall) – Memory corruption (Heap Guard)Many other possibilities exist Detector collects information and terminates application
  12. 12. Learning attack behavior Community machines What was the effect of the attack? Server Clients send difference inServer correlates behavior: violated constraints Instrumentation continuouslyconstraints to attack evaluates learned behavior
  13. 13. Repair Community machines Propose a set of patches for each behavior that predicts the attack p Server Predictive: copy len ≤ buff_size py_ Candidate patches: 1. Set copy_len = buff_size 2. Set copy len = 0 py_ 3. Set buff_size = copy_len 4. Return from procedureServer generatesa set of patches
  14. 14. Repair Community machinesDistribute patches to the community ServerRanking:Patch 1:P t h1 0Patch 2: 0Patch 3: 0…
  15. 15. Repair Community machines Evaluate patches Success = no detector is triggered gg Server Ranking: Patch 3: 5 P t h 3 +5 Patch 2: 0 Patch 1: -5 … When attacked, clients send outcome to server Detector is stillServer ranks patches running on clients
  16. 16. Repair Community machinesRedistribute the best patches ServerRanking:Patch 3: 5P t h 3 +5Patch 2: 0 Patch 3Patch 1: -5… Server redistributes the most effective patches
  17. 17. Outline• Overview• Learning normal behavior• Learning attack b h i L i tt k behavior• Repair: propose and evaluate patches• Evaluation: adversarial Red Team exercise• Conclusion
  18. 18. Learning normal behavior Community machines Generalize observed behavior Server … copy_len ≤ buff_size … Clients sendServer generalizes inference results(merges results) Clients do local inference
  19. 19. Dynamic invariant detection• Daikon generalizes observed program executions Candidate constraints: Remaining candidates: copy_len < buff_size Observation: copy_len < buff_size copy_len ≤ buff_size copy_len: 22 copy_len ≤ buff_size copy_len = b ff i l buff_size buff_size: 42 ff copy_len = b ff i l buff_size copy_len ≥ buff_size copy_len ≥ buff_size copy_len > buff_size copy_len > buff_size copy len ≠ buff_size py_ copy len ≠ buff_size py_• Many optimizations for accuracy and speed – Data structures, code analysis, statistical tests, …• We further enhanced the technique q
  20. 20. Quality of inference results• Not sound – Overfitting if observed executions are not representative• Not complete – Templates are not exhaustive• Useful!• Unsoundness is not a hindrance – Does not affect attack detection – For repair, mitigated by the correlation step – Continued learning improves results
  21. 21. Outline• Overview• Learning normal behavior• Learning attack b h i L i tt k behavior• Repair: propose and evaluate patches• Evaluation: adversarial Red Team exercise• Conclusion
  22. 22. Detecting attacks (or bugs)Goal: detect problems close to their sourceCode injection (Determina Memory Firewall) –T i Triggers if control j t l jumps t code th t was not to d that t in the original executableMemory corruption (HM ti (Heap G d) Guard) – Triggers if sentinel values are overwrittenThese have low overhead and no false positivesOther detectors are possible
  23. 23. Learning from failuresEach attack provides information about the underlying vulnerability – That it exists – Where it can be exploited – How the exploit operates – What repairs are successful
  24. 24. Attack detection & suppression Community machines Server Detector collects information and terminates application
  25. 25. Learning attack behavior Community machines Where did the attack happen? scanf Server read_input p process_record _ mainDetector maintainsa shadow call stack Client sends attack info to server Detector collects information and terminates application
  26. 26. Learning attack behavior Community machines Extra checking in attacked code Check the learned constraints Server scanf read_input process_record mainServer generates Server sends instru-instrumentation for mentation to all clientstargeted code locations Clients install instrumentation
  27. 27. Learning attack behavior Community machines What was the effect of the attack? Server Predictive: copy_len ≤ buff_size Clients send difference inServer correlates behavior: violated constraints Instrumentation continuouslyconstraints to attack evaluates inferred behavior
  28. 28. Correlating attacks & constraintsCheck constraints only at attack sites – Low overheadA constraint is predictive of an attack if: – The constraint is violated iff the attack occursCreate repairs for each predictive constraint – Re-establish normal behavior
  29. 29. Outline• Overview• Learning normal behavior• Learning attack b h i L i tt k behavior• Repair: propose and evaluate patches• Evaluation: adversarial Red Team exercise• Conclusion
  30. 30. Repair Community machines Distribute patches to the community Success = no detector is triggered gg Server Ranking: Patch 1: P t h1 0 Patch 2: 0 Patch 3: 0 …Patch evaluation usesadditional detectors(e.g., crash, difference in attack)
  31. 31. Attack example• Target: JavaScript system routine (written in C++) – C t it argument to a C++ object, calls a virtual method Casts its tt C bj t ll it l th d – Does not check type of the argument• Attack supplies an “object” whose virtual table object points to attacker-supplied code• Predictive constraint at the method call: – JSRI address target is one of a known set• Possible repairs: – Call one of the known valid methods – Skip over the call p – Return early
  32. 32. Repair exampleif (! ( py_len ≤ buff_size)) ( (copy )) copy_len = buff_size;• The repair checks the predictive constraint – If constraint is not violated, no need to repair – If constraint i violated, an attack is (probably) underway t i t is i l t d tt k i ( b bl ) d• The patch does not depend on the detector – Should fix the problem before the detector is triggered• Repair is not identical to what a human would write – Unacceptable to wait for human response
  33. 33. Example constraints & repairsv1 ≤ v2 if (!(v1≤v2)) v1 = v2;v≥c if (!(v≥c)) v = c;v ∈ { c1, c2, c3 } if (!(v==c1 || v==c2 || v==c3)) v = ci;Return from enclosing procedure if (!(…)) return;Modify a use: convert “call *v” to if (…) call *v; Constraint on v (not negated)
  34. 34. Evaluating a patch• In-field evaluation – No attack detector is triggered – No other behavior deviations • E g crash application invariants E.g., crash,• Pre-validation, before distributing the patch: • Replay the attack + No N need t wait f a second attack d to it for d tt k + Exactly reproduce the problem – Expensive to record log; log terminates abruptly – Need to prevent irrevocable effects – Delays distribution of good patches • Run the program’s test suite – May be too sensitive – Not available for commercial software
  35. 35. Outline• Overview• Learning normal behavior• Learning attack b h i L i tt k behavior• Repair: propose and evaluate patches• Evaluation: adversarial Red Team exercise• Conclusion
  36. 36. Red Team• Red Team attempts to break our system – Hired by DARPA; 10 engineers• Red Team created 10 Firefox exploits – Each exploit is a webpage – Firefox executes arbitrary code – Malicious JavaScript, GC errors, stack smashing, heap buffer overflow, uninitialized memory
  37. 37. Rules of engagement• Firefox 1.0 – ClearView may not be tuned to known vulnerabilities –FFocus on most security-critical components t it iti l t • No access to a community for learning• Red Team has access to all ClearView materials – Source code, documents, learned invariants, …
  38. 38. ClearView was successful• Detected all attacks prevented all exploits attacks,• For 7/10 vulnerabilities, generated a patch that maintained functionality – No observable deviation from desired behavior – Aft an average of 4.9 minutes and 5.4 attacks After f49 i t d 5 4 tt k• Handled polymorphic attack variants• Handled simultaneous & intermixed attacks• No false positives• Low overhead for detection & repair
  39. 39. 3 un repaired vulnerabilities un-repairedConsequence: Application crashes when attacked. No exploit occurs.1. ClearView was mis-configured: didn’t try repairs in all procedures on the stack2. Learning suite was too small: a needed constraint was not statistically significant3. A needed constraint was not built into Daikon
  40. 40. Outline• Overview• Learning normal behavior• Learning attack b h i L i tt k behavior• Repair: propose and evaluate patches• Evaluation: adversarial Red Team exercise• Conclusion
  41. 41. LimitationsClearView might fail to repair an error: – Only fixes errors for which a detector exists – Daikon might not learn a needed constraint – Predictive constraint may be too far from error – Built-in repairs may not be sufficient p yClearView might degrade the application: – Patch may impair functionality y p y – Attacker may subvert patch – Malicious nodes may induce bad p y patchesBottom line: Red Team tried unsuccessfully
  42. 42. Related work• Attack detection: ours are mostly standard – Distributed: Vigilante [Costa], live monitoring [Kıcıman], statistical bug isolation [Liblit]• L Learning i – FSMs of system calls for anomaly detection – Invariants: [Lin], [Demsky], Gibraltar [Baliga] [Lin] [Demsky] – System configuration: FFTV [Lorenzoli], Dimmunix [Jula] [ ]• Repair & failure tolerance – Checkpoint and replay: Rx [Qin], microreboot [Candea] [C d ] – Failure-oblivious [Rinard], ASSURE [Sidiroglou]
  43. 43. Credits• Saman Amarasinghe • Jeff Perkins• Jonathan Bachrach • Martin Rinard• Michael Carbin • Frank Sherwood• Michael Ernst • Stelios Sidiroglou• Sung Kim • Greg Sullivan• Samuel Larsen • Weng-Fai Wong• Carlos Pacheco • Yoav ZibinSubcontractor: Determina, Inc.Funding: DARPA (PM: Lee Badger)Red Team: SPARTA, Inc.
  44. 44. ContributionsClearView: framework for patch generation – Pluggable detection, learning, repair1.1 Protects against unknown vulnerabilities – Learns from success – Learns from failure: what, where, how – Learning focuses effort where it is needed2.2 Preserves functionality: repairs the vulnerability3.3 Commercial software: Windows binariesEvaluation via a Red Team exercise
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×