1 / 50

Static Analysis of Executables with Applications to Infosec

Static Analysis of Executables with Applications to Infosec. Somesh Jha University of Wisconsin Wisconsin Safety Analyzer http://www.cs.wisc.edu/wisa. Various Tasks. Developing infrastructure for analysis and rewriting executables Initial focus on x86 and infosec applications

loyal
Download Presentation

Static Analysis of Executables with Applications to Infosec

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. Static Analysis of Executables withApplications to Infosec Somesh Jha University of Wisconsin Wisconsin Safety Analyzer http://www.cs.wisc.edu/wisa

  2. Various Tasks • Developing infrastructure for analysis and rewriting executables • Initial focus on x86 and infosec applications • Applications to host-based intrusion detection • Malicious code detection • Attacking virus scanners • Better malicious code detection techniques • Foundations • Framework for interprocedural analysis • Applications to “identifying structure” in activation records Somesh Jha, UW-Madison

  3. Goal: Discover attempts to maliciously gain access to a system • Misuse Detection • Specify patterns ofattack or misuse • Ensure misuse patternsdo not arise at runtime • Snort • Rigid: cannot adaptto novel attacks • Anomaly Detection • Learn typical behaviorof application • Variations indicatepotential intrusions • IDES • High false alarm rate • Specification-Based • Monitoring • Specify constraints uponprogram behavior • Ensure execution doesnot violate specification • Our work; Ko, et. al. • Specifications can becumbersome to create Somesh Jha, UW-Madison

  4. Worldview • User desires to run program • Running program makes operating system requests • Attacker uses running program to generate malicious requests User Program Event Interface Operating System Somesh Jha, UW-Madison

  5. Worldview • Attack goal: be creative… • Destruction • Information leaks • Service disruption • Attack technique: run arbitrary code in the user program • Buffer overrun • Virus or worm • Manipulate remote execution User Program Event Interface Operating System Somesh Jha, UW-Madison

  6. Example: SQL Slammer • Worm activated January 2003 • Caused worldwide service disruption • Propagation: exploited buffer overrun in Microsoft SQL Server to execute arbitrary code • Detection: SQL Server makes unexpected system calls • Arbitrary code differs from SQL code Somesh Jha, UW-Madison

  7. Our Objective • Detect malicious activity before harm caused to local machine • … before operating system executes malicious system call User Program Event Interface Operating System Somesh Jha, UW-Madison

  8. Our Objective Our work • Detection at system call interface makes our work independent of intrusion technique User Program Event Interface Operating System Somesh Jha, UW-Madison

  9. Our Objective Snort • Detection at service interface: limited to network-based attacks User Program Event Interface Operating System Somesh Jha, UW-Madison

  10. Specification-Based Monitoring • Specify constraints upon program behavior • Construct automaton accepting all system call sequences the program can generate • First suggested by Wagner-Dean, Oakland, 2000 (static analysis of source code) • Our analysis is on binaries • Ensure execution does not violate specification • Operate the automaton • If no valid states, then intrusion attempt occurred Somesh Jha, UW-Madison

  11. An Application of Binary Analysis/Rewriting Infrastructure • Binary analysis • Construct model for host-based intrusion detection • Binary rewriting • Rewrite binary to expose more information about the program • Makes the model more precise • Current prototype uses EEL • J.R. Larus and E. Schnarr, PLDI, 1995. Somesh Jha, UW-Madison

  12. Specification-Based Monitoring User Program Analyzer RewrittenBinary Runtime Monitor Somesh Jha, UW-Madison

  13. Specification-Based Monitoring User Program Analyzer Rewritten Binary Runtime Monitor Somesh Jha, UW-Madison

  14. Runtime Monitor Specification-Based Monitoring Rewritten Binary User Program Event Interface Operating System Somesh Jha, UW-Madison

  15. Runtime Monitor Rewritten Binary Event Interface Event Interface Specification-Based Monitoring Operating System Somesh Jha, UW-Madison

  16. Runtime Monitor Rewritten Binary Event Interface Event Interface Specification-Based Monitoring Operating System Somesh Jha, UW-Madison

  17. Rewritten Binary Event Interface Event Interface Specification-Based Monitoring • Our runtime monitor monitors program execution at the event interface layer • Ensures program events match specification Runtime Monitor Operating System Somesh Jha, UW-Madison

  18. Rewritten Binary Event Interface Event Interface Specification-Based Monitoring • Our runtime monitor monitors program execution at the event interface layer • Ensures program events match specification • Runtime monitor must be part of trusted computing base Runtime Monitor Operating System Trusted computing base Somesh Jha, UW-Madison

  19. Event interface defines observable events Observed events may be superset of system calls Expand interface between program and monitor Call-site renaming Null calls Event Interface Event Interface Specification-Based Monitoring Rewritten Binary Runtime Monitor Operating System Somesh Jha, UW-Madison

  20. Expanded set of observable events More precise program modeling More efficient model operation User program rewritten to use expanded interface Event Interface Specification-Based Monitoring Rewritten Binary Expanded Interface Runtime Monitor Operating System Somesh Jha, UW-Madison

  21. Model Construction User Program Analyzer Runtime Monitor Rewritten Binary Control Flow Graphs Binary Program Global Automaton Local Automata Somesh Jha, UW-Madison

  22. function: save %sp, 0x96, %sp cmp %i0, 0 bge L1 mov 15, %o1 call read mov 0, %o0 call line nop b L2 nop L1: call read mov %i0, %o0 call close mov %i0, %o0 L2: ret restore function (int a) { if (a < 0) { read(0, 15); line(); } else { read(a, 15); close(a); } } The Binary View (SPARC) Somesh Jha, UW-Madison

  23. CFG ENTRY bge call read call read call line call close ret CFG EXIT Control Flow Graph Generation function: save %sp, 0x96, %sp cmp %i0, 0 bge L1 mov 15, %o1 call read mov 0, %o0 call line nop b L2 nop L1: call read mov %i0, %o0 call close mov %i0, %o0 L2: ret restore Somesh Jha, UW-Madison

  24. CFG ENTRY bge read read call read call read call line call close close line ret CFG EXIT Control Flow GraphTranslation Somesh Jha, UW-Madison

  25. Interprocedural ModelGeneration A read read close line Somesh Jha, UW-Madison

  26. Interprocedural ModelGeneration A read read line write close line Somesh Jha, UW-Madison

  27. Interprocedural ModelGeneration B A line read read line write close close line Somesh Jha, UW-Madison

  28. Interprocedural ModelGeneration B A line read read line write close close Somesh Jha, UW-Madison

  29. Interprocedural ModelGeneration B A read read line write close close Somesh Jha, UW-Madison

  30. PossiblePaths B A read read line write close close Somesh Jha, UW-Madison

  31. PossiblePaths B A read read line write close close Somesh Jha, UW-Madison

  32. ImpossiblePaths B A read read line write close close Somesh Jha, UW-Madison

  33. ImpossiblePaths B A read read line write close close Somesh Jha, UW-Madison

  34. Adding ContextSensitivity B A read read Y line X write close close Y X Somesh Jha, UW-Madison

  35. PDA State Explosion • ε-edge identifiers maintained on a stack • Stack may grow to be unbounded • Solution: • Dyck language model • Stack operations visible in call stream • Requires binary rewriting X Somesh Jha, UW-Madison

  36. Dyck LanguageModel B A read read Y line X write close close Y X Somesh Jha, UW-Madison

  37. Dyck LanguageModel B A read read Y line X write close close Y’ X’ Somesh Jha, UW-Madison

  38. Dyck LanguageModel B A read read Y line X write close close Y’ X’ Somesh Jha, UW-Madison

  39. Rewriting User Job User Job Analyzer Checking Shadow Modified User Job Binary Program Rewritten Binary Somesh Jha, UW-Madison

  40. Null calls are dummy system calls Part of the expanded interface Used by the monitor to update the model Do not cross the interface to the operating system Event Interface Null Call Insertion Rewritten Binary Expanded Interface Runtime Monitor Operating System Somesh Jha, UW-Madison

  41. Insert dummy remote system calls around function call sites Notify monitor of stack activity function (int a) { if (a < 0) { read(0, 15); line(); } else { read(a, 15); close(a); } } Rewriting User Job Somesh Jha, UW-Madison

  42. Insert dummy remote system calls around function call sites Notify monitor of stack activity function (int a) { if (a < 0) { read(0, 15); line(); } else { read(a, 15); close(a); } } Rewriting User Job Somesh Jha, UW-Madison

  43. Insert dummy remote system calls around function call sites Notify monitor of stack activity Null calls are cheap function (int a) { if (a < 0) { read(0, 15); X(); line(); X’(); } else { read(a, 15); close(a); } } Rewriting User Job Somesh Jha, UW-Madison

  44. Dyck Language Model Theory • Language accepted is bracketed context-free language [Ginsberg, Harrison] • Subsequences of null calls form a Dyck language [Chomsky, Scheutzenberger] • Dyck languages as powerful as CFL LCFL = h(LDyck LReg) [Chomsky] Somesh Jha, UW-Madison

  45. Test Programs Somesh Jha, UW-Madison

  46. Smart Null Call Insertion • Precision metric: average branching factor • Lower values indicate greater precision chown getpid open Somesh Jha, UW-Madison

  47. Somesh Jha, UW-Madison

  48. Somesh Jha, UW-Madison

  49. Important Ideas • Attackers exploit code vulnerabilities to execute arbitrary, malicious code. • Pre-execution static analysis to construct a model of the system call sequences addresses this threat. • The Dyck model effectively balances model accuracy and runtime cost. Somesh Jha, UW-Madison

  50. Static Analysis of Executables withApplications to Infosec Somesh Jha University of Wisconsin Wisconsin Safety Analyzer http://www.cs.wisc.edu/wisa

More Related