Analyzing Stripped Device-Driver Executables

1
Analyzing Stripped Device-Driver Executables

• Gogul Balakrishnan1
• Thomas Reps2
• 1NEC Laboratories America
• 2University of Wisconsin
• (Work done at University of Wisconsin)

2
Why Analyze Executables?

• Source code is not available
• Windows drivers, libraries, viruses, worms, etc.
• Source code analysis may miss bugs
• WYSINWYX phenomenon
• What You See Is Not What You eXecute
• Better platform for finding security issues
• Many exploits utilize particular quirks of a
  compiler

3
Device Driver Analysis

• . . . You must examine the object code
• to be sure it matches your expectations,
• or at least will work correctly in the kernel
  environment. . .
• (From a document on Microsofts WHDC website)

4
Device-Driver Analysis

• Device Driver
• like a library that exports procedures
• each procedure actions for an I/O request
• e.g., AddDevice routine
• invoked by OS when a new device is added
• referred to as dispatch routines
• Windows Kernel API is complex
• 85 of crashes in Windows due to driver bugs
• Swift et al. 2005

5
PendedCompletedRequested Rule(simplified version)
A drivers dispatch routine does not return
STATUS_PENDING on an I/O Request Packet (IRP) if
it has called IoCompleteRequest on the IRP.
6
PendedCompletedRequested Rule
A drivers dispatch routine does not return
STATUS_PENDING on an I/O Request Packet (IRP) if
it has called IoCompleteRequest on the IRP,
unless it has also called IoMarkIrpPending.
7
DDA/x86 Device Driver Analyzer
8
SLAM Error Trace
DDA/x86 Error Trace
9
SDV Error Trace
DDA/x86 Error Trace
10
SDV Error Trace
DDA/x86 Error Trace
11
SDV Error Trace
DDA/x86 Error Trace
12
Static Program-Analysis Tools

• Malicious-code detection
• Bug detection
• Policy adherence

13
Static Program-Analysis Tools
14
Static Executable-Analysis Tools
15
Static Executable-Analysis Tools

• Value-Set Analysis CC04
• Combined pointer and numeric analysis
• Information about memory accesses
• Variable recovery algorithm VMCAI07
• Structure and Type recovery
• Analyzes heap-allocated data
• Recency-abstraction SAS06

16
Static Executable-Analysis Tools

• Memory-safety violations!
• Access outside of activation record
• Access outside of malloced block
• Call/jump to data
• Use of code as data

17
Memory-Access Analyzer
proc dispatch_routine sub esp, 4 mov
esp0, STATUS_PENDING cmp . . . jnz L1
mov ecx, esp4 mov ecx12,
STATUS_SUCCESS push ecx call
IoCompleteRequest mov esp0,
STATUS_SUCCESS L1 mov eax, esp0
add esp, 4 retn

• int dispatch_routine(Irp)
• int status
• status STATUS_PENDING
• if(. . .)
• Irp-gtStatusSTATUS_SUCCESS
• IoCompleteRequest(Irp)
• statusSTATUS_SUCCESS
• return status

18
Memory-Access Analyzer (MAA)

• Analyze a (possibly stripped) executable E
• Recover an Intermediate Representation (IR)
• Identify the procedures, data objects (V), types,
  and libraries that it uses
• For each instruction I, compute AbsEnv
• AbsEnv (V ? 2Values)
• Values memory addresses or numeric values
• 2Values use value-set abstract domain
  VMCAI07
• Distinguish inter-procedural contexts also

19
Device Extension Structure for moufiltr driver
Declaration in C Source
Structure in Executable
20
Device Extension Structure for moufiltr driver
Declaration in C Source
Structure identified by MAA
21
Memory-Access Analyzer (MAA)
proc dispatch_routine sub esp, 4 mov
esp0, STATUS_PENDING cmp . . . jnz L1
mov ecx, esp4 mov ecx12,
STATUS_SUCCESS push ecx call
IoCompleteRequest mov esp0,
STATUS_SUCCESS L1 mov eax, esp0
add esp, 4 retn

• Two aspects of AbsEnv
• Pointer analysis
• information about memory accesses
• Numeric analysis
• Information about numeric contents of data objects

22
API Usage Checking with Recovered IR

• IR recovery followed by automaton state
  propagation

23
API Usage Checking with Recovered IR

• int dispatch_routine(...)
• int status
• status STATUS_PENDING
• if(...)
• IoCompleteRequest()
• status STATUS_SUCCESS
• return status

From Memory Access Analyzer
status ?? STATUS_PENDING, STATUS_SUCCESS Reachab
le Automaton States START, COMPLETED
PendedCompletedRequest rule violated! (False
Positive)
24
API Usage Checking with Recovered IR

• Combine IR recovery and state-space exploration
• Feedback between phases can improve both

25
API Usage Checking with Recovered IR

• Combine IR recovery and state-space exploration?
• Feedback between phases can improve both
• ESP-like analysis M. Das et. al.
• Qualify AbsEnv with property automaton states

26
API Usage Checking with Recovered IR

• int dispatch_routine(...)
• int status
• status STATUS_PENDING
• if(...)
• IoCompleteRequest()
• status STATUS_SUCCESS
• return status

AbsEnv qualified with automaton state
START status ?? STATUS_PENDING COMPL
ETED status ? STATUS_SUCCESS
PendedCompletedRequest rule NOT violated!
27
API Usage Checking with Recovered IR

• int dispatch_routine(...)
• int status
• status STATUS_PENDING
• if(...)
• IoCompleteRequest()
• status STATUS_SUCCESS
• return status

Actually, above automaton does NOT provide
sufficient fidelity to deal with all cases!
28
API Usage Checking with Recovered IR
int dispatch_routine(...) int status
status STATUS_PENDING if(...)
IoCompleteRequest() status
STATUS_SUCCESS return status

• int dispatch_routine(...)
• int status, c
• c 0
• status STATUS_PENDING
• if(...)
• status STATUS_SUCCESS
• c 1
• if(c 1)
• IoCompleteRequest()
• return status

29
API Usage Checking with Recovered IR

• int dispatch_routine(...)
• int status, c
• c 0
• status STATUS_PENDING
• if(...)
• status STATUS_SUCCESS
• c 1
• if(c 1)
• IoCompleteRequest()
• return status

START status ? ? STATUS_PENDING,
STATUS_SUCCESS
START status ? ? STATUS_PENDING
30
API Usage Checking with Recovered IR

• int dispatch_routine(...)
• int status, c
• c 0
• status STATUS_PENDING
• if(...)
• status STATUS_SUCCESS
• c 1
• if(c 1)
• IoCompleteRequest()
• return status

PendedCompletedRequest rule violated! (False
Positive)
START status ? STATUS_PENDING,
STATUS_SUCCESS COMPLETED status? ?
STATUS_PENDING, STATUS_SUCCESS
31
StatusPending FSM
Finding status-variable The local variable
(if any) that is used to initialize the value of
eax just before returning from the dispatch
routine is the status-variable.
32
Extracting Counter-Example Traces

• Harness existing tracing facilities from Push
  Down Systems (PDSs)
• Build PDS on-the-fly during property checking
• Symbolic representation of state space explored
• Issue a reachability query on PDS
• Report witness trace for a path to the error
  configuration

33
Results For PendedCompletedRequested Rule
34
Summary

• Prototype tool to check device-driver executables
• 2 bugs, 10 OK, 5 false positives
• Reasonable running time
• Establishes that property checking of stripped
  executables is a promising direction
• What next?
• Automatic abstraction refinement
• Lazy Abstraction Henzinger et al. POPL02,
  Property simulation Das et al. PLDI02, Gulavani
  Rajamani TACAS06,. . .
• Automatic counter-example validation
• . . .

35
Analyzing Stripped Device-Driver Executables

• Gogul Balakrishnan1
• Thomas Reps2
• 1NEC Laboratories America
• 2University of Wisconsin
• (Work done at University of Wisconsin)

36
Backup Slides
37

• G. Balakrishnan and T. Reps, Analyzing memory
  accesses in x86
• executables, CC 2004, www.cs.wisc.edu/reps/cc
  04
• T. Reps, G. Balakrishnan, J. Lim, and T.
  Teitelbaum, A next-
• generation platform for analyzing executables,
  APLAS 2005,
• www.cs.wisc.edu/reps/aplas05.invited
• T. Reps, G. Balakrishnan, and J. Lim,
  Intermediate-representation
• recovery from low-level code, PEPM 2006,
• www.cs.wisc.edu/reps/pepm06.invited
• G. Balakrishnan and T. Reps, Recency-abstraction
  for heap-allocated
• storage, SAS 2006, www.cs.wisc.edu/reps/sas06
  -recency
• G. Balakrishnan and T. Reps, DIVINE DIscovering
  Variables IN
• Executables, VMCAI 2007, www.cs.wisc.edu/reps/
  vmcai07.invited

38
Current State-of-the-Art CodeSurfer/x86

• General platform for analyzing executables
• Tracks data movement through memory
• including heap
• Does not rely on debugging information
• Gives information to build further analysis
• like a compiler front-end plus some more

39
Basic Approach

• Recover an Intermediate Representation (IR) from
  the executable
• IR similar to that built by a compiler
• control-flow graph (w/ indirect jumps resolved)
• call graph (w/ indirect calls resolved)
• set of variables
• values of pointers
• used, killed, and possibly-killed variables for
  CFG nodes
• data dependences
• types of variables base types, pointer types,
  structs, and classes
• Use the recovered IR for further analysis

Without Debugging Information!
40
Scope

• Programs that conform to a standard compilation
  model
• procedures
• activation records
• global data region
• heap, etc.
• Report violations
• violations of stack protocol
• return address modified within procedure

41
CodeSurfer/x86 Architecture
Security Analyzers
Memory-Access Analyzer
Decompiler
Binary
CodeSurfer (Builds SDG)
IDAPro Disassembler
Binary Rewriter
User Scripts

• Initial estimate of
• code vs. data
• procedures
• call sites
• malloc sites

42
CodeSurfer/x86 Architecture
Security Analyzers
Memory-Access Analyzer
Decompiler
Binary
CodeSurfer (Builds SDG)
IDAPro Disassembler
VSA
Binary Rewriter
ASI
User Scripts

• Initial estimate of
• code vs. data
• procedures
• call sites
• malloc sites

43
CodeSurfer/x86 Architecture
Security Analyzers
Memory-Access Analyzer
Decompiler
Binary
CodeSurfer (Builds SDG)
IDAPro Disassembler
VSA
Binary Rewriter
ASI
User Scripts

• Initial estimate of
• code vs. data
• procedures
• call sites
• malloc sites

44
SLAM Error Trace
DDA/x86 Error Trace
45
SDV Error Trace
DDA/x86 Error Trace
46
SDV Error Trace
DDA/x86 Error Trace
47
SDV Error Trace
DDA/x86 Error Trace