Title: Static Analysis of Executables with Applications to Infosec
1Static Analysis of Executables withApplications
to Infosec
- Somesh Jha
- University of Wisconsin
- Wisconsin Safety Analyzer
- http//www.cs.wisc.edu/wisa
2Various 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
4Worldview
- 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
5Worldview
- 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
6Example 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
7Our Objective
- Detect malicious activity before harm caused to
local machine - before operating system executes malicious
system call
User Program
Event Interface
Operating System
8Our Objective
User Program
- Our work
- Detection at system call interface makes our work
independent of intrusion technique
Event Interface
Operating System
9Our Objective
- Snort
- Detection at service interface limited to
network-based attacks
User Program
Event Interface
Operating System
10Specification-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
11An 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.
12Specification-Based Monitoring
User Program
Analyzer
Runtime Monitor
RewrittenBinary
13Specification-Based Monitoring
User Program
Analyzer
Rewritten Binary
Runtime Monitor
14Specification-Based Monitoring
Rewritten Binary
User Program
Event Interface
Operating System
15Specification-Based Monitoring
Operating System
16Specification-Based Monitoring
Operating System
17Specification-Based Monitoring
- Our runtime monitor monitors program execution at
the event interface layer - Ensures program events match specification
Runtime Monitor
Operating System
18Specification-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
19Specification-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
20Specification-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
21Model Construction
User Program
Analyzer
Rewritten Binary
Runtime Monitor
Control Flow Graphs
Binary Program
Global Automaton
Local Automata
22The 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)
-
23Control 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
24Control Flow GraphTranslation
25Interprocedural ModelGeneration
A
read
read
close
line
26Interprocedural ModelGeneration
A
read
read
line
write
close
line
27Interprocedural ModelGeneration
B
A
line
read
read
line
write
close
close
line
28Interprocedural ModelGeneration
B
A
line
read
read
line
write
close
close
29Interprocedural ModelGeneration
B
A
read
read
line
write
close
close
30PossiblePaths
B
A
read
read
line
write
close
close
31PossiblePaths
B
A
read
read
line
write
close
close
32ImpossiblePaths
B
A
read
read
line
write
close
close
33ImpossiblePaths
B
A
read
read
line
write
close
close
34Adding ContextSensitivity
B
A
read
Y
read
line
X
write
close
close
Y
X
35PDA 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
36Dyck LanguageModel
B
A
read
Y
read
line
X
write
close
close
Y
X
37Dyck LanguageModel
B
A
read
Y
read
line
X
write
close
close
Y
X
38Dyck LanguageModel
B
A
read
Y
read
line
X
write
close
close
Y
X
39Rewriting User Job
User Job
Analyzer
Checking Shadow
Modified User Job
Binary Program
Rewritten Binary
40Null 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
41Rewriting 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
42Rewriting 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
43Rewriting 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
44Dyck 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
45Test Programs
Program Number of Instructions
procmail 107,246
gzip 56,710
cat 54,028
ps 59,814
fdformat 67,874
eject 70,177
46Smart Null Call Insertion
- Precision metric average branching factor
- Lower values indicate greater precision
chown
getpid
open
47(No Transcript)
48(No Transcript)
49Important 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.
50Static Analysis of Executables withApplications
to Infosec
- Somesh Jha
- University of Wisconsin
- Wisconsin Safety Analyzer
- http//www.cs.wisc.edu/wisa