The software monoculture favors attackers over defenders, since it makes all target environments appear similar. Code-reuse attacks, for example, rely on target hosts running identical software. Attackers use this assumption to their advantage by automating parts of creating an attack. This article presents large-scale automated software diversification as a means to shore up this vulnerability implied by our software monoculture. Besides describing an industrial-strength implementation of automated software diversity, we introduce methods to objectively measure the effectiveness of diversity in general, and its potential to eliminate code-reuse attacks in particular.

The number and complexity of attacks on computer systems are increasing. This growth necessitates proper defense mechanisms. Intrusion detection systems play an important role in detecting and disrupting attacks before they can compromise software. Multivariant execution is an intrusion detection mechanism that executes several slightly different versions, called variants, of the same program in lockstep. The variants are built to have identical behavior under normal execution conditions. However, when the variants are under attack, there are detectable differences in their execution behavior. At runtime, a monitor compares the behavior of the variants at certain synchronization points and raises an alarm when a discrepancy is detected. We present a monitoring mechanism that does not need any kernel privileges to supervise the variants. Many sources of inconsistencies, including asynchronous signals and scheduling of multithreaded or multiprocess applications, can cause divergence in behavior of variants. These divergences cause false alarms. We provide solutions to remove these false alarms. Our experiments show that the multivariant execution technique is effective in detecting and preventing code injection attacks. The empirical results demonstrate that dual-variant execution has on average 17 percent performance overhead when deployed on multicore processors.

In a Multi-Variant Execution Environment (MVEE), several slightly different versions of the same program are executed in lockstep. While this is done, a monitor compares the behavior of the versions at certain synchronization points with the aim of detecting discrepancies which may indicate attacks.As we show, the monitor can be implemented entirely in user space, eliminating the need for kernel modifications. As a result, the monitor is not a part of the trusted code base.We have built a fully functioning MVEE, named Orchestra, and evaluated its effectiveness. We obtained benchmark results on a quad-core system, using two variants which grow the stack in opposite directions. The results show that the overall penalty of simultaneous execution and monitoring of two variants on a multi-core system averages about 15% relative to unprotected conventional execution

While memory-safe and type-safe languages have been available for many years, the vast majority of software is still implemented in type-unsafe languages such as C/C++. Despite massive concerted efforts by software vendors such as Microsoft to eliminate buffer overflow vulnerabilities through automated and manual code review, they continue to be found and exploited. We present a novel approach that accepts the existence of overflow vulnerabilities and uses parallelism available through current and future multi-core architectures to detect vulnerabilities by monitoring the parallel execution of several slightly varying instances of the same application. During regular execution each instance performs equivalent computations. When an attacker attempts to inject an attack vector through a buffer overflow vulnerability, however, each instance reacts differently due to the variances we introduced into each instance. We describe our prototype implementation of such a parallelism-based buffer overflow detection system and demonstrate that it is capable of stopping buffer overflow vulnerabilities using actual exploit codes for the popular Apache Web server. The experimental results show that the runtime overhead of our parallel execution framework is less than 10% on average.