Address-space randomization is a technique used to fortify systems against buffer overflow attacks. The idea is to introduce artificial diversity by randomizing the memory location of certain system components. This mechanism is available for both Linux (via PaX ASLR) and OpenBSD. We study the effectiveness of address-space randomization and find that its utility on 32-bit architectures is limited by the number of bits available for address randomization. In particular, we demonstrate a derandomization attack that will convert any standard buffer-overflow exploit into an exploit that works against systems protected by address-space randomization. The resulting exploit is as effective as the original, albeit somewhat slower: on average 216 seconds to compromise Apache running on a Linux PaX ASLR system. The attack does not require running code on the stack. We also explore various ways of strengthening addressspace randomization and point out weaknesses in each. Surprisingly, increasing the frequency of re-randomizations adds at most 1 bit of security. Furthermore, compile-time randomization appears to be more effective than runtime randomization. We conclude that, on 32-bit architectures, the only benefit of PaX-like address-space randomization is a small slowdown in worm propagation speed. The cost of randomization is extra complexity in system support.

Since sensor applications are implemented in embedded computer systems, cyber attacks that compromise regular computer systems via exploiting memory-related vulnerabilities present similar threats to sensor networks. However, the paper shows that memory fault attacks in sensors are not just the same as in regular computers due to sensor’s hardware and software architecture. In contrast to worm attacks, malcodes carried by exploiting packets cannot be executed in a sensor. Therefore, the paper proposes a range of attack approaches to illustrate that a mal-packet, which only carries specially crafted data, can exploit memory-related vulnerabilities and utilize existing application codes in a sensor to propagate itself without disrupting sensor’s functionality. The paper shows that such a mal-packet can have as few as 17 bytes. A prototype of a 27-byte mal-packet has been implemented and tested in Mica2 sensors. Simulation shows that the propagation pattern of such a mal-packet in a sensor network is very different from worm propagation. Mal-packets can either quickly take over the whole network or hard to propagate under different traffic situations.

This paper explores “return-oriented programming, ” a technique by which an attacker can induce arbitrary behavior in a program whose control flow he has diverted — without injecting any code. A Return-oriented program chains together short instruction sequences already present in a program’s address space, each of which ends in a “return ” instruction. Return-oriented programming defeats the W⊕X protections recently deployed by Microsoft, Intel, and AMD; in this context, it can be seen as a generalization of traditional “return-into-libc” attacks. But the threat is more general: return-oriented programming is readily exploitable on multiple architectures, and bypasses an entire category of malware protections. To demonstrate the wide applicability of return-oriented programming, we construct a Turingcomplete set of building blocks called gadgets using the standard C library from each of two very different architectures: Linux/x86 and Solaris/SPARC. To demonstrate the power of returnoriented programming, we present a high-level, general-purpose language for describing returnoriented exploits and a compiler that translates it to gadgets. We argue that the threat posed by return-oriented programming, across all architectures and systems, has negative implications for an entire class of security mechanisms: those that seek to prevent malicious computation by preventing the execution of malicious code.

For most computer end–users, web browsers and Internet services act as the providers and protectors of their personal information, from bank accounts to personal correspondence. These systems are critical to users ’ continued lifestyles but often show no evidence of survivability [45], or robustness against present and future attacks. Software defects, considered the largest risk to survivability [45], are quite prevalent in consumer products and Web service software components [12]. Recent widespread security issues [20] [19] serve to emphasize this fact and show a lack investment in survivability engineering

We present a practical tool for inserting security features against low-level software attacks into third-party, proprietary or otherwise binary-only software. We are motivated by the inability of software users to select and use low-overhead protection schemes when source code is unavailable to them, by the lack of information as to what (if any) security mechanisms software producers have used in their toolchains, and the high overhead and inaccuracy of solutions that treat software as a black box. Our approach is based on SecondWrite, an advanced binary rewriter that operates without need for debugging information or other assist. Using SecondWrite, we insert a variety of defenses into program binaries. Although the defenses are generally well known, they have not generally been used together because they are implemented by different (non-integrated) tools. We are also the first to demonstrate the use of such mechanisms in the absence of source code availability. We experimentally evaluate the effectiveness and performance impact of our approach. We show that it stops all variants of low-level software attacks at a very low performance overhead, without impacting original program functionality. 1

Abstract—Code reuse attacks (CRAs) are recent security exploits that allow attackers to execute arbitrary code on a compromised machine. CRAs, exemplified by return-oriented and jump-oriented programming approaches, reuse fragments of the library code, thus avoiding the need for explicit injection of attack code on the stack. Since the executed code is reused existing code, CRAs bypass current hardware and software security measures that prevent execution from data or stack regions of memory. While softwarebased full control flow integrity (CFI) checking can protect against CRAs, it includes significant overhead, involves non-trivial effort of constructing a control flow graph, relies on proprietary tools and has potential vulnerabilities due to the presence of unintended branch instructions in architectures such as x86—those branches are not checked by the software CFI. We propose branch regulation (BR), a lightweight hardware-supported protection mechanism against the CRAs that addresses all limitations of software CFI. BR enforces simple control flow rules in hardware at the function granularity to disallow arbitrary control flow transfers from one function into the middle of another function. This prevents common classes of CRAs without the complexity and run-time overhead of full CFI enforcement. BR incurs a slowdown of about 2 % and increases the code footprint by less than 1 % on the average for the SPEC 2006 benchmarks.

Code Reuse Attacks (CRAs) recently emerged as a new class of security exploits. CRAs construct malicious programs out of small fragments (gadgets) of existing code, thus eliminating the need for code injection. Existing defenses against CRAs often incur large performance overheads or require extensive binary rewriting and other changes to the system software. In this paper, we examine a signature-based detection of CRAs, where the attack is detected by observing the behavior of programs and detecting the gadget execution patterns. We first demonstrate that naive signature-based defenses can be defeated by introducing special "delay gadgets" as part of the attack. We then show how a softwareconfigurable signature-based approach can be designed to defend against such stealth CRAs, including the attacks that manage to use longer-length gadgets. The proposed defense (called SCRAP) can be implemented entirely in hardware using simple logic at the commit stage of the pipeline. SCRAP is realized with minimal performance cost, no changes to the software layers and no implications on binary compatibility. Finally, we show that SCRAP generates no false alarms on a wide range of applications. 1.