detecting past and present intrusions through vulnerability specific predicates n.
Skip this Video
Loading SlideShow in 5 Seconds..
Detecting Past and Present Intrusions through Vulnerability-Specific Predicates PowerPoint Presentation
Download Presentation
Detecting Past and Present Intrusions through Vulnerability-Specific Predicates

play fullscreen
1 / 20
Download Presentation

Detecting Past and Present Intrusions through Vulnerability-Specific Predicates - PowerPoint PPT Presentation

odessa
114 Views
Download Presentation

Detecting Past and Present Intrusions through Vulnerability-Specific Predicates

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Detecting Past and Present Intrusions through Vulnerability-Specific Predicates Ashlesha Joshi, Samuel T. King, George W. Dunlap, Peter M. Chen (SOSP-2005)

  2. vulnerability introduced vulnerability discovered patch released patch applied Motivation • Red time interval: window of vulnerability during which exploit is possible • Prompt patching makes this interval smaller, but cannot eliminate it • What to do in what’s left of window of vulnerability?

  3. vulnerability introduced vulnerability discovered patch released patch applied IntroVirt • Use vulnerability-specific, perturbation-free predicates to detect the triggering of a vulnerability • For “past” time interval, combine predicates with VM replay • For “present” time interval, combine predicates with a response strategy

  4. Vulnerabilities-Specific Predicates • Why vulnerabilities-specific? • char *str = some_string; • int len = strlen(str); • char buf[BUFSIZE]; • strcpy(buf, str); (len >= BUFSIZE)

  5. Goals • Predicates must not perturb the target state • Predicates should be able to check applications and OS • Installing new predicates should not shut down the target software • Predicates should be easy to write • Predicates should execute with low overhead

  6. Design Challenge I: Where do Predicates Execute? • Problems: • Cannot perturb the target state • Both the application and OS vulnerabilities • Run the target software inside a VM • Run the predicates outside this VM • Control VM execution: • Register for events notification via function name or source code line (software breakpoints)

  7. Design Challenge II: Semantic Gap Between Predicates and VM • Problems: • Gap between the abstraction predicate writers would use and the abstraction exposed by VMM • Examples: • 1. strlen = 3 (predicate writers), (0x08040300) = 3 (VMM) • 2. authentication, decryption, etc. • Translate symbolic information to numeric values using debug information • Leverage Guest Functionality

  8. Design Challenge III: Avoiding Perturbations to Target State • Problems: • Invoke existing code  modify the target state • Cause the target to send out a message • Cause the target to hang • Checkpoint and Rollback • Others • Output supression • Timeout on predicates execution

  9. Design Challenge IV: Preemptions between the Predicate and the Bug • Problem: • Predicate Refresh • Re-check the predicates when the target process is scheduled out/in • 1 If (access(file, W_OK)) { • unlink(file); • } access(file, W_OK)

  10. More Details: Difficulties for Applications • Process Creation and Termination  complicate maintaining breakpoints • Virtual page may not be mapped to a physical page  complicate maintaining breakpoints  complicate application data access

  11. Evaluation • Revisit the goals • Predicates must not perturb the target state • Predicates should be able to check applications and OS • Installing new predicates should not shut down the target software • Predicates should be easy to write • Predicates should execute with low overhead (< 500 microsec) ? ?

  12. An Example Predicate Patch: if ((addr + len) > TASK_SIZE) || (addr + len) < addr) return –EINVAL; Predicate: #define TASK_SIZE 0xc0000000 void brkEventHandler() { unsigned long addr = readVar(“addr”); unsigned long len = readVar(“len”); if ((addr + len) > TASK_SIZE) || (addr + len) < addr) // use “alert” response strategy cout << “brk bug triggerred” << endl; }

  13. Vulnerabilities and Predicates

  14. Performance • Relative to a UML guest on Revirt without predicates or the predicate engine • Most security vulnerabilities examined occur on infrequent code path  no measurable overhead • Measured three frequently executed predicates in: • do_brk(): 810 times/sec  4% • openssl : 96 times/sec  1% • find : 21 times/sec  25% (taking&restoring checkpoints) • combined: 10%

  15. Conclusion & Discussion • Vulnerability-specific predicates can help improve security for both the past and present time interval • Can we use predicates for other purposes? • Does predicate refresh work for multiprocessors? • Any perturbation to target software? • Results from guest functions may be environment- dependent?

  16. Examples of Vulnerabilities • Can be checked by predicates

  17. Performance (II) • UML adds overhead 15-76% for system call intensive workloads (SPECweb99 and compiling a kernel) • Overhead for VM replaying is less than 10%