94 C O M P U T E R P U B L I S H E D B Y T H E I E E E C O M P U T E R S O C I E T Y 0 0 1 8 - 9 1 6 2 / 1 6 / $ 3 3 . 0 0 © 2 0 1 6 I E E E

CYBERTRUST

Having identical software running on many plat-forms—a software monoculture—gives cyber-attackers a signi� cant advantage. An attacker who gains access to the software can analyze

it to locate vulnerabilities. Once the attacker has created an exploit, all of the machines running the same software become potential targets.

Biological populations face a similar challenge. If all members are vulnerable to attack from a biological agent, that single agent could destroy the entire population. Nature uses diversity to protect against this eventuality: members di� er in some way so that, for most agents, a fraction of the population isn’t vulnerable. In any given population of bacteria, for example, slight DNA varia-tion among members protects some against an antibiotic. There’s a downside to diversity, of course—in this case, the emergence of drug- resistant bacteria.

Diversity in nature has served biological populations well, which leads to the question of whether it could also

be exploited in computing. The an-swer is a resounding yes, especially in cybersecurity.

DIVERSITY IN COMPUTINGDiversity in computing comes in many forms and has a long history. One of the � rst examples was when British astronomer Nevil Maskelyne

employed simple versions of diversity to improve naviga-tion table calculations at the Royal Greenwich Observa-tory at the turn of the 19th century.1 Several decades later, Charles Babbage, credited with originating the concept of a programmable computer, discussed the importance of diversity—though not by that name—in improving the accuracy of his analytical engine.2

In modern times, the initial incentive to exploit di-versity was to avoid software failures. Hardware wear- out failures can be detected and masked by operating multiple identical units in parallel and voting on their results. Software doesn’t wear out, however, and run-ning multiple identical software instances in parallel provides no value.

Software does su� er from design faults, so rather than identical copies of software, what’s needed are multiple software versions with identical functionality but di� er-ent designs— known as design diversity.3 Because many security vulnerabilities are actually software faults, de-

Diversity in CybersecurityJohn Knight, Jack Davidson, Anh Nguyen-Tuong, Jason Hiser, and Michele Co, University of Virginia

Randomizing software characteristics can

help thwart cyberattacks by denying critical

information about a target system previously

known to an attacker.

A P R I L 2 0 1 6 95

EDITOR JEFFREY VOASNational Institute of Standards and Technology; j.voas@ieee.org

sign diversity o� ers the possibility of protection against cyberattacks.

A particular data item often takes values that are of interest to an at-tacker. For example, many Unix sys-tems associate the user identi� er (UID) value of zero with the super user. This common value facilitates an attacker’s ability to gain super- user privileges. Some protection can be a� orded by using a di� erent data value on each system with minor software changes to accommodate the di� erent data values. The idea of varying data val-ues across di� erent system instances, known as data diversity,4 was origi-nally introduced in the context of soft-ware dependability.

Design diversity relies upon useful di� erences in version designs arising by chance. In contrast, data diversity requires explicit code changes to ac-commodate di� erences in the map-ping of data values to semantics. If the changes are made carefully, an attacker must recover the mapping to e� ect what was previously a much simpler exploit.

ARTIFICIAL DIVERSITYThe power of data diversity has led to the application of various mechani-cal transformations, known as arti� -cial diversity, to production systems. Arti � cial diversity has been shown to provide signi� cant value in the cyber-security � eld.

The basic idea is to change some program characteristic in a way that denies an attacker straightforward access. The transformation doesn’t eliminate vulnerabilities; rather, it makes vulnerabilities di� cult to ex-ploit, because critical information needed for the exploit has changed to a random value. For example, if the locations of items in a stack frame are randomized, the data is still there but an adversary can no longer predict the o� sets.

EntropyThe di� culty an attacker encounters— the need to search for information that previously was readily available—is the transformation’s entropy. In the stack- frame randomization example, the di� culty appears to be minimal. Most stack frames contain only a small num-ber of � elds, and, even after random-ization, a determined attacker could search through all possible stack layouts and � nd the one being used relatively quickly. In any given program, however, the stack frame must be determined for all of the functions of interest to the at-tacker, and the stack- frame layouts will di� er for each program instance; know-ing one program instance doesn’t yield access to others. Thus, an important goal of arti� cial diversity is to maximize the search time that the attacker faces. Some transformations have been shown to have extremely high entropy.

Transformation implementationsFor source programs, transformations can be implemented by manipulating the source code or the way the com-piler generates binary code. For binary programs, the transformations can be applied statically using a binary re-writer, or dynamically using dynamic binary translation, a just- in- time (JIT) compilation process. Four examples of transformation developed for binary programs are address- space layout randomization (ASLR), instruction- set randomization (ISR), stack layout transformation (SLX), and instruction layout randomization (ILR).

Address- space layout random ization. ASLR randomizes memory layout— the locations of the stack, heap, and code libraries. The randomization is limited to the absolute address where the item is loaded. The goal is to thwart attacks that rely on knowing the loca-tion of speci� c code or data targets. ASLR is the most successful arti� cial

diversity technique to date and is widely deployed on commodity OSs in-cluding Linux, Windows, OS X, and iOS. A common criticism of ASLR is that its randomization is too coarse grained. For example, while a library will be loaded at di� erent addresses in di� erent program instantiations, the relative distance of any two instructions remains constant. Thus, inferring any code address, possi-bly via an information- leakage attack, reveals the entire library’s layout. To remedy this weakness, higher- entropy diversity transformations should be composed with ASLR.

Instruction- set randomization. ISR is designed to thwart code- injection at-tacks. The concept is to target a hypo-thetical, nonexistent instruction set; store the program in that form; and translate to the actual hardware at ex-ecution time using a JIT compiler. An attacker could try to inject code into the binary program, but without knowing the random instruction set’s details, any injected code will be invalid on the hypothetical processor. The JIT compiler could detect this and take corrective action. ISR is a strong defense against code- injection attacks irrespective of the vulnerability.

A variant of ISR is to encrypt the orig-inal binary program and decrypt it on the � y during execution. This form of ISR has been implemented using the Ad-vanced Encryption Standard (AES). En-cryption with AES doesn’t require stor-age of the encryption key on disk, as the key is generated dynamically when the program is loaded. In addition, each ex-ecution of a given application uses a dif-ferent key, so an attacker who monitors execution and tries to reverse- engineer the encryption learns nothing that could be exploited in future executions.

Stack layout transformation. SLX is designed to thwart stack- based attacks, including intraframe over� ows and

96 C O M P U T E R W W W . C O M P U T E R . O R G / C O M P U T E R

CYBERTRUST

noncontrol data attacks. It random-izes the order of local variables in each function’s stack frame, adds random- length padding between variables, and inserts canaries—random values that are checked periodically—be-tween variables.

The implementation of SLX re-quires defining a new stack layout, modifying instructions that access or manipulate the stack to be consistent with the new layout, adding instruc-tions to set and check canary values during execution, and changing the function prolog to increase the stack frame’s size to accommodate padding and canaries. All of these changes can

be made by static translation of the bi-nary program.

SLX doesn’t offer high entropy, but padding with deceptive content be-tween variables generates doubt about the location of the borders between variables. Thus, to succeed with the attack, the attacker must determine the variables’ order and boundaries. Padding increases entropy consider-ably but at the cost of increased mem-ory requirements.

Instruction layout randomization. ILR randomizes the location of every individual machine instruction in a program. Each instruction’s successor

is specified explicitly, so the succes-sor’s location is independent of that instruction’s location. This allows in-structions to be scattered randomly throughout the memory space, and ILR can use the processor’s full ad-dress space—for example, all 32 bits of the x86. Hiding the explicit successor information prevents an attacker from predicting one instruction’s location based on knowledge of another. JIT compilation implements ILR’s non-sequential execution model by re-assembling the original instruction sequence on the fly.

ILR changes a fundamental software characteristic often used by attackers: predictable code layout. Attackers rou-tinely rely on this property to craft at-tacks such as arc injection and various forms of return- oriented programming. Because instructions are in a random order, ILR’s entropy is extremely high.

Security efficacyThe security efficacy of artificial di-versity depends on the entropy intro-duced, the randomization’s complete-ness, the ability to keep randomization keys secret, and the security of the im-plementation itself. Transformations often provide significant entropy that can cause an attacker immense diffi-culty, and protecting randomization keys is similar to any key protection challenge. The implementation’s se-curity is an important issue for all transformations, as the software is being changed; in most cases, addi-tional software is inserted. Great care must be exercised to avoid introduc-ing new vulnerabilities or changing functionality.

The practicality of artificial diver-sity is also affected by the execution time and space overhead added by the transformation process.5

Implementing transformationsWe’ve developed a tool chain called Helix that effects the transformations just described (except ASLR) along with many others. Helix targets Intel x86 binary programs and supports both

Staticanalysis anddisassembly

Originalbinary �le

IntermediateRepresentationDatabase (IRDB)

Dynamicbinary

translator

Binaryrewriter

Transformedbinary �le

Tran

sfor

mat

ion

libra

ry

ILR,

ISR,

SLX

, ...

Figure 1. Overall architecture of Helix, a tool chain that effects artificial diversity transformations. First, the target binary program is subject to static analysis and disassembly, and then the program is entered into the IRDB, with each machine instruction stored as a separate record. ILR: instruction layout randomization, ISR: instruction-set randomization, SLX: stack layout transformation.

A P R I L 2 0 1 6 97

static binary rewriting and dynamic bi-nary translation.

Figure 1 shows the overall architec-ture of Helix. First, the target binary program is subject to static analysis and disassembly, and then the program is entered into the Intermediate Represen-tation Database (IRDB), with each ma-chine instruction stored as a separate record. Storing the program in this way facilitates arbitrary transformations, as the individual instructions can be ma-nipulated separately. Transformations are applied by creating a copy of the pro-gram in the IRDB and manipulating the instructions as necessary.

SECRETLESS SECURITYArtificial diversity as described so far relies on some sort of secret, such as a randomization key. The result is a probabilistic measure of protection— the probability that adversaries won’t be able to determine the secret us-ing a state- space search in a practical amount of time. An insider collabo-rating with an attacker or some sort of weakness in the security protection of the secret could destroy all of the ex-pected security benefits.

A variation of artificial- diversity techniques has been developed that, for specific classes of vulnerability and with certain fairly weak assumptions, eliminates this dependence on a secret and provides provable rather than prob-abilistic security protection. The basic concept is to apply artificial diversity using more than one randomization key (N) so as to produce N variants of the original software. At execution time, all of the N variants are executed in parallel with the same inputs and their results are compared by a monitor.6–9

They should have identical functional-ity, and so under normal operation, the results of the N variants should be the same. Any difference is an indication of an attack, and the monitor can then take suitable defensive action.

Figure 2 shows a simple instance of artificial diversity in which there are two variants (N = 2). Suppose that in one variant, all code addresses are

located in the lower half of memory, and in the other, all code addresses are in the upper half of memory. During operation of this system, both variants are executed in parallel with all inputs being supplied to both. Clearly, the ar-tificial diversity shouldn’t affect either variant’s functionality.

On such a system, to perform a code- injection attack or a return- oriented programming attack with a payload that includes absolute memory ad-dresses, the malicious payload would have to include addresses with both a 0 and a 1 in the most significant bit. Clearly, this is impossible. An attack that depended on absolute addresses could affect one of the variants but not both in such a way that their func-tionality was identical. The variants would thus diverge, and the monitor would detect the resulting difference in functionality.

Note that there’s only one bit of en-tropy in this example and that the de-tails of the diversity—the value of the most significant bit in the address—needn’t be kept a secret. Knowing this doesn’t help the attacker. Further, if an insider provided details of the sys-tem or vulnerabilities, the information would still not make an attack possible.

Artificial diversity is a powerful security tech nology that can be applied to either source or

binary programs. In the latter’s case, the source code needn’t be available and no rebuilding of the binary is required. An enhancement to the technique, secret-less security, allows protection without the need for any conventional secrets such as randomization keys.

The classes of vulnerabilities for which artificial diversity offers protec-tion are extensive. By applying multiple transformations to a single program, the benefits of each can be combined. The observed overhead varies with the transformations. In many cases, execution- time overhead is only a few percent, making the technique quite practical.

Randomization, which is at the heart of artificial diversity, needn’t be fixed. Re- randomization can be con-ducted either before or during execu-tion. An artificially diverse program can be re- randomized on disk or upon program start-up, providing long- term protection against malicious access to the randomization key. In addition, with care, a program can be stopped, re- randomized, and restarted in what amounts to a moving- target defense.

ACKNOWLEDGMENTSThe research described in this article is supported by National Science Founda-tion (NSF) grant CNS- 0811689; Army Re-search Office (ARO) grant W911-10-0131; Air Force Research Laboratory (AFRL) contracts FA8650-10-C-7025, FA8750-13-2-0096, and FA8750-15-2-0054; and US De-partment of Defense (DoD) AFOSR MURI grant FA9550-07-1-0532. The views and conclusions contained herein are those of the authors and should not be interpreted

Variant 2Variant 1

Monitor

Output

Input

Figure 2. N-variant system architec-ture. At execution time, all N software variants (in this case, N = 2) are executed in parallel with the same inputs, and their results are compared by a monitor. Any difference is an indication of an attack, and the monitor can then take suitable defensive action.

98 C O M P U T E R W W W . C O M P U T E R . O R G / C O M P U T E R

CYBERTRUST

as necessarily representing the official policies or endorsements, either ex-pressed or implied, of the NSF, AFRL, ARO, DoD, or US government.

REFERENCES1. N. Maskelyne, Papers of Nevil Maske-

lyne, GBR/0180/RGO 4, Royal Green-wich Observatory Archives; http://cudl.lib.cam.ac.uk/collections/rgo4.

2. C. Babbage, “On the Mathematical Powers of the Calculating Engine,” The Origins of Digital Computers: Selected Papers, 3rd ed., B. Randell, ed., Springer, 1982, pp. 19–54.

3. A. Avizienis, “N-Version Program-ming: A Fault-Tolerance Approach to Reliability of Software Operation,” IEEE Trans. Software Eng., vol. 11, no. 12, 1985, pp. 1491–1501.

4. P.E. Ammann and J.C. Knight, “Data Diversity: An Approach to Software Fault Tolerance,” IEEE Trans. Comput-ers, vol. 37, no. 4, 1988, pp. 418–425.

5. J.D. Hiser et al., “ILR: Where’d My

Gadgets Go?,” Proc. IEEE Symp. Security and Privacy (SP 12), 2012, pp. 571–585.

6. B. Cox et al., “N-Variant Systems: A Secretless Framework for Security through Diversity,” Proc. 15th USE-NIX Security Symp. (USENIX-SS 06), vol. 15, 2006, article 9.

7. D. Bruschi, L. Cavallaro, and A. Lanzi, “Diversified Process Replicæ for Defeating Memory Error Exploits,” Proc. 3rd IEEE Int’l Work-shop Information Assurance (WIA 07), 2007, pp. 434–441.

8. B. Salamat et al., “Orchestra: Intru-sion Detection Using Parallel Exe-cution and Monitoring of Program Variants in User-Space,” Proc. 4th ACM European Conf. Computer Systems (EuroSys 09), 2009, pp. 33–46.

9. A. Nguyen-Tuong et al., “Security through Redundant Data Diversity,” Proc. IEEE Int’l Conf. Dependable Sys-tems and Networks with FTCS and DCC (DSN 08), 2008, pp. 24–27.

JOHN KNIGHT is a professor of computer science at the University of Virginia. Contact him at knight@cs.virginia.edu.

JACK DAVIDSON is a professor of computer science at the University of Virginia. Contact him at jwd@cs.virginia.edu.

ANH NGUYEN-TUONG is a senior scientist at the University of Virginia. Contact him at nguyen@cs.virginia .edu.

JASON HISER is a senior scientist at the University of Virginia. Contact him at jdh8d@cs.virginia.edu.

MICHELE CO is a research scientist at the University of Virginia. Contact her at mc2zk@cs.virginia.edu.

got flaws?Find out more and get involved:

cybersecurity.ieee.org

Selected CS articles and columns are also available for free at http://ComputingNow .computer.org.