AFRL-IFRS-TR-2004-102 Final Technical Report April 2004 AN ANALYTICAL INVESTIGATION OF SOFTWARE MUTATION FOR INCREASED INFORMATION SURVIVABILITY Reliable Software Technologies

interpretation techniques generally have two important drawbacks. First, the abstract representations can be voluminous and thus tax system resources. Second, some semantic information is hard to translate into the desired abstract form (a notable example being behavior that results from pointer aliasing). A more practical issue is that the programs we are interested in here are procedural or object-oriented, which is a representation quite different from the one we seek. This means that the implementation of a general-purpose abstract interpretation is time-consuming due to the sheer number of diverse features that must be implemented. All of these limitations can be sidestepped in a system that uses abstract interpretation to implement diversity. Instead of insisting that S1 represent the semantics of whole programs, we can use a number of different mappings in place of M1 to extract the semantics of small sections of the program. The size of the abstract behavioral descriptions can be bounded by limiting the size and number of program chunks whose semantics are represented. Program features that cannot be represented, or ones that require features not yet implemented in the abstract interpretation system, can simply be left out of the process by choosing program chunks that do not span such features (for example, if loops are not supported, we might treat the body of the loop, a section of code before the loop, and a section of code after the loop as three distinct code-chunks.) At any given time, we can randomly select which parts of the program we represent abstractly. This is in accordance with the principle of randomization outlined in Section 3. An attack may go unattended because it does not exploit the semantics being mapped, but since the choice of what to map is made randomly, there is a certain probability that the attack will affect part of the semantics that are being replicated. If we take some corrective action, then this probability is just the survival probability discussed in section 3. In fact, even if we just raise an alarm when the actual and expected program behaviors diverge (as we do in the system we will shortly describe), we still have a diverse system, though it is now the intrusion detector that is diverse, and fooling a particular intrusion detector is analogous to subverting it. 5.1 Details of the System for Extracting and Monitoring Behavioral Constraints In this section, we describe our framework for extracting behavioral information from programs. In our original proposal, it was meant to help us in finding mutants that preserved the intended semantics of the original program, but it became the backbone of what we believe is a more viable approach to diversity, based on monitoring a program’s compliance with semantic constraints. In this section, we will describe our system for analyzing program behavior, and our use of that system to create diversity in critical systems. The original aim of our mutation system was to create only equivalent mutants, that is, mutants whose semantics were (superficially) the same as those of the original program. The motivation for this is that, in reality, the semantics elements of a program can be divided into intentional semantics and incidental semantics. The intentional semantics describe the behavior that must be present to fulfil a program’s specification, and the unintentional semantics describe incidental behavior, such as the writing of temporary files, the specific choices of data structures, and, in principle, even such details as what memory locations are allocated and how much the program heats up the CPU. The motivation for our approach to survivability was that malicious attacks often take advantage of incidental semantics. Indeed, such attacks are especially troublesome because they exploit vulnerabilities not apparent in the specification. If an attack relied on nothing but the semantics given in a specification, then the vulnerability could (at least in principle) be uncovered by a formal methods. Therefore, we intended to build a mutation system that could preserve the intentional sematics of a program, while altering the incidental semantics. In the language of mutation analysis, the goal was to create equivalent mutants. Existing software mutation systems already have mechanism for identifying equivalent mutants, though this is done to avoid them and not to generate them. Our intent was to reverse the standard approach.