Preventing Buffer Overflows with Binary Rewriting

Buffer overflows are the single largest cause of security attacks in recent times. Attacks based on this vulnerability have been the subject of extensive research and a significant number of defenses have been proposed for dealing with attacks of this nature. However, despite this extensive research, buffer overflows continue to be exploited due to the fact that many defenses proposed in prior research provide only partial coverage and attackers have adopted to exploit problems that are not well defended. The fact that many legacy binaries are still deployed in production environments also contributes to the success of buffer overflow attacks since most, if not all, buffer overflow defenses are source level defenses which require an application to be re-compiled. For many legacy applications, this may not be possible since the source code may no longer be available. In this thesis, we present an implementation of a defense mechanism for defending against various attack forms due to buffer overflows using binary rewriting. We study various attacks that happen in the real world and present techniques that can be employed within a binary rewriter to protect a binary from these attacks. Binary rewriting is a nascent field and little research has been done regarding the applications of binary rewriting. In particular, there is great potential for applications of binary rewriting in software security. With a binary rewriter, a vulnerable application can be immediately secured without the need for access to it's source code which allows legacy binaries to be secured. Also, numerous attacks on application software assume that application binaries are laid out in certain ways or have certain characteristics. Our defense scheme implemented using binary rewriting technology can prevent many of these attacks. We demonstrate the effectiveness of our scheme in preventing many different attack forms based on buffer overflows on both synthetic benchmarks and real-world attacks

Retrofitting Security in COTS Software with Binary Rewriting

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

Effective Memory Diversification in Legacy Systems

Memory corruption error is one of the critical security attack vectors against a wide range of software. Addressing this problem, modern compilers provide multiple features to fortify the software against such errors. However, applying compiler-based memory defense is problematic in legacy systems we often encounter in industry or military environments because source codes are unavailable. In this study, we propose memory diversification techniques tailored for legacy binaries to which we cannot apply state-of- the-art compiler-based solutions. The basic idea of our approach is to automatically patch the machine code instructions of each legacy system differently (e.g., a drone, or a vehicle firmware) without altering any semantic behavior of the software logic. As a result of our system, attackers must create a specific attack payload for each target by analyzing the particular firmware, thus significantly increasing exploit development time and cost. Our approach is evaluated by applying it to a stack and heap of multiple binaries, including PX4 drone firmware and other Linux utilities

Shining Light On Shadow Stacks

Control-Flow Hijacking attacks are the dominant attack vector against C/C++ programs. Control-Flow Integrity (CFI) solutions mitigate these attacks on the forward edge,i.e., indirect calls through function pointers and virtual calls. Protecting the backward edge is left to stack canaries, which are easily bypassed through information leaks. Shadow Stacks are a fully precise mechanism for protecting backwards edges, and should be deployed with CFI mitigations. We present a comprehensive analysis of all possible shadow stack mechanisms along three axes: performance, compatibility, and security. For performance comparisons we use SPEC CPU2006, while security and compatibility are qualitatively analyzed. Based on our study, we renew calls for a shadow stack design that leverages a dedicated register, resulting in low performance overhead, and minimal memory overhead, but sacrifices compatibility. We present case studies of our implementation of such a design, Shadesmar, on Phoronix and Apache to demonstrate the feasibility of dedicating a general purpose register to a security monitor on modern architectures, and the deployability of Shadesmar. Our comprehensive analysis, including detailed case studies for our novel design, allows compiler designers and practitioners to select the correct shadow stack design for different usage scenarios.Comment: To Appear in IEEE Security and Privacy 201

Static Binary Rewriting for ROP Gadget Removal

Return-Oriented Programming (ROP) is an exploitation technique that is commonly used by malicious users. It works by leveraging return statements in binaries to gain control over the execution of programs. Some mitigations for ROP include changing the binary during compilation time, rewriting the binary after compilation, and adding runtime checks to the binary. The focus of this study was rewriting the binary after compilation. Rewriting during compilation time requires end users to have access to source code, which, in most cases, they will not. Adding runtime checks adds additional overhead to the target binary. The areas this study aimed to improve in the binary rewriting space were twofold. The first was improving static binary rewriting. This was done by attempting to see if the amount of information needed to correctly rewrite a binary could be reduced compared to other tools. The second area was attempting to use static binary rewriting to reduce the number of potential ROP gadgets in a binary. The ROP gadgets that were targeted were those created by splitting an instruction that contains a return in them to create new ROP gadgets. This was chosen because most current tools focused on the safety of standard returns from function ends. To determine if static binary rewriting could be used to reduce the amount of ROP gadgets created from mid-instruction ROP gadgets, a design science approach was taken. There were two artifacts that were created through two design cycles. The first artifact aimed to create a static binary rewriter that collected minimal amount of information from binaries. The second artifact built upon the first artifact and attempted to use it to remove instructions that contained a mid-instruction return. After the removal of the mid-instruction return, the second artifact inserted instructions that allowed for the same functionality of the binary, but without the return byte

Using Execution Transactions To Recover From Buffer Overflow Attacks

We examine the problem of containing buffer overflow attacks in a safe and efficient manner. Briefly, we automatically augment source code to dynamically catch stack and heap-based buffer overflow and underflow attacks, and recover from them by allowing the program to continue execution. Our hypothesis is that we can treat each code function as a transaction that can be aborted when an attack is detected, without affecting the application's ability to correctly execute. Our approach allows us to selectively enable or disable components of this defensive mechanism in response to external events, allowing for a direct tradeoff between security and performance. We combine our defensive mechanism with a honeypot-like configuration to detect previously unknown attacks and automatically adapt an application's defensive posture at a negligible performance cost, as well as help determine a worm's signature. The main benefits of our scheme are its low impact on application performance, its ability to respond to attacks without human intervention, its capacity to handle previously unknown vulnerabilities, and the preservation of service availability. We implemented a stand-alone tool, DYBOC, which we use to instrument a number of vulnerable applications. Our performance benchmarks indicate a slow-down of 20% for Apache in full-protection mode, and 1.2% with partial protection. We validate our transactional hypothesis via two experiments: first, by applying our scheme to 17 vulnerable applications, successfully fixing 14 of them; second, by examining the behavior of Apache when each of 154 potentially vulnerable routines are made to fail, resulting in correct behavior in 139 of cases