Synthetic Diversity for Intrusion Tolerance
James E. Just*
Global InfoTek, Inc.
jjust@globalinfotek.com
Abstract
The increasing monoculture in operating systems and
key applications and the enormous expense of N-version
programming for custom applications mean that lack of
diversity is a fundamental barrier to achieving
survivability even for high value systems that can afford
hot spares. We propose synthetic diversity, implemented
at the executable code level, to reduce the common mode
failure problem in COTS applications potentially by
several orders of magnitude. We analyze vulnerabilities
to identify those potentially affected by diversity and
examine key assumptions used in developing successful
attacks against those vulnerabilities. There are enough
techniques for producing synthetic diversity in the
literature that the approach is feasible.
1. Introduction
There is a great desire for affordable, robust systems
that respond automatically to accidental and deliberate
faults. The current state of the art employs fault-
tolerance technologies for accidental faults and errors
and intrusion-tolerance technologies for malicious,
intentional faults caused by an intelligent adversary.
Combining fault- and intrusion-tolerance technologies
can produce very robust and survivable systems, but such
systems have an Achilles heel. Their robust performance
depends upon the continued existence of spare resources
for failover. Spare resources can be depleted by a
determined adversary simply by continued attacks until
the system can no longer maintain critical functionality.
2. Breaking Vulnerability Specifications
Binary code is the main integration point for software
on specific operating systems (Windows/Solaris/ Linux)
and hardware architectures (Intel/Sparc). Binaries
provide common interfaces (abstract machines) that
interpret code according to highly specific rules and
conventions like run-time environment management,
calling library routines, or addressing in-memory tables.
We suggest an approach to synthetic diversity that
randomizes critical information in the binary to alter the
interface and representation conventions in such a way
that injected code no longer functions and existing code
is no longer reachable. Such transformations can be
discussed in the language of software verification by
Mark Cornwell
Global InfoTek, Inc.
mcornwell@globalinfotek.com
viewing specifications as objects that capture
assumptions about software. Specifications are more
abstract than the programs themselves, because many
different programs may implement the same
specification. A tenet of software engineering is that any
program that uses another program should only uses the
assumptions that are allowed by the specification.
The author of any wide-spread attack, such as Code
Red, must identify the specific vulnerability details in a
widely deployed application and how to exploit that
vulnerability in an attack. Details are important because
most attacks are executable code and every bit counts.
For example, the author might look for a flaw such as a
buffer overrun that allows one to write data into the
runtime stack or heap. He must then identify specific
locations that are branching addresses and exploit them
to point to his injected code. This injected code must
find and execute system calls at the binary level to access
system resources, talk over the network, propagate itself
further, and do whatever other tasks the author intends.
These details can be viewed as a Vulnerability
Specification or V-SPEC from the perspective of the
attacker. A program that supports the assumptions of the
V-SPEC is vulnerable to that attack. Programs not
supporting the V-SPEC are invulnerable to that particular
attack. This is illustrated below.
Software
Current Specification
Attack Source
Code
Problem
Known Executable
V-Spec Code
Vu
ln
er Linker
ab
ili
ty
Loader
Attack
Machine-level
Code
Machine Code
Specification
Our approach transforms programs in ways that break
the V-SPEC, without affecting legitimate assumptions
about program behavior, which we refer to as the A-
SPEC. It is not necessary that we know the precise A-
SPEC in order to make use of the concept. We merely
need confidence that, after applying transformations, the
runtime executable still conforms to the A-SPEC. For
example, if random sized blocks of information are 10 inc ebx ; Increment by 1
11 dec ebx ; Decrement by 1
pushed onto the stack to make stack locations harder to 12 inc ebx ; Increment by 1
predict, legitimate programs be affected by such things. 13 dec ebx ; Decrement by 1
14 mov ecx, [ebp-1B4h] ; load ecx with ebp-1b4
In our terminology, ideal diversity inducing 15 mov [ebp+ecx*4-174h], eax ; load the address into
transformations will have the property that they are both the ebp stack where needed
V-SPEC variant and A-SPEC invariant. Once RVA techniques are used to get the address of
GetProcAddress, GetProcAddress is used to get the
Software
Specification address of LoadLibraryA (not illustrated above). The
Breaking worm uses these two functions to load kernel32.DLL,
Transform
infocomm.DLL and WS2_32.DLL enabling it to access
the V-Spec Source
Code
Specifications
the file system, open network sockets and send and
receive network packets. The worm is making many
Known Executable
V-Spec Code assumptions about how to interact with the Windows
Vu
ln
operating system and these assumptions are sensitive to
er Transformer particular types of code transformations.
ab Machine-level
ili Machine-level Linker
ty
?? Code
Machine-level
Machine-level Code Loader We extensively reviewed the literature for
Code
Machine-level
Code
Machine-level
Machine-level
Code
transformations that are applicable to executable code
Code Machine-level
Code Machine-level
Attack X Machine-level
Code Code
Machine-level Code
Machine-level
and concluded that our approach is feasible. Consider the
Doesnt
Match
Machine-level
Code
Machine-levelCode
Machine Code
following mechanical transformations:
Code Code
Specification Re-arrange the run-time stack
V-Spec Unknown Until Load-Time
Permute the addresses in the jump table
Change the machine code (table transformation)
3. Illustrative Example Change the interpretation of (encrypt) filenames
Change the order of parameters for system calls
Most of the recent large-scale cyber-attacks have been
Encrypt file name parameters to system calls
worms that relied on buffer overflow vulnerabilities in
Rename ports for network connections
widely deployed Windows applications. The current
Windows monoculture gives even casual attackers, Put return pointers on a separate stack
armed with buffer overflow attack code, the potential to Any one of these transformations could break Code
break into essentially every vulnerable computer Red. For example, if we changed the order of
connected to the network. This enormous reach provided parameters to GetProcAddress, the order of the push
to the attacker can adversely affect the network itself, operations at lines 4 and 6 would be invalid. We would
overloading links and cause routing table instabilities. have prevented Code Red from resolving the addresses it
The Code Red I worm has been studied extensively. It needs to call socket, connect, send, recv, TcpSockSend,
is a single http GET transaction that exploits a buffer etc. When the call at line 7 is performed, with high
overflow vulnerability in the Index Server resource to probability the call would fail with an invalid opcode or
execute arbitrary code. The following selection of addressing exception as it attempted to execute the
disassembled code shows some of the techniques and relative virtual address table.
assumptions used by the worm writer1. The technique
illustrated is called RVA (Relative Virtual Address) 4. Conclusions and Next Steps
lookup2. The disassembled code is on the left of the
listing below and the eEye Digital Security annotations Program diversity through randomized program
to each line are on the right. Lines 09 through 13 below transformation harnesses powerful theoretical techniques
have no net effect and are used for padding. to introduce much needed diversity into modern
01 loc_4B4: ; CODE XREF: DO_RVA+26D j networks3. Our concept for a synthetic diversity system
02 mov esi, esp
03 mov ecx, [ebp-198h]; set ecx with the data focuses on breaking the vulnerability specifications that
segment pointer successful attacks depend on. We believe the potential
04 push ecx; push data segment (pointer of function
to load)
for practical application of these techniques is high.
05 mov edx, [ebp-1CCh]; get current RVA base offset
06 push edx; push module handle(base loaded address)
3
07 call dword ptr [ebp-190h]; call GetProcAddress Diversity is not a panacea for cyber-attack problems. Many
08 cmp esi, esp ; Compare Two Operands vulnerabilities cannot be mitigated by diversity, e.g., weak passwords,
09 nop ; No Operation cross site scripting attacks, and denial of service. However, diversity at
the level of interpreting scripting languages can be effective in
1
Excerpted from Code Red Disassembly Analysis, Ryan Permeh, analogous ways [See [Kc-03] Gaurav S. Kc, Angelos D. Keromytis,
Marc Maiffret, at http://www.eeye.com/html/advisories/codered.zip. Vassilis Prevelakis, Countering Code-Injection Attacks with
2
For more details on RVA, check documentation on Portable Instruction-Set Randomization ACM Conference on Computer and
Executable (PE), the executable file format for Microsoft platforms. Communications Security, October 27, 2003, Washington DC