Chapter 1
Introduction
When a program is executed on a computer system, that system must be
able to transform the program on disk into a running process image. The
standard format used on Linux and most other UNIX-like systems for rep-
resenting both programs on disk and process images is the ELF (Executable
and Linking Format) [43]. An ELF structure consists of various header in-
formation and an array of named sections, each section containing the data
necessary for some specific part of the process or process lifecycle (e.g. pro-
gram text, writable data, symbol table, dynamic linking information, and so
on). For languages, such as C++, supporting exceptions, the process image
and surrounding mechanisms must include a facility for providing exception
handling. While on Windows a process stores this information on the stack
[28], on Linux and other systems exception handling information is stored in
ELF sections using a standardized format called DWARF (Debugging with
Attributed Records Format) [?]. We show that if an attacker can gain control
of the DWARF data he can perform sophisticated computations unhindered
by standard protections such as non-executable stacks and ASLR. This is
useful in at least two attack scenarios:
1. The adversary creates a trojan by modifying the DWARF sections of
the executable before it is run to create a backdoor. This is less likely
to be noticed than many other trojan techniques because no executable
code is modified and for further reasons discussed later.
2. The adversary exploits a vulnerability ability allowing data overwrite
but not code execution. He uses this exploit to overwrite the DWARF
portion of the executable (or the information used to locate the DWARF
4
