curity property that needs to be enforced to prevent control-

flow hijacking attacks. Recent attacks have demonstrated that

existing CFI protections for COTS binaries are too permissive,

callsites. With the extracted C++ semantics, we construct a sound

CFI policy and further improve the policy precision by devising

two filters, namely “Nested Call Filter” and “Calling Convention

Filter”. We implement a prototype system called vfGuard,

and evaluate its accuracy, precision, effectiveness, coverage and

performance overhead against a test set including complex C++

binary modules used by Internet Explorer. Our experiments show

a runtime overhead of 18.3% per module. On SpiderMonkey,

an open-source JavaScript engine used by Firefox, vfGuard

generated 199 call targets per virtual callsite – within the same

security property that needs to be ensured to prevent control-

flow hijacking attacks. Because of its importance, several

recent research efforts (e.g., [2]–[6]) have focused on CFI. CFI

solutions roughly fall into two categories: some derive strict

CFI policies from program source code (e.g., SafeDispatch [7],

VTV [8]), and others such as CCFIR [2] and BinCFI [3]

enforce coarse-grained CFI policy to directly protect COTS

binaries. Binary-only CFI solutions are attractive, because in

reality the source code for many commercial software, third-

party libraries, and kernel modules are not available. However,

NDSS ’15, 8-11 February 2015, San Diego, CA, USA

Copyright 2015 Internet Society, ISBN 1-891562-38-X

http://dx.doi.org/10.14722/ndss.2015.23297

a strict CFI policy for virtual calls, we need to reliably

rebuild certain C++-level semantics that persist in the stripped

C++ binaries, particularly VTables and virtual callsites. Based

on the extracted VTables and callsites, we can construct a

basic CFI policy and further refine it. As a key contribution,

we demonstrate that CFI policies with increased precision

decompilation framework [12] with over 3.4K lines of Python

code. vfGuard successfully recovered all the legitimate VTa-

bles in complex binaries. Moreover, it recovered most of the

legitimate callsites in the binary without false positives. We

generated a CFI policy for each of the callsites and tested

a set of C++ Windows system libraries and show under 250

call targets per binary. In comparison with BinCFI, specifically

for the virtual call instructions, our policy is over 95% more

precise. We show that vfGuard can successfully mitigate

real-world exploits and report an overhead of under 20% for

evaluate our solution in Section VI and present a discussion

in Section VII. We present related work in Section VIII and

conclude in Section IX.

and 2, we present some background on dynamic dispatch and

polymorphism in C++ from a binary perspective. Specifically,

we consider two popular Application Binary Interfaces (ABIs)

– Itanium [13] and MSVC [14] – that modern compilers adhere

to. Figure 1(a) is the source code for a C++ program that was

termed “virtual functions” [15] and their invocation is termed

“virtual call” (or vcall). Virtual functions are in the heart

of polymorphism, which allows a derived class to override

methods in its base class. When a virtual function that is

overridden in a derived class is invoked on an object, the

invoked function depends on the object’s type at runtime.

Modern compilers – e.g., Microsoft Visual C++ (MSVC) and

GNU g++ – achieve this resolution using a “Virtual Function

Table” or VTable

virtual function is invoked in the derived class, the compiler

introduces a thunk that adjusts the this pointer to point to the

derived class object before invoking the actual function. For

example, in Figure 2(b), the thunk subtracts 0xc from the B

subobject to point to C object before invoking C::vBfoo.

We refer the reader to the ABIs for more details on thunks

but contains 0.

D. VTable Identification

ideal but hard. For instance, Dewey et al. [17] locate the

constructors in the program by tracking the VTable initializa-

tions. In commercial software, constructors are often inlined,

sections in the binary to identify the VTables. The VTables that

adhere to Itanium ABI contain mandatory fields along with the

array of vfpts. The mandatory fields make locating of VTables

in the binary relatively easier when compared to MSVC ABI.

However, VTables generated by the Microsoft Visual Studio

compiler (MSVC ABI) are often grouped together with no

apparent “gap” between them. This poses a challenge to

accurately identify VTable boundaries.

including a few false VTables does not compromise the policy

soundness and only reduces precision to a certain degree. A

detailed algorithm for VTable identification is presented in

Section IV-B.

E. Target Accumulation and Filtering

form a universal set for virtual call targets. A naive policy

will include all vfptrs as valid targets for each callsite. For

large binaries, such a policy would contain 1000s of targets

per callsite. While still more precise than existing defenses, it

further improve the policy precision. First, we note that target

vfptrs for a callsite that is invoked on the same object pointer as

the host function must belong to the same VTables as the host

function. With this, we apply our first filter, called “Nested Call

is presumed at the callsite and the calling convention adhered

to by the target function must be compatible. Accordingly, we

apply the second filter called “Calling Convention Filter”.

for various reasons. To name a few, we could infer the number

of arguments accepted by each function and require it to match

the number of arguments passed at the callsite; we could

perform inter-procedural data flow analysis to keep track of

this pointers; and we could perform type inference on func-

tion parameters and bind type compatible functions together.

scanning-based approach for callsite identification is insuffi-

cient. vfGuard first identifies all the candidate functions that

could host callsites by identifying functions in the binary that

contain at least 1 indirect call instruction. Each identified func-

tion is subjected to static intra-procedural analysis to identify

legitimate virtual callsites and VTable offsets at such callsites.

large, and instructions often have complex semantics. To aid

in analysis and focus on the data flow, we make use of a

simple, yet intuitive intermediate language as shown in Table I.

The IR is simple enough to precisely capture the flow of data

within a function without introducing unnecessary overhead.

Each function is first broken down into basic blocks and a

control-flow graph (CFG) is generated. Then, starting from

the function entry point, the basic blocks are traversed in a

1. A

2. if (x == 0)

3. pa = &a

4. else

5. pa = &c

6. pa->vAtest(0);

TABLE II: Callsite identification for A::Afoo() in the sample example in Figure 2(a). After propagation at 0x7ae, deref(esp

VTables, using a signature template derived from the Itanium

and MSVC ABI specifications. Moreover, since the VTable

locations are known during compile-time, using mov or an

equivalent instruction, compilers move the “immediate” value

of a VTable’s address point into the object base address

during object initialization. Therefore, VTable base addresses

are a subset of all the “immediate” values that occur in the

binary. vfGuard first scans for all the “immediate” values

that occur in the binary. Then, the value is identified as a

VTable if it belongs to a read-only section and matches with

therefore provide a stronger signature template. They also act

as a natural boundary between VTables. MSVC imposes no

such requirement. In binaries compiled by MSVC, groups of

VTables are often contiguously allocated, thereby presenting

the challenge of identifying the boundaries.

Algorithm 1. It comprises of two functions. “ScanVTables”

takes a binary as input and returns a list of all the VTables

each address in the data sections of the binary are scanned

for immediate values. If an immediate value that belongs to a

“getVTable” checks and returns the VTable at a given address.

Starting from the address, it accumulates entries as valid vfptrs

as long as they point to a valid instruction boundary within

the code region. Note that not all valid vfptrs may point to

a function entry point. For instance, in case of “pure virtual”

functions, the vfptr points to a compiler generated stub that

jumps to a predefined location. In fact the MSVC compiler

introduces stubs consisting of a single return instruction to

implement empty functions. To be conservative, vfGuard

Fig. 4: VTables with mandatory fields for running examples

as generated by Visual Studio (MSVC) compiler (no RTTI).

A::Afoo and B::Bfoo are non-virtual member functions

and therefore are not present in the VTables. VTables for A, B

assume VTables to be zero-based arrays of vfptrs. That is: