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

Survey of Protections from Buffer-Overflow Attacks

Buffer-overflow attacks began two decades ago and persist today. Over that time, many solutions to provide protection from buffer-overflow attacks have been proposed by a number of researchers. They all aim to either prevent or protect against buffer-overflow attacks. As defenses improved, attacks adapted and became more sophisticated. Given the maturity of field and the fact that some solutions now exist that can prevent most buffer-overflow attacks, we believe it is time to survey these schemes and examine their critical issues. As part of this survey, we have grouped approaches into three board categories to provide a basis for understanding buffer-overflow protection schemes

Dynamic Application Level Security Sensors

The battle for cyber supremacy is a cat and mouse game: evolving threats from internal and external sources make it difficult to protect critical systems. With the diverse and high risk nature of these threats, there is a need for robust techniques that can quickly adapt and address this evolution. Existing tools such as Splunk, Snort, and Bro help IT administrators defend their networks by actively parsing through network traffic or system log data. These tools have been thoroughly developed and have proven to be a formidable defense against many cyberattacks. However, they are vulnerable to zero-day attacks, slow attacks, and attacks that originate from within. Should an attacker or some form of malware make it through these barriers and onto a system, the next layer of defense lies on the host. Host level defenses include system integrity verifiers, virus scanners, and event log parsers. Many of these tools work by seeking specific attack signatures or looking for anomalous events. The defenses at the network and host level are similar in nature. First, sensors collect data from the security domain. Second, the data is processed, and third, a response is crafted based on the processing. The application level security domain lacks this three step process. Application level defenses focus on secure coding practices and vulnerability patching, which is ineffective. The work presented in this thesis uses a technique that is commonly employed by malware, dynamic-link library (DLL) injection, to develop dynamic application level security sensors that can extract fine-grain data at runtime. This data can then be processed to provide stronger application level defense by shrinking the vulnerability window. Chapters 5 and 6 give proof of concept sensors and describe the process of developing the sensors in detail

Defense against buffer overflow attack by software design diversity

A buffer overflow occurs during program execution when a fixed-size buffer has had too much data copied into it. This causes the data to overwrite into adjacent memory locations, and, depending on what is stored there, the behavior of the program itself might be affected; Attackers can select the value to place in the location in order to redirect execution to the location of their choice. If it contains machine code, the attacker causes the program to execute any arbitrary set of instructions---essentially taking control of the process. Successfully modifying the function return address allows the attacker to execute instructions with the same privileges as that of the attacked program; In this thesis, we propose to design software with multiple variants of the modules/functions. It can provide strong defense against the buffer overflow attack. A way can be provided to select a particular variant (implementation) of the module randomly when software is executed. This proves to be useful when an attacker designs the attack for a particular variant/implementation which may not be chosen in the random selection process during execution. It would be much difficult for the attacker to design an attack because of the different memory (stack-frame) layout the software could have every time it is executed

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

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

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

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

On The General Applicability of Instruction-Set Randomization

We describe Instruction-Set Randomization (ISR), a general approach for safeguarding systems against any type of code-injection attack. We apply Kerckhoffs' principle to create OS process-specific randomized instruction sets (e.g., machine instructions) of the system executing potentially vulnerable software. An attacker who does not know the key to the randomization algorithm will inject code that is invalid for that (randomized) environment, causing a runtime exception. Our approach is applicable to machine-language programs and scripting and interpreted languages. We discuss three approaches (protection for Intel x86 executables, Perl scripts, and SQL queries), one from each of the above categories. Our goal is to demonstrate the generality and applicability of ISR as a protection mechanism. Our emulator-based prototype demonstrates the feasibility ISR for x86 executables and should be directly usable on a suitably modified processor. We demonstrate how to mitigate the significant performance impact of emulation-based ISR by using several heuristics to limit the scope of randomized (and interpreted) execution to sections of code that may be more susceptible to exploitation. The SQL prototype consists of an SQL query-randomizing proxy that protects against SQL injection attacks with no changes to database servers, minor changes to CGI scripts, and with negligible performance overhead. Similarly, the performance penalty of a randomized Perl interpreter is minimal. Where the performance impact of our proposed approach is acceptable (i.e., in an already-emulated environment, in the presence of programmable or specialized hardware, or in interpreted languages), it can serve as a broad protection mechanism and complement other security mechanisms