1 / 16

High Coverage Detection of Input-Related Security Faults

High Coverage Detection of Input-Related Security Faults. Eric Larson and Todd Austin August 7, 2003 University of Michigan. Introduction. Failing to properly bound input data can be exploited by malicious users bugs found in Windows especially important for network data

dex
Download Presentation

High Coverage Detection of Input-Related Security Faults

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. High Coverage Detection of Input-Related Security Faults Eric Larson and Todd Austin August 7, 2003 University of Michigan

  2. Introduction • Failing to properly bound input data can be exploited by malicious users • bugs found in Windows • especially important for network data • Common security exploits • array references • string library functions • Exploitable bugs are often difficult to find • precise input is often necessary to expose the bug • bug may not produce an error in the output

  3. Static vs. Dynamic Bug Finding Approaches • Compile-time (static) bug detection + no dependence on input + can prove that a particular operation is safe in some cases • often computationally infeasible  scope is limited • Run-time (dynamic) bug detection + can analyze all variables (including those on the heap) + execution is on a real path  fewer false alarms • depends on program input

  4. Overview of Our Approach • Dynamic approach to detecting input-related security faults • Program instrumentation tracks input derived data • possible range of integer variables • maximum size and termination of strings • Dangerous operations are checked over entire range of possible values • Found 16 bugs in 8 programs, including 2 known high security faults in OpenSSH Relaxes constraint that the user provides an input that exposes the bug

  5. Source Code Debug and fix errors Instrumentation specification Compile (GCC w/MUSE) Error reports Run test suite Instrumented Executable Testing Process

  6. Detecting Array Buffer Overflows • Interval constraint variables are introduced when external inputs are read • Holds the lower and upper bounds of each input value • Initial values encompass the entire range of values • Control points narrow the bounds • Arithmetic operations adjust the bounds • Potentially dangerous operations are checked: • array indexing • controlling a loop (to prevent DoS attacks) • arithmetic operations (overflow)

  7. Array Buffer Overflow Example ERROR! When x = 5, array reference is out of bounds!

  8. Detecting Dangerous String Operations • Strings are shadowed by: • max_str_size: largest possible size of the string • known_null: set if string is known to contain a null character • Checking string operations: • source string will fit into the destination • source strings are guaranteed to be null terminated • Integers that store string lengths are shadowed by: • base address of corresponding string • difference between its value and actual string length • Operations involving a string length can narrow the maximum string size

  9. ERROR! temp may not be null terminated during strcpy String Fault Detection Example

  10. ERROR! src may not fit into dest during strcpy String Fault Detection Example

  11. Implementation • Our technique was implemented in MUSE • general-purpose instrumentation tool • implemented in gcc at the abstract syntax tree (AST) level • simplification phase removes C nuances • instrumented code is not optimized (future work) • Shadowed state for stored in hash tables • separate tables for arrays and integers • hash tables are indexed by address • pointers are shadowed by base address • Debug tracing mode can help find source of error

  12. Results

  13. Performance Results

  14. Future Work • Improve performance by eliminating unnecessary instrumentation calls • Interprocedural dataflow analysis will determine which variables never hold input data • Inline instrumentation to avoid call overhead and hash table lookups • Add symbolic analysis support to find more defects and reduce false alarms • Address these common scenarios: • pointer walking (manual string handling) • multiple string concatenation into a single buffer

  15. Conclusion • Our dynamic approach shadows variables derived from input with additional state • Integers: upper and lower bounds • Strings: maximum string size and known null flag • Found 16 bugs in 8 programs • 2 known high security faults in OpenSSH • Run-time performance overhead is high • Instrumentation has not been optimized

  16. Questions and Answers

More Related