1 / 20

Detecting Past and Present Intrusions through Vulnerability-Specific Predicates

Detecting Past and Present Intrusions through Vulnerability-Specific Predicates. Ashlesha Joshi, Samuel T. King, George W. Dunlap, Peter M. Chen (SOSP-2005). vulnerability introduced. vulnerability discovered. patch released. patch applied. Motivation.

odessa
Download Presentation

Detecting Past and Present Intrusions through Vulnerability-Specific Predicates

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

More Related