Static Analysis of Executables with Applications to Infosec - PowerPoint PPT Presentation

1 / 50
About This Presentation
Title:

Static Analysis of Executables with Applications to Infosec

Description:

Developing infrastructure for analysis and rewriting executables ... Current prototype uses EEL. J.R. Larus and E. Schnarr, PLDI, 1995. 8/26/09 ... – PowerPoint PPT presentation

Number of Views:49
Avg rating:3.0/5.0
Slides: 51
Provided by: jonatho1
Category:

less

Transcript and Presenter's Notes

Title: Static Analysis of Executables with Applications to Infosec


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

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

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

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
8
Our Objective
User Program
  • Our work
  • Detection at system call interface makes our work
    independent of intrusion technique

Event Interface
Operating System
9
Our Objective
  • Snort
  • Detection at service interface limited to
    network-based attacks

User Program
Event Interface
Operating System
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

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.

12
Specification-Based Monitoring
User Program
Analyzer
Runtime Monitor
RewrittenBinary
13
Specification-Based Monitoring
User Program
Analyzer
Rewritten Binary
Runtime Monitor
14
Specification-Based Monitoring
Rewritten Binary
User Program
Event Interface
Operating System
15
Specification-Based Monitoring
Operating System
16
Specification-Based Monitoring
Operating System
17
Specification-Based Monitoring
  • Our runtime monitor monitors program execution at
    the event interface layer
  • Ensures program events match specification

Runtime Monitor
Operating System
18
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
19
Specification-Based Monitoring
  • Event interface defines observable events
  • Observed events may be superset of system calls
  • Expand interface between program and monitor
  • Call-site renaming
  • Null calls

Rewritten Binary
Runtime Monitor
Operating System
20
Specification-Based Monitoring
  • Expanded set of observable events
  • More precise program modeling
  • More efficient model operation
  • User program rewritten to use expanded interface

Rewritten Binary
Expanded Interface
Runtime Monitor
Operating System
21
Model Construction
User Program
Analyzer
Rewritten Binary
Runtime Monitor
Control Flow Graphs
Binary Program
Global Automaton
Local Automata
22
The Binary View (SPARC)
  • 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 lt 0)
  • read(0, 15)
  • line()
  • else
  • read(a, 15)
  • close(a)

23
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

24
Control Flow GraphTranslation
25
Interprocedural ModelGeneration
A
read
read
close
line
26
Interprocedural ModelGeneration
A
read
read
line
write
close
line
27
Interprocedural ModelGeneration
B
A
line
read
read
line
write
close
close
line
28
Interprocedural ModelGeneration
B
A
line
read
read
line
write
close
close
29
Interprocedural ModelGeneration
B
A
read
read
line
write
close
close
30
PossiblePaths
B
A
read
read
line
write
close
close
31
PossiblePaths
B
A
read
read
line
write
close
close
32
ImpossiblePaths
B
A
read
read
line
write
close
close
33
ImpossiblePaths
B
A
read
read
line
write
close
close
34
Adding ContextSensitivity
B
A
read
Y
read
line
X
write
close
close
Y
X
35
PDA State Explosion
  • e-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
36
Dyck LanguageModel
B
A
read
Y
read
line
X
write
close
close
Y
X
37
Dyck LanguageModel
B
A
read
Y
read
line
X
write
close
close
Y
X
38
Dyck LanguageModel
B
A
read
Y
read
line
X
write
close
close
Y
X
39
Rewriting User Job
User Job
Analyzer
Checking Shadow
Modified User Job
Binary Program
Rewritten Binary
40
Null Call Insertion
  • 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

Rewritten Binary
Expanded Interface
Runtime Monitor
Operating System
41
Rewriting User Job
  • function (int a)
  • if (a lt 0)
  • read(0, 15)
  • line()
  • else
  • read(a, 15)
  • close(a)
  • Insert dummy remote system calls around function
    call sites
  • Notify monitor of stack activity

42
Rewriting User Job
  • function (int a)
  • if (a lt 0)
  • read(0, 15)
  • line()
  • else
  • read(a, 15)
  • close(a)
  • Insert dummy remote system calls around function
    call sites
  • Notify monitor of stack activity

43
Rewriting User Job
  • function (int a)
  • if (a lt 0)
  • read(0, 15)
  • X()
  • line()
  • X()
  • else
  • read(a, 15)
  • close(a)
  • Insert dummy remote system calls around function
    call sites
  • Notify monitor of stack activity
  • Null calls are cheap

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

45
Test Programs
Program Number of Instructions
procmail 107,246
gzip 56,710
cat 54,028
ps 59,814
fdformat 67,874
eject 70,177
46
Smart Null Call Insertion
  • Precision metric average branching factor
  • Lower values indicate greater precision

chown
getpid
open
47
(No Transcript)
48
(No Transcript)
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.

50
Static Analysis of Executables withApplications
to Infosec
  • Somesh Jha
  • University of Wisconsin
  • Wisconsin Safety Analyzer
  • http//www.cs.wisc.edu/wisa
Write a Comment
User Comments (0)
About PowerShow.com