KTN ran a collaborators' workshop on 26 September 2019 in London to explain more about the Digital Security by Design Challenge announced by the government. The Digital Security by Design challenge has been recently announced by the Department for Business, Energy & Industrial Strategy (BEIS). This challenge, amounting to £70 million of government funding over 5 years, was delivered by UK Research and Innovation (UKRI) through the Industrial Strategy Challenge Fund (ISCF). This Collaborators' Workshop provides an opportunity to hear more details of the challenge and forthcoming competitions. A Scoping Workshop for this challenge was held on 30th May: http://ow.ly/oz6230pHlGl Find out more about the Defence and Security Interest Group at https://ktn-uk.co.uk/interests/defence-security Join the Defence and Security Interest Group at https://www.linkedin.com/groups/8584397 or Follow KTN_UK Defence group on Twitter https://twitter.com/KTNUK_Defence

1. Collaboration between the University of
Oxford and Intel Corporation has developed
new methods to check that electronic chips
do what they’re meant to do, before they
are manufactured.
Integrated electronic chips, such as the processor
in a laptop, contain many billions of interconnected
transistors, all working together to run programs.
The engineering design of a new chip is extremely
challenging, and ensuring that the finished chip
works correctly is vitally important. Almost half of
the several years spent creating a new chip goes on
testing it for potential errors.
Fabricating a prototype chip to test a design is
prohibitively expensive, so computer simulations
are widely used to validate designs. But exhaustive
simulation of every possible internal set of
connections in every possible operating condition
would take many millions of years, so is clearly
not feasible.
Tom Melham, Professor of Computer Science at
the University of Oxford, has been working with
Intel Corporation since the late 1990s to develop
and apply a mathematical validation technique
known as formal verification. This entails building
a mathematical description of the chip design
and then analysing its correctness by rigorous
mathematical proof. The proofs are very large, so
a simplification technique called abstraction is used
to pick out salient features for testing; one such
technique has been patented by Intel and Professor
Melham. Twenty-five years ago these advanced
formal verification techniques were thought
unachievable; today they are in routine use by Intel
and other companies worldwide.
Professor Melham’s collaboration with Intel is a
prime example of knowledge exchange between
academia and industry. Intel, led by experts such as
Senior Principal Engineer Dr Carl Seger, has pioneered
the use of formal verification on the hardest industrial
chip design problems. Melham has worked closely
with Intel engineers for over a decade, and Intel
researchers have spent time at the University of
Oxford – including Dr Seger as a Visiting Fellow of
Balliol College during 2006-7.
The ability to rapidly identify design errors in a chip
is cost-effectively driving forward new designs that
use less power and are more environmentally friendly.
The technique also has applications in safety-critical
systems, such as aeroplane, automotive, or rail control,
where confidence in the chips is vital.
‘Having Professor Melham working with us and
helping us articulate and evaluate the “big picture”,
which often gets lost in the daily struggle to get the
next design out the door, has been invaluable. Some
of this joint work provided the foundation for methods
that are today used at half a dozen design centres on
three continents. In addition, I believe the benefits
have been mutual in that we have also provided
Professor Melham with a wealth of interesting,
challenging, and relevant research problems.’
Dr Carl Seger, Senior Principal Engineer, Intel Corporation
Chips with confidence
37
www.ox.ac.uk/oxfordimpacts
www.cs.ox.ac.uk/tom.melham
Funded by: Intel Corporation and the Engineering and Physical Sciences
Research Council.
Microarchitecture Formal Verification
IEEE TRANSACTIONS ON COMPUTER-AIDED DESIGN OF INTEGRATED CIRCUITS AND SYSTEMS, VOL. 24, NO. 9, SEPTEMBER 2005 1381
An Industrially Effective Environment for
Formal Hardware Verification
Carl-Johan H. Seger, Robert B. Jones, Member, IEEE, John W. O’Leary, Member, IEEE, Tom Melham,
Mark D. Aagaard, Member, IEEE, Clark Barrett, and Don Syme
Abstract—The Forte formal verification environment for
datapath-dominated hardware is described. Forte has proven to be
effective in large-scale industrial trials and combines an efficient
linear-time logic model-checking algorithm, namely the symbolic
trajectory evaluation (STE), with lightweight theorem proving
in higher-order logic. These are tightly integrated in a general-
purpose functional programming language, which both allows the
system to be easily customized and at the same time serves as
a specification language. The design philosophy behind Forte is
presented and the elements of the verification methodology that
make it effective in practice are also described.
Index Terms—BDDs, formal verification, model checking,
symbolic trajectory evaluation, theorem proving.
I. INTRODUCTION
FUNCTIONAL validation is one of the major challenges in
chip design today, with conventional approaches to design
validation a serious bottleneck in the design flow. Over the past
ten years, formal verification [1] has emerged as a complement
to simulation and has delivered promising results in trials on
industrial-scale designs [2]–[6].
Formal equivalence checking is widely deployed to compare
the behavior of two models of hardware, each represented as
a finite state machine or simply a Boolean expression (often
using binary decision diagrams (BDDs) [7]). It is typically
used in industry to validate the output of a synthesis tool
against a “golden model” expressed in a register-transfer level
hardware description language (HDL), and in general to check
consistency between other adjacent levels in the design flow.
Property checking with a model checker [8]–[11] also in-
volves representing a design as a finite state machine, but it
has wider capabilities than equivalence checking. Not only can
one check that a design behaves the same as another model,
Manuscript received January 20, 2004; revised June 23, 2004. This paper
was recommended by Associate Editor J. H. Kukula.
C.-J. H. Seger, R. B. Jones, and J. W. O’Leary are with Strategic CAD
Labs, Intel Corporation, Hillsboro, OR 97124 USA (e-mail: Carl.Seger@
intel.com; Robert.B.Jones@intel.com; John.W.O’Leary@intel.com).
T. Melham is with the Oxford University Computing Laboratory, Oxford
OX1 3QD, U.K. (e-mail: Tom.Melham@comlab.ox.ac.uk).
M. D. Aagaard is with the Department of Electrical and Computer En-
gineering, University of Waterloo, Wateroo, ON N2L 3G1, Canada (e-mail:
maagaard@uwaterloo.ca).
C. Barrett is with the Department of Computer Science, Courant Institute
of Mathematical Sciences, New York University, New York, NY 10012 USA
(e-mail: barrett@cs.nyu.edu).
D. Syme is with Microsoft Research, Cambridge CB3 0FB, U.K. (e-mail:
dsyme@microsoft.com).
Digital Object Identifier 10.1109/TCAD.2005.850814
one can also check that the hardware possesses certain desir-
able properties expressed more abstractly in a temporal logic.
An example is checking that all requests are eventually ac-
knowledged in a protocol. Model checking is currently much
less widely used in practice than equivalence checking.
Theorem proving [12], [13] allows higher level and more
abstract properties to be checked. It provides a much more
expressive language for stating properties—for example, higher
order logic [14]—and it can deal with infinite-state systems.
In particular, it allows one to reason with unknowns and param-
eters, so a general class of designs can be checked—for exam-
ple, parameterized IP blocks [15]. Industrially, theorem proving
is still viewed as a very advanced technology, and its use is not
widespread.
Equivalence checkers and model checkers both suffer from
severe capacity limits. In practice, only small fragments of
systems can be handled directly with these technologies, and
much current research is aimed at extending capacity. Of
course, it is unrealistic to expect a completely automatic model-
checking solution. Instead, one needs to find good ways of
using human intelligence to extract the maximum potential
from model-checking algorithms and to decompose problems
into appropriate pieces for automated analysis. One approach
is to combine model-checking and BDD-based methods with
theorem proving [16]–[18]. The hope is that theorem proving’s
power and flexibility will enable large problems to be broken
down or transformed into tasks a model checker finds tractable.
Another approach is to extend the top level of a model checker
with ad hoc theorem-proving rules and procedures [19].
This paper describes a formal verification system called Forte
that combines an efficient linear-time logic model checking
algorithm, namely symbolic trajectory evaluation (STE) [20],
with lightweight theorem proving in higher-order logic. These
are interfaced to and tightly integrated with FL [21], a strongly
typed, higher order functional programming language. As a
general-purpose programming language, FL allows the Forte
environment to be customized and large proof efforts to be
organized and scripted effectively. FL also serves as an expres-
sive specification language at a level far above the temporal
logic primitives.
The Forte environment has proven to be highly effective
in large-scale industrial trials on datapath-dominated hardware
[3], [22], [23]. The restricted temporal logic of STE does
not, however, limit Forte to pure datapath circuits. Many large
control circuits are “datapath-as-control,” and these can also be
handled effectively. In addition, the tight connection to higher-
order logic and theorem proving provides great flexibility in
0278-0070/$20.00 © 2005 IEEE
FUNCTIONAL VALIDATION is one of the major
challenges in chip design today, with test genera-
tion, test bench construction, and simulation con-
suming a significant portion of the design effort.
Throughout the 1990s, formal verification emerged
as a promising complement to conventional sim-
ulation-based validation.1
Most formal verification
research concerns algorithms and focuses on tool
capacity limits. Yet almost any serious verification
effort faces many practical difficulties besides
capacity. In a large verification project, the effort
required to organize the multitude of tasks, speci-
fications, and verification scripts can limit the qual-
ity and productivity of the work.
We tackle this problem by coupling our
research on verification algorithms and tools
with research on verification methodology. Our
goal is to address the realities of design prac-
tice—rapid changes and incomplete specifica-
tions—while producing high-quality results and
improving verification productivity. Our
methodology systematically organizes a large
verification effort’s many interdependent activ-
ities and provides a guiding structure for the
verification process.
Any formal verification tool researcher is
keenly aware that what is a routine verification
for the technology expert or tool developer
may be very difficult for others to duplicate.
Our methodology addresses this problem by
tailoring a formal, custom-built verification
framework, Forte, to industrial-scale circuits
and industrial design environments. Forte com-
bines an efficient, linear temporal logic model-
checking algorithm, called symbolic trajectory
evaluation (STE),2
with lightweight theorem
proving. FL—a custom, general-purpose func-
tional programming language—tightly inte-
grates the model checker and the theorem
prover. This combination of model checking,
theorem proving, and a general-purpose pro-
gramming language makes the verification
environment customizable and lets large veri-
fication efforts be organized effectively.
Our methodology has evolved over several
years of use on fully custom, high-performance
Practical Formal Verification
in Microprocessor Design
Formal Verification
16
Practical application of formal methods requires
more than advanced technology and tools;
it requires an appropriate methodology. A
verification methodology for data-path-dominated
hardware combines model checking and theorem
proving in a customizable framework. This
methodology has been effective in large-scale
industrial trials, including verification of an IEEE-
compliant floating-point adder.
Robert B. Jones, John W. O’Leary, and
Carl-Johan H. Seger
Intel
Mark D. Aagaard
University of Waterloo
Thomas F. Melham
University of Glasgow
0740-7475/01/$10.00 © 2001 IEEE IEEE Design & Test of Computers
Professor Tom Melham
University of Oxford
Symbolic Simulation and Abstraction
for Data Path Verification
Theory, Methodology, and Experience
Formal Verification with Broad-Spectrum
ANSI-C Reference Specifications
Tom Melham, Andreas Tiemeyer,
Daniel Kroening
John O’Leary
Intel Corporation

2. Verification of Tree-Based Hierarchical
Read-Copy Update in the Linux Kernel
Lihao Liang
University of Oxford
Paul E. McKenney
IBM Linux Technology Center
Daniel Kroening and Tom Melham
University of Oxford
Abstract—Read-Copy Update (RCU) is a scalable, high-
performance Linux-kernel synchronization mechanism that runs
low-overhead readers concurrently with updaters. Production-
quality RCU implementations are decidedly non-trivial and their
stringent validation is mandatory. This suggests use of formal
verification. Previous formal verification efforts for RCU either
focus on simple implementations or use modeling languages. In
this paper, we construct a model directly from the source code
of Tree RCU in the Linux kernel, and use the CBMC program
analyzer to verify its safety and liveness properties. To the best
of our knowledge, this is the first verification of a significant part
of RCU’s source code—an important step towards integration of
formal verification into the Linux kernel’s regression test suite.
I. INTRODUCTION
The Linux operating system kernel [1] is widely used,
for example in servers, safety-critical embedded systems,
household appliances, and mobile devices. Over the past 25
years, many technologies have been added to the Linux kernel,
one example being Read-Copy Update (RCU) [2].
RCU is a synchronization mechanism used to replace reader-
writer locks in read-mostly scenarios, allowing low-overhead
readers to run concurrently with updaters. Production-quality
implementations for multi-core systems must provide excellent
scalability, high throughput, low latency, modest memory
footprint, excellent energy efficiency, and reliable response
to CPU hotplug operations. They must therefore avoid cache
misses, lock contention, frequent updates to shared variables,
and excessive use of atomic read-modify-write and memory-
barrier instructions. Finally, implementations must cope with
the extremely diverse workloads and platforms of Linux [3].
RCU is now widely used in the Linux-kernel networking,
device-driver, and file-storage subsystems [3], [4]. There are
at least 75 million Linux servers [5] and 1.4 billion Android
devices [6], so a “million-year” bug can occur several times
per day across the installed base. Stringent validation of RCU’s
complex implementation is thus critically important.
Formal verification has already been applied to some aspects
of RCU design, including Tiny RCU [7], userspace RCU [8],
sysidle [7], and interactions between dyntick-idle and non-
maskable interrupts (NMIs) [9]. But these efforts either validate
trivial single-CPU RCU implementations in C or use special-
of special-purpose modeling languages is difficult and error-
prone translation from source code. Other research has done
manual proof of simple RCU implementations [11], [12], but
this requires significant effort beyond translation. Linux kernel
releases are only about 60 days apart, and RCU changes with
each release. So any manual work must be replicated about
six times a year.
If formal verification is to be part of Linux-kernel RCU’s
regression suite, it must be scalable and automated. This
paper describes how to build a model directly from the Linux
kernel source code, and use the C Bounded Model Checker
(CBMC) [13] to verify RCU’s safety and liveness properties.
II. BACKGROUND
RCU is used in read-mostly situations. Readers run concur-
rently with updaters, so RCU maintains multiple versions of
objects and ensures they are not freed until all pre-existing
readers complete, after a grace period elapses. The idea is
to split updates into removal and reclamation phases [2]. The
removal phase makes objects inaccessible to readers, waits
during the grace period, and then reclaims them. Grace periods
need wait only for readers whose runtime overlaps the removal
phase. Readers starting after the removal phase ends cannot
hold references to any removed objects and thus cannot be
disrupted by objects being freed during the reclamation phase.
Modern CPUs guarantee that writes to single aligned pointers
are atomic, so readers see either the old or new version of
a data structure. This enables atomic insertions, deletions,
and replacements in a linked structure. Readers can then
avoid expensive atomic operations, memory barriers, and cache
misses. In the most aggressive configurations of Linux-kernel
RCU, readers use the same sequence of instructions that would
be used in a single-threaded implementation, providing RCU
readers with excellent performance and scalability.
A. Core RCU API Usage
The core API has five primitives [3], which we now introduce.
A read-side critical section begins with rcu read lock()
and ends with rcu read unlock(). When nested, they are
flattened into one critical section. Within a critical section, it
A Tool for Checking ANSI-C Programs
Edmund Clarke, Daniel Kroening, and Flavio Lerda
Carnegie Mellon University
Abstract. We present a tool for the formal verification of ANSI-C pro-
grams using Bounded Model Checking (BMC). The emphasis is on us-
ability: the tool supports almost all ANSI-C language features, including
pointer constructs, dynamic memory allocation, recursion, and the float
and double data types. From the perspective of the user, the verification
is highly automated: the only input required is the BMC bound. The
tool is integrated into a graphical user interface. This is essential for pre-
senting long counterexample traces: the tool allows stepping through the
trace in the same way a debugger allows stepping through a program.
1 Introduction
We present a tool that uses Bounded Model Checking to reason about low-level
ANSI-C programs. There are two applications of the tool: 1) the tool checks
safety properties such as the correctness of pointer constructs, and 2) the tool
can compare an ANSI-C program with another design, such as a circuit given in
Verilog.
Many safety-critical software systems are legacy designs, i.e., written in a low
level language such as ANSI-C or even assembly language, or at least contain
components that are written in this manner. Furthermore, very often perfor-
mance requirements enforce the use of these languages. These systems are a big-
ger security and safety problem than programs written in high level languages.
The high level languages are usually easier to verify, as they enforce type-safety,
for example. The verification of low level ANSI-C code is challenging due to the
extensive use of arithmetic, pointers, pointer arithmetic, and bit-wise operators.
We describe a tool that formally verifies ANSI-C programs. The properties
checked include pointer safety, array bounds, and user-provided assertions. The
tool implements a technique called Bounded Model Checking (BMC) [1]. In
BMC, the transition relation for a complex state machine and its specification
are jointly unwound to obtain a Boolean formula that is satisfiable if there exists
an error trace. The formula is then checked by using a SAT procedure. If the
formula is satisfiable, a counterexample is extracted from the output of the SAT
procedure. The tool checks that sufficient unwinding is done to ensure that no
longer counterexample can exist by means of unwinding assertions.
The tool comes with a graphical user interface (GUI) that hides the imple-
mentation details from the user. It resembles tools already well-known to soft-
ware engineers. If a counterexample is found, the GUI allows stepping through
the trace like a debugger. We hope to make formal verification tools accessible
to non-expert users this way.
K. Jensen and A. Podelski (Eds.): TACAS 2004, LNCS 2988, pp. 168–176, 2004.
c⃝ Springer-Verlag Berlin Heidelberg 2004
Formal Co-Validation of Low-Level
Hardware/Software Interfaces
Alex Horn⇤, Michael Tautschnig⇤, Celina Val†, Lihao Liang⇤,
Tom Melham⇤, Jim Grundy‡, Daniel Kroening⇤
⇤University of Oxford †University of British Columbia ‡Intel Corporation
Abstract—Today’s microelectronics industry is increasingly
confronted with the challenge of developing and validating
software that closely interacts with hardware. These interactions
make it difficult to design and validate the hardware and
software separately; instead, a verifiable co-design is required
that takes them into account. This paper demonstrates a new
approach to co-validation of hardware/software interfaces by
formal, symbolic co-execution of an executable hardware model
combined with the software that interacts with it. We illustrate
and evaluate our technique on three realistic benchmarks in
which software I/O is subject to hardware-specific protocol rules:
a real-time clock, a temperature sensor on an I2
C bus, and an
Ethernet MAC. We provide experimental results that show our
approach is both feasible as a bug-finding technique and scales
to handle a significant degree of concurrency in the combined
hardware/software model.
I. INTRODUCTION
A growing problem for today’s microelectronics industry is
co-design of hardware alongside embedded, low-level software
that closely interacts with it. In particular, semiconductor
designs are witnessing an increased use of on-chip micro-
controllers running firmware to implement functionality that
would formerly have been implemented in hardware. This trend
is driven by factors that include the following:
• Extracting the control of complex devices and implement-
ing it in firmware can cut development schedules while
adding flexibility and survivability.
• By making on-chip devices more capable, work can
be shifted away from the CPU, where performance is
increasingly hard-won. The richer control required for
more capable devices further drives the trend.
The sorts of devices that are typically integrated on-chip are
controllers for power management, hardware with sequestered
functionality for remote management or secure content, and
increasingly capable graphics processors.
Co-design and validation of such devices together with
their firmware, with the predictability needed to schedule
fabrication and hit market windows, has become an acute
challenge. Similar challenges arise in developing firmware for
systems on chip (SoCs) and general embedded systems [1].
Firmware is just hardware-specific software. One might
therefore expect that the problem can be addressed by some
combination of today’s separate techniques for design and
verification of hardware and software. But the results of
Supported by ERC project 280053 and EPSRC project EP/H017585/1.
this approach are disappointing. The problem is the complex
nature of the interactions at the hardware/software interfaces.
All large systems are structured into subsystems, but the
interfaces between hardware and software subsystems are more
problematic than those in a homogeneous system.
• In a homogeneous design, the documentation of interfaces
(say by header files) is both understandable by developers
and processable by tools. A compiler, for example, can
guarantee some consistency in how two modules view a
shared interface. But hardware and software are typically
described in different languages, processed by separate
tool chains. And the hardware and software design teams
have their own descriptions of the interfaces they share,
with little to ensure the two are consistent.
• The mechanisms for invoking functionality and sharing
data among modules in a homogeneous system, particu-
larly in software, are relatively few. In contrast, the means
of passing information between hardware and software
are varied and built up from nonstandard primitives that
may include interrupts, memory-mapped I/O, and special-
purpose registers. The situation is analogous to software
before procedure-calling conventions were standardized.
• The hardware/software interface also marks a boundary
between different threads of concurrent execution. Without
the shared understanding of synchronization that follows
from a common language and library, concurrency at the
hardware/software interface needs special treatment.
• Finally, a hardware/software interface almost always marks
a boundary between different teams, working in different
parts of a company and having different educational
backgrounds and skills. The scope for misunderstanding
is greater than usual.
The challenges faced by those implementing the two sides
of a hardware/software interface are high—but so is the need
to get it right. Building a system with a new interface and then
testing it to find and remove bugs is a perilous practice. When
designers move the control from a complex hardware device
into firmware, the stripped-down hardware can be difficult to
test without a means to run the firmware. Testing the hardware
and firmware together is difficult before silicon is fabricated:
simulators are slow, emulators expensive, and FPGAs limited
in capacity. Delaying extensive testing until silicon is available
is unacceptable as it serializes the development of hardware
and software to the point where it can be difficult to meet the
Low-Level Code and HW/SW Verification
2010 2011 2012 2013 2014 2015 2016 2017
Intel: Effective Validation of Firmware
HW/SW Co-Verification via Directed
Trace Partitioning
2018 2019
Methodology and Abstraction for
System-Level HW/SW Co-Verification
CBMC

3. Security
Gollum: Modular and Greybox Exploit Generation
for Heap Overflows in Interpreters
Sean Heelan
sean.heelan@cs.ox.ac.uk
University of Oxford
Tom Melham
tom.melham@cs.ox.ac.uk
University of Oxford
Daniel Kroening
daniel.kroening@cs.ox.ac.uk
University of Oxford
ABSTRACT
We present the rst approach to automatic exploit generation for
heap overows in interpreters. It is also the rst approach to exploit
generation in any class of program that integrates a solution for
automatic heap layout manipulation. At the core of the approach
is a novel method for discovering exploit primitives—inputs to
the target program that result in a sensitive operation, such as a
function call or a memory write, utilizing attacker-injected data. To
produce an exploit primitive from a heap overow vulnerability, one
has to discover a target data structure to corrupt, ensure an instance
of that data structure is adjacent to the source of the overow on the
heap, and ensure that the post-overow corrupted data is used in a
manner desired by the attacker. Our system addresses all three tasks
in an automatic, greybox, and modular manner. Our implementation
is called G, and we demonstrate its capabilities by producing
exploits from 10 unique vulnerabilities in the PHP and Python
interpreters, 5 of which do not have existing public exploits.
CCS CONCEPTS
• Security and privacy → Systems security; Software and ap-
plication security.
KEYWORDS
greybox; exploit generation; primitive search
ACM Reference Format:
Sean Heelan, Tom Melham, and Daniel Kroening. 2019. Gollum: Modular
and Greybox Exploit Generation for Heap Overows in Interpreters. In 2019
ACM SIGSAC Conference on Computer and Communications Security (CCS
’19), November 11–15, 2019, London, United Kingdom. ACM, New York, NY,
USA, 18 pages. https://doi.org/10.1145/3319535.3354224
1 INTRODUCTION
Automatic exploit generation (AEG) is the task of converting vulner-
abilities into inputs that violate a security property of the target sys-
tem. Attacking software written in languages that are not memory
safe often involves hijacking the instruction pointer and redirecting
it to code of the attacker’s choosing. The diculty varies, depending
on several parameters. For example, exploiting a stack-based buer
overow in a local le parsing utility, on a system without Ad-
dress Space Layout Randomisation (ASLR) or stack canaries, is well
Permission to make digital or hard copies of part or all of this work for personal or
classroom use is granted without fee provided that copies are not made or distributed
for prot or commercial advantage and that copies bear this notice and the full citation
on the rst page. Copyrights for third-party components of this work must be honored.
For all other uses, contact the owner/author(s).
CCS ’19, November 11–15, 2019, London, United Kingdom
© 2019 Copyright held by the owner/author(s).
ACM ISBN 978-1-4503-6747-9/19/11.
https://doi.org/10.1145/3319535.3354224
within the capabilities of existing AEG systems [4, 13]. However,
by considering stronger protection mechanisms, dierent classes of
target software, or dierent vulnerability classes, one nds a large
set of open problems to be explored.
In this work, we focus on automatic exploit generation for heap-
based buer overows in language interpreters. From a security
point of view, interpreters are a lucrative target because they are
ubiquitous, and usually themselves written in languages that are
prone to memory safety vulnerabilities. From an AEG research
point of view they are interesting as they represent a dierent
class of program from that which has previously been considered.
Most AEG systems are aimed at command-line utilities or systems
that act essentially as le parsers. Interpreters break many of the
assumptions that traditional AEG systems rely upon. One such as-
sumption is that it is feasible to use symbolic execution to eciently
reason about the relationship between values in the input le and
the behaviour of the target. The state space of interpreters is far
too large, and there is far too much indirection between the values
in the input program and the resulting machine state. As we will
see later, many of the exploits we generate require multiple valid
lines of code in the language of the interpreter to be synthesised.
To the best of our knowledge, while there is research showing how
to apply symbolic execution to programs written in interpreted
languages, there is no research which has shown how to eciently
explore the behaviour of interpreters themselves.
Interpreters are prone to multiple classes of vulnerabilities, but
we focus on heap overows for a couple of reasons. Firstly, they are
among the most common type of vulnerability, and secondly they
have only been partially explored from the point of view of AEG.
The exploitation of heap-based buer overows requires reasoning
about the layout of the heap to ensure that the correct data is
corrupted. Previously, researchers have shown [11, 26, 30] how to
generate exploits under the assumption that the layout is correct,
but here we present a solution that can automate the entire process,
including heap layout manipulation.
To address these challenges we present G, a modular,
greybox system for primitive discovery and exploit generation
using heap overows. G takes as input a vulnerability trigger
for a heap overow and a set of test cases, such as the regression test
suite for an interpreter. It produces full exploits, as well as primitives
that can be used in manual exploit creation. G is greybox
in the sense that we use fuzzing-inspired input generation with
limited instrumentation, instead of techniques such as symbolic
execution. It is modular in the sense that we solve the multiple
stages of heap exploit generation separately. This is enabled via a
custom memory allocator, called SS, that allows one
to request a particular heap layout to determine if such a layout
This paper is included in the Proceedings of the
27th USENIX Security Symposium.
August 15–17, 2018 • Baltimore, MD, USA
ISBN 978-1-931971-46-1
Open access to the Proceedings of the
27th USENIX Security Symposium
is sponsored by USENIX.
Automatic Heap Layout Manipulation
for Exploitation
Sean Heelan, Tom Melham, and Daniel Kroening, University of Oxford
https://www.usenix.org/conference/usenixsecurity18/presentation/heelan
ACM CCS’19