A Platform for Secure Static Binary Instrumentation
∗
Mingwei Zhang Rui Qiao Niranjan Hasabnis R. Sekar
Stony Brook University
Abstract
Program instrumentation techniques form the basis of many
recent software security defenses, including defenses against
common exploits and security policy enforcement. As com-
pared to source-code instrumentation, binary instrumenta-
tion is easier to use and more broadly applicable due to the
ready availability of binary code. Two key features needed
for security instrumentations are (a) it should be applied
to all application code, including code contained in various
system and application libraries, and (b) it should be non-
bypassable. So far, dynamic binary instrumentation (DBI)
techniques have provided these features, whereas static bi-
nary instrumentation (SBI) techniques have lacked them.
These features, combined with ease of use, have made DBI
the de facto choice for security instrumentations. However,
DBI techniques can incur high overheads in several common
usage scenarios, such as application startups, system-calls,
and many real-world applications. We therefore develop a
new platform for secure static binary instrumentation (PSI)
that overcomes these drawbacks of DBI techniques, while
retaining the security, robustness and ease-of-use features.
We illustrate the versatility of PSI by developing several
instrumentation applications: basic block counting, shadow
stack defense against control-flow hijack and return-oriented
programming attacks, and system call and library policy en-
forcement. While being competitive with the best DBI tools
on CPU-intensive SPEC 2006 benchmark, PSI provides an
order of magnitude reduction in overheads on a collection of
real-world applications.
1. Introduction
Program instrumentation has played a central role in exploit
detection/prevention, security policy enforcement, applica-
tion monitoring and debugging. Such instrumentation may
be performed either on source or binary code. Source code
∗
This work was supported in part by AFOSR grant FA9550-09-1-0539,
NSF grant CNS-0831298, and ONR grant N000140710928.
Permission to make digital or hard copies of all or part of this work for personal or
classroom use is granted without fee provided that copies are not made or distributed
for profit or commercial advantage and that copies bear this notice and the full citation
on the first page. Copyrights for components of this work owned by others than ACM
must be honored. Abstracting with credit is permitted. To copy otherwise, or republish,
to post on servers or to redistribute to lists, requires prior specific permission and/or a
fee. Request permissions from permissions@acm.org.
VEE ’2014, March 1–2, 2014, Salt Lake City, Utah, USA..
Copyright
c
2014 ACM 978-1-4503-2764-0/14/03. . . $15.00.
http://dx.doi.org/10.1145/2576195.2576208
instrumentations can be more easily and extensively opti-
mized by exploiting higher level information such as types.
However, binary instrumentations are more widely applica-
ble since users have ready access to binaries. Moreover, se-
curity instrumentations should be applied to all code, includ-
ing all libraries, inline assembly code, and any code inserted
by the compiler/linker. Here again, binary based techniques
are advantageous.
Binary instrumentation can either be static or dynamic.
Static binary instrumentation (SBI) is performed offline on
binary files, whereas dynamic binary instrumentation (DBI)
operates on code already loaded into main memory. DBI
techniques disassemble and instrument each basic block just
before its first execution. DBI has been the technique of
choice for security instrumentation of COTS binaries. Pre-
vious works have used DBI for sandboxing [15, 17], taint-
tracking [23, 28], defense from return-oriented program-
ming (ROP) attacks [11, 12], and other techniques for hard-
ening benign code [16, 26]. This is because DBI platforms
provide several features that simplify instrumentation devel-
opment, while ensuring their security:
•
Non-bypassable instrumentation. DBI tools check every
control-transfer to ensure that the target is instrumented,
and hence can block attempts to escape security checks
enforced by the instrumentation, e.g., by returning/jump-
ing to (i) data (code injection attacks), (ii) middle of an
instruction (typical ROP attacks), or (iii) into the middle
of added instrumentation or past its end.
•
Completeness. DBI techniques instrument all executed
code, regardless of whether they reside in executables or
libraries. The alternative of omitting library instrumenta-
tion is unsatisfactory because the vast majority of code
executed by today’s applications resides in libraries, and
all of this code will remain unprotected.
•
Ease of use. Instrumenting an application is as simple
as prefixing its invocation with the name of a wrapper
program. There is no need to explicitly instrument the
application prior to its run, nor is there a need to know
(and instrument) the libraries used by it. Moreover, DBI
platforms such as Pin [19], DynamoRIO [8] and Valgrind
[22] provide a convenient API that greatly simplifies the
development of new instrumentations (also called tools).
Previous SBI techniques have lacked these features, and
moreover, were targeted at specific problems such as control-
flow integrity (CFI) [2] or software fault isolation (SFI) [32].
Consequently, they don’t address the issues in developing a
general-purpose platform for binary instrumentation.
Main Results and Contributions
We present a general-purpose binary instrumentation plat-
form PSI that addresses the shortcomings of previous SBI
techniques. It combines the benefits of DBI with the advan-
tages that are unique to SBI, including:
•
the ability to trade off increased (offline) analysis/instru-
mentation time for faster runtime performance, and
•
avoiding reliance on a potentially large and complex vir-
tual environment at runtime
Moreover, PSI provides low overheads across a wide range
of benchmarks, while avoiding some pitfalls of DBI plat-
forms such as high application startup times and high over-
heads for systems applications. Our key contributions are
summarized below.
Secure static instrumentation. Two key features needed
for security instrumentations are completeness (instrumenta-
tion should be applied to all code that can get executed) and
non-bypassability (instrumented code should not be able to
bypass or subvert the added instrumentation). Many previ-
ous SBI techniques, including Native Client [35], PittSFIeld
[20], PEBIL [18] and many others [2, 6, 14, 24, 36, 37], are
not complete for COTS binaries since they require additional
information (such as symbol or relocation information) for
correctly instrumenting binaries.
Among techniques applicable to stripped binaries, Reins
[33] and SecondWrite [4, 13] don’t instrument all libraries.
Moreover, several of these techniques, including Dyninst
[10], SecondWrite and Binary stirring [34], do not prevent
execution from escaping instrumentation since they do not
check the validity of targets such as return addresses. Al-
though our BinCFI [38] system performs such checks, it
implements a single hard-coded instrumentation, and hence
there is no general discussion or treatment of instrumenta-
tion non-bypassability.
A versatile, easy-to-use static instrumentation platform.
Our platform provides an easy-to-use API with convenient
abstractions for low-level instrumentation, including data
structures to capture instructions, basic blocks, and control-
flow graphs. We illustrate the API and demonstrate its ver-
satility by developing several instrumentation tools:
•
Counting basic blocks: This conceptually simple example
has been used frequently to illustrate DBI platforms.
•
System call policy enforcement: These policies are com-
monly used in security hardening and related applications.
•
Shadow stack: This technique has been used by several
previous works to defend against stack-smashing [27] and
ROP [12]. While our instrumentation is similar to that of
ROPdefender [12], it provides much better performance.
On-demand instrumentation of libraries. SBI techniques
require all library dependences to be identified statically, and
these libraries need to be instrumented ahead of time; other-
wise, an instrumented application can fail at runtime. Tools
for determining library dependencies (e.g., ldd on Linux)
cannot identify libraries that are loaded after an application
begins execution. For a collection of popular real-world ap-
plications, more that 40% of library loads occurred after the
commencement of application execution. To support seam-
less instrumentation of such libraries, we have developed an
on-demand static instrumentation technique.
Good performance across a wide range of applications
We present a comparative performance evaluation of PSI
against the two leading DBI tools, namely DynamoRIO and
Pin. We summarize our results below:
•
BB counting on SPEC 2006. PSI incurs an average over-
head of 69% on SPEC 2006 for basic-block counting,
compared with 53% for DynamoRIO and 97% for Pin.
•
Shadow stack. PSI’s overhead is less than a quarter of that
reported by ROPdefender (18% vs 74%).
•
lmbench Microbenchmark. The average overhead of PSI
is about 10 times smaller than DynamoRIO, and 200 times
smaller than Pin.
•
A collection of real-world applications. PSI’s overheads
are about 7 to 13 times lower than DynamoRIO, and 60
times lower than Pin on several real-world applications,
including compilation, software updates, etc.
Our PSI platform will be available for download from
http://seclab.cs.stonybrook.edu/download.
Scope and Limitations. PSI is a general platform for the
instrumentation of COTS applications. It is targeted at be-
nign COTS binaries that do not employ obfuscation. If a
binary employs obfuscation (as is common with malware),
our disassembly technique can fail to detect all of its code, or
perform incorrect disassembly. However, since control flows
are checked at runtime, PSI will block all attempts to exe-
cute code that wasn’t disassembled and instrumented. Thus,
binaries employing obfuscation may fail at runtime due to
control-flow transfers being blocked, but they won’t be able
to bypass PSI.
Similar to most SBI techniques, PSI does not support self-
modifying code. In particular, any attempt to modify existing
code (or to transfer control to runtime-generated code) will
be denied, causing such applications to fail.
Our implementation targets x86/Linux, but our tech-
niques are generally applicable to other architectures as well.
2. Background
Disassembly. Two of the basic algorithms used for disas-
sembly are linear sweep and recursive disassembly. Linear
sweep begins at the binary entry point, and sequentially dis-
assembles instructions until the end. Data or padding embed-
ded within code will also get disassembled. With variable-
length instruction sets, this error can cascade past the data
region. Recursive disassembly avoids this problem by fol-
lowing the control-flow, and limiting disassembly to those
code fragments that are known to be reachable. However, it
often fails to discover all code, since some code is reach-
able only via code pointers whose values aren’t known stat-
ically. As a result, accurate disassembly of stripped binaries
has been a challenging problem for variable-length instruc-
tion sets such as x86. Indeed, this is another reason for the
popularity of DBI platforms, since they can side-step these
difficulties by limiting disassembly to one basic block at a
time, just before the block is executed for the first time.
Our BinCFI [38] work and binary stirring [34] have
shown that robust instrumentation can be achieved despite
the above challenges. Like many previous efforts in static
disassembly, these works combine elements of linear sweep
and recursive disassembly. Specific advances made in these
works were: (a) expanding the coverage of recursive dis-
assembly using static analysis techniques for code pointer
discovery, and (b) the development of instrumentation tech-
niques that tolerate disassembly of data. Our efforts were
also helped by the fact that compilers have become more
strict in avoiding data within code segments. As a result, we
have achieved 100% disassembly accuracy on many com-
plex binaries [38]. In PSI, we reused this disassembler.
Resolving Indirect Control Transfers. Insertion of instru-
mentation will cause the locations of subsequent code to
change. This means that statically computed function point-
ers will have incorrect values in an instrumented program,
pointing to code locations in the original rather than the in-
strumented code. DBI techniques solve this problem by per-
forming address translation of indirect control flow targets
at runtime. Our BinCFI work [38] uses the same approach,
and we reused it in PSI. When an address is not found in the
translation table, that indicates an attempt to transfer control
to an invalid destination, which will be blocked by PSI.
We point out BinCFI’s address translation approach is
modular, and is performed in two steps. In the first step, a
global translation table (GTT), maintained by our modified
loader, is used to translate the upper 20-bits of an address to
the entry point of a module-specific translation table (MTT)
routine. This MTT, which is generated at the time the module
is transformed by PSI, uses the remaining bits to look up the
corresponding address in the transformed module.
3. System Overview
PSI instruments executables as well as all of the shared li-
braries used by them. On each invocation, PSI takes a binary
file (executable or library) as input, and outputs an instru-
mented version of this binary. This invocation may occur
before execution, or on-the-fly during program execution.
Figure 1 shows the architecture of PSI. It consists of three
main components: a binary analyzer, an instrumentor and a
binary generator. The binary analyzer takes a binary as input,
disassembles it, and then constructs a control-flow graph.
This control-flow graph becomes the input for static analysis
and instrumentation components.
ELF binary layout
Controller
Binary Instrumentation API
Static
analyzer
disasse-
mbly
checker
System
Call
Policy
profiling
debugging
optimization
New Code & Data
Original Data
ELF
Metad
ata
Original Code
address translation
Instrumentor
generic
instrumentation
Instrumentation Tools
Binary
Rewriter
more …...
Binary generator
Binary analyzer
Target Binary
library
loading
policy
Basic
Block
Counting
Shadow
Stack
(return
Stack)
Figure 1. Architecture Overview of PSI
The heart of PSI is the instrumentor, which provides an
expressive API for static binary instrumentation. Two lev-
els of API are supported. The low-level API operates at the
instruction level, and supports operations for inserting as-
sembly language snippets at desired points. The high-level
API allows insertion of calls to instrumentation functions
that may be written in a language such as C. This code is
compiled into a shared library, and our platform ensures that
these functions can be called in a secure manner from (and
only from) the calls inserted using the high-level instrumen-
tation API. This API is further described in Section 3.2.
PSI uses the address translator from BinCFI [38], but its
behavior can be modified using the instrumentation API.
The actual task of instrumentation is performed by in-
strumentation tools, which are programs that use the API
provided by the platform to instrument applications and the
libraries used by them.
Our API not only allows tools to control the instrumen-
tation phase, but also other phases such as static analysis,
address translation, etc. This allows instrumentation tools to
enhance these phases.
3.1 Non-bypassable Instrumentation
PSI ensures that the added instrumentation is non-bypassable
by enforcing the following properties.
•
All direct and indirect control-flow transfers made from
the original code must target instructions in the original
code that were validly disassembled by the disassembler.
•
If a snippet was specified for insertion before an instruc-
tion I, then all (direct or indirect) control-flow transfers
targeting I will instead be made to target the first instruc-
tion of the added snippet.
•
Only the added instrumentation code can transfer control
to libraries containing instrumentation support functions.
(Recall that the high-level instrumentation API relies on
inserting calls to this library.)
All indirect branches, including jumps, calls and returns, are
checked at runtime to ensure the above properties. Direct
branches are checked at the time of generating the instru-
mented binary.
In addition to the above, our loader denies requests for
loading uninstrumented libraries. If on-demand instrumenta-
tion option is turned on, the request isn’t denied; instead, an
instrumented version of the library is generated and loaded.
The above properties overlap with coarse-granularity CFI
that limits control transfers to instruction boundaries. Specif-
ically, we have enhanced such a CFI property with additional
restrictions intended to protect the integrity of added instru-
mentation, as well as to deal with problems such as runtime
loading of libraries, disassembly problems, etc.
Our platform is geared for instrumenting benign appli-
cations — applications that may contain vulnerabilities, but
are not malicious themselves. For such applications, these
checks ensure that control-flow cannot “escape” instrumen-
tation. A non-exhaustive list of attacks prevented by PSI is
as follows.
•
Branching to data segments. As described above, the list
of valid targets can only include addresses within validly
instrumented code. Thus, data segments cannot appear in
this table of valid targets.
•
Branching to code sections that were not recognized and
instrumented. If the disassembler fails to recognize some
code fragments, they won’t be instrumented. However,
since branch targets are restricted to be valid instruction
boundaries in disassembled code, any attempt to execute
undiscovered code will be blocked.
•
Branching to middle of instructions. ROP attacks are a
prime example here. Since the targets are checked to be
valid instruction boundaries, these attacks are stopped.
•
Bypassing the instrumentation code. As noted above, if an
instrumentation snippet was specified for insertion before
an instruction, that instruction is no longer permitted to be
a branch target.
•
Corrupting the integrity of instrumentation logic by jump-
ing into its middle, or by accessing functions intended to
be used exclusively by instrumentation. As noted above,
branches will be checked to preclude these targets.
Threats posed by untrusted code. Instrumentation of un-
trusted (and potentially malicious) applications can be sup-
ported, but it requires more extensive (and expensive) checks
on instrumented code. Specifically, untrusted code can at-
tempt to subvert PSI using one of the following means:
•
corrupting PSI data. Untrusted code could intentionally
corrupt data used by PSI instrumentations.
•
using race conditions. Untrusted code may use data races
to carry out time-of-check-to-time-of-use attacks on poli-
cies enforced by PSI, such as system call policies.
•
subverting the loader. By subverting the loader, untrusted
code may be able to load and execute uninstrumented
libraries.
All of these threats can be addressed by isolating the mem-
ory used by the instrumented applications, using a technique
such as software fault isolation (SFI) [32]. However, mem-
ory isolation incurs significant additional costs, and hence
is typically not enabled on most instrumentation platforms,
including most DBI platforms.
3.2 Instrumentation API
Our platform provides a simple API for custom instrumen-
tation of binaries. This API is designed to operate at roughly
the same level of abstraction as Pin and DynamoRIO. How-
ever, being a static rewriting tool, all instrumentation opera-
tions occur in one shot on our platform: the entire CFG for a
binary is presented to the code instrumentor, which traverses
the CFG and adds all the desired instrumentation. This con-
trasts with DBI tools where instructions and basic blocks are
discovered one by one, just before their first execution, and
the code instrumentor invoked separately on the newly dis-
covered basic block.
After disassembly, PSI constructs a control-flow graph
(CFG) of the program. The nodes in the CFG are basic
blocks, each of which consists of a sequence of instructions.
All incoming control transfers into a basic block go to its
first instruction, while all control transfers out of the block
occur on its last statement. Note that every indirect control
flow target computed by our static analysis is considered in
defining these basic blocks. Since this analysis estimates a
superset of possible indirect targets, the basic blocks com-
puted by our technique can be smaller than those computed
by a compiler.
The entire CFG can be accessed using the API function
getCFG, while the list of all basic blocks and instructions
can be obtained using the functions getBBs and getInsns.
The API also provides operations to iterate through instruc-
tions and basic blocks in a CFG, and instructions in a ba-
sic block. Also supported are operations to examine instruc-
tions. These operations are based on the Intel’s xed2 instruc-
tion encoder/decoder library. Some of the most commonly
used operations are isCall, isRet, isTest, isSysCall,
isMemRead, isMemWrite, getTarget, and getSrc.
Insertion of Assembly Code Snippets. Instrumentation
can be performed at a low or high level. At the low level,
an instrumentation snippet is inserted as follows:
ins
snippet(target, location, snippet)
Here, target is a reference to an instruction or a basic block,
and is specified using a reference to the corresponding ob-
ject, or by using a label. The parameter location is one
of BEFORE or AFTER, and snippet is a string consisting of
assembly code that is to be inserted. For call instructions,
one extra location AFTER CALL is defined. To ensure trans-
parency of return addresses on the stack, a call is translated
into a push instruction that pushes the original return ad-
dress, followed by a jump that transfers control to the tar-
get function. AFTER CALL corresponds to the point between
push and jump.
Instead of inserting additional instrumentation, some ap-
plications may require replacement of existing instructions.
This is done using the following API function:
replace ins(target, new snippet)
Instruction emulation is a purpose for which this API func-
tion comes handy: we replace the original instruction with a
snippet that emulates it.
PSI provides a private thread local storage (TLS) area
that can be used by assembly snippets to store their data.
This private TLS, which is independent of the one used
by glibc, is organized into two arrays TS and GS that are
both initialized with all zeros. The size of these arrays is
configurable, but they default to one memory page. Snippet
code can use the identifiers TS n and GS n to access the nth
word of the arrays TS and GS respectively. Example uses of
these arrays can be found in Figures 2 and 3.
Insertion of Calls to Instrumentation Functions. The
benefit of the snippet API is that it can be more efficient
since the instrumentation writer can minimize the number of
instructions executed. Its downside is that instrumentation
has to be performed in assembly, and that it is more complex.
In contrast, the higher level API simplifies instrumentation
but is generally less efficient. It enables the insertion of calls
to handler functions in a shared library defined by the instru-
mentor. Several low level details are handled automatically
by the high-level API. These include saving/restoring of reg-
isters and flags, switching to a different stack, resolving the
symbolic name of the user-defined handler function, making
the program state available through a high-level data struc-
ture called Context, and so on. These factors simplify the
instrumentation task, and allows the handler code to be writ-
ten in higher level languages (currently, C/C++). This API is
accessed using the following function:
ins call(target, location, name, args)
Here, target and location have the same meaning as the
snippet API. The name of the function to be invoked is
specified using the string parameter name. This function
should have the following prototype:
void handler(struct Context ∗ c, . . .)
It takes a first parameter that represents the runtime context
of the instrumented program, including all of the CPU regis-
ters, stack, etc. The subsequent parameters are exactly those
that were included in the args parameter to ins call.
Controlling Address Translation. As described earlier,
address translation instrumentation, which regulates ICF
transfers, is automatically added by our platform. We pro-
vide some API functions so that an instrumentation devel-
oper can exercise finer control over ICF transfers. These
functions can be used by an instrumentation tool that im-
plements a more sophisticated ICF target analysis to further
restrict indirect branches. Even without performing more
static analysis, an instrumentation tool may enforce a more
restrictive policy, e.g.,
•
all returns should go to instructions following calls
•
(some or all) indirect jumps should not target addresses
outside the current module
These restrictions can be specified using the API function:
rm indirect target(src addrs, target addrs)
The argument src addrs is a list of the labels of the ICF
transfer instructions whose targets should be restricted. If it
is empty, then the operation is applied to all ICF transfer
instructions in the module. The second argument is also a
list of labels, but may include a special label NONLOCAL
that causes non-local addresses to be deleted from the list of
valid targets.
Custom address translation instrumentation can also be
used to relax a previously specified policy. This is done using
the following API function:
add indirect target(src addrs, target addrs)
Any number of rm indirect target and add indirect
target calls may be made. The platform will keep track of
possible targets for each source address, and will generate a
unique address translation trampoline for each set of source
addresses that share the same set of possible targets.
Runtime event handling. Finally, the API supports regis-
tration of instrumentation functions that will be called when
certain events occur at runtime, such as program/thread
startup or exit, loading of libraries, and system calls:
•
register pre syscall handler()
•
register post syscall handler()
•
register library load handler()
•
register thread start handler()
•
register thread terminate handler()
•
register program start handler()
•
register program terminate handler()
These API calls take a function name as their argument.
Development of Instrumentation tools. To develop an in-
strumentation tool, user provides the tool code, and option-
ally, a client library. The tool code uses the API provided
by our platform to realize an instrumentation tool. Tools that
use the high-level API need a mechanism to provide the def-
initions of function calls inserted using that API. This is the
role of the client library. Note that the tool code is used at
