Results 1 - 10
of
18
Out of control: Overcoming control-flow integrity
- In IEEE Symposium on Security and Privacy
, 2014
"... Abstract—As existing defenses like ALSR, DEP, and stack cookies are not sufficient to stop determined attackers from exploiting our software, interest in Control Flow Integrity (CFI) is growing. In its ideal form, CFI prevents any flow of control that was not intended by the original program, effect ..."
Abstract
-
Cited by 37 (4 self)
- Add to MetaCart
Abstract—As existing defenses like ALSR, DEP, and stack cookies are not sufficient to stop determined attackers from exploiting our software, interest in Control Flow Integrity (CFI) is growing. In its ideal form, CFI prevents any flow of control that was not intended by the original program, effectively putting a stop to exploitation based on return oriented programming (and many other attacks besides). Two main problems have prevented CFI from being deployed in practice. First, many CFI implementations require source code or debug information that is typically not available for commercial software. Second, in its ideal form, the technique is very expensive. It is for this reason that current research efforts focus on making CFI fast and practical. Specifically, much of the work on practical CFI is applicable to binaries, and improves performance by enforcing a looser notion of control flow integrity. In this paper, we examine the security implications of such looser notions of CFI: are they still able to prevent code reuse attacks, and if not, how hard is it to bypass its protection? Specifically, we show that with two new types of gadgets, return oriented programming is still possible. We assess the availability of our gadget sets, and demonstrate the practicality of these results with a practical exploit against Internet Explorer that bypasses modern CFI implementations. Keywords—Control-flow integrity evaluation, code-reuse attack I.
SoK: Automated Software Diversity
"... Abstract—The idea of automatic software diversity is at least two decades old. The deficiencies of currently deployed defenses and the transition to online software distribution (the “App store ” model) for traditional and mobile computers has revived the interest in automatic software diversity. Co ..."
Abstract
-
Cited by 18 (3 self)
- Add to MetaCart
(Show Context)
Abstract—The idea of automatic software diversity is at least two decades old. The deficiencies of currently deployed defenses and the transition to online software distribution (the “App store ” model) for traditional and mobile computers has revived the interest in automatic software diversity. Consequently, the literature on diversity grew by more than two dozen papers since 2008. Diversity offers several unique properties. Unlike other de-fenses, it introduces uncertainty in the target. Precise knowledge of the target software provides the underpinning for a wide range of attacks. This makes diversity a broad rather than narrowly focused defense mechanism. Second, diversity offers probabilistic protection similar to cryptography—attacks may succeed by chance so implementations must offer high entropy. Finally, the design space of diversifying program transformations is large. As a result, researchers have proposed multiple approaches to software diversity that vary with respect to threat models, security, performance, and practicality. In this paper, we systematically study the state-of-the-art in software diversity and highlight fundamental trade-offs between fully automated approaches. We also point to open areas and unresolved challenges. These include “hybrid solutions”, error reporting, patching, and implementation disclosure attacks on diversified software. I.
Scalable variable and data type detection in a binary rewriter
- In To Appear in PLDI
, 2013
"... We present scalable static analyses to recover variables, data types, and function prototypes from stripped x86 executables (without symbol or debug information) and obtain a functional intermedi-ate representation (IR) for analysis and rewriting purposes. Our techniques on average run 352X faster t ..."
Abstract
-
Cited by 12 (4 self)
- Add to MetaCart
(Show Context)
We present scalable static analyses to recover variables, data types, and function prototypes from stripped x86 executables (without symbol or debug information) and obtain a functional intermedi-ate representation (IR) for analysis and rewriting purposes. Our techniques on average run 352X faster than current techniques and still have the same precision. This enables analyzing executables as large as millions of instructions in minutes which is not possible us-ing existing techniques. Our techniques can recover variables allo-cated to the floating point stack unlike current techniques. We have integrated our techniques to obtain a compiler level IR that works correctly if recompiled and produces the same output as the input executable. We demonstrate scalability, precision and correctness of our proposed techniques by evaluating them on the complete SPEC2006 benchmarks suite. Categories and Subject Descriptors D.2.7: Software Engineer-
StackArmor: Comprehensive Protection from Stack-based Memory Error Vulnerabilities for Binaries
"... Abstract—StackArmor is a comprehensive protection tech-nique for stack-based memory error vulnerabilities in binaries. It relies on binary analysis and rewriting strategies to drastically re-duce the uniquely high spatial and temporal memory predictabil-ity of traditional call stack organizations. U ..."
Abstract
-
Cited by 4 (1 self)
- Add to MetaCart
(Show Context)
Abstract—StackArmor is a comprehensive protection tech-nique for stack-based memory error vulnerabilities in binaries. It relies on binary analysis and rewriting strategies to drastically re-duce the uniquely high spatial and temporal memory predictabil-ity of traditional call stack organizations. Unlike prior solutions, StackArmor can protect against arbitrary stack-based attacks, requires no access to the source code, and offers a policy-driven protection strategy that allows end users to tune the security-performance tradeoff according to their needs. We present an implementation of StackArmor for x86 64 Linux and provide a detailed experimental analysis of our prototype on popular server programs and standard benchmarks (SPEC CPU2006). Our results demonstrate that StackArmor offers better security than prior binary- and source-level approaches, at the cost of only mod-est performance and memory overhead even with full protection. I.
Reassembleable Disassembling
"... Reverse engineering has many important applications in computer security, one of which is retrofitting software for safety and security hardening when source code is not available. By surveying available commercial and aca-demic reverse engineering tools, we surprisingly found that no existing tool ..."
Abstract
-
Cited by 2 (2 self)
- Add to MetaCart
(Show Context)
Reverse engineering has many important applications in computer security, one of which is retrofitting software for safety and security hardening when source code is not available. By surveying available commercial and aca-demic reverse engineering tools, we surprisingly found that no existing tool is able to disassemble executable binaries into assembly code that can be correctly assem-bled back in a fully automated manner, even for simple programs. Actually in many cases, the resulted disas-sembled code is far from a state that an assembler ac-cepts, which is hard to fix even by manual effort. This has become a severe obstacle. People have tried to over-come it by patching or duplicating new code sections for retrofitting of executables, which is not only inefficient but also cumbersome and restrictive on what retrofitting techniques can be applied to. In this paper, we present UROBOROS, a tool that can disassemble executables to the extent that the gener-ated code can be assembled back to working binaries without manual effort. By empirically studying 244 binaries, we summarize a set of rules that can make the disassembled code relocatable, which is the key to reassembleable disassembling. With UROBOROS, the disassembly-reassembly process can be repeated thou-sands of times. We have implemented a prototype of UROBOROS and tested over the whole set of GNU Core-utils, SPEC2006, and a set of other real-world applica-tion and server programs. The experiment results show that our tool is effective with a very modest cost. 1
Static Binary Rewriting without Supplemental Information Overcoming the Tradeoff between Coverage and Correctness
"... Abstract—Binary rewriting is the process of transforming executables by maintaining the original binary’s functionality, while improving it in one or more metrics, such as energy use, memory use, security, or reliability. Although several technologies for rewriting binaries exist, static rewriting a ..."
Abstract
-
Cited by 2 (1 self)
- Add to MetaCart
(Show Context)
Abstract—Binary rewriting is the process of transforming executables by maintaining the original binary’s functionality, while improving it in one or more metrics, such as energy use, memory use, security, or reliability. Although several technologies for rewriting binaries exist, static rewriting allows for arbitrarily complex transformations to be performed. Other technologies, such as dynamic or minimally-invasive rewriting, are limited in their transformation ability. We have designed the first static binary rewriter that guar-antees 100 % code coverage without the need for relocation or symbolic information. A key challenge in static rewriting is content classification (i.e. deciding what portion of the code segment is code versus data). Our contributions are (i) handling portions of the code segment with uncertain classification by using speculative disassembly in case it was code, and retaining the original binary in case it was data; (ii) drastically limiting the number of possible speculative sequences using a new technique called binary characterization; and (iii) avoiding the need for relocation or symbolic information by using call translation at usage points of code pointers (i.e. indirect control transfers), rather than changing addresses at address creation points. Extensive evaluation using stripped binaries for the entire SPEC 2006 benchmark suite (with over 1.9 million lines of code) demonstrates the robustness of the scheme. I.
Helium: Lifting High-Performance Stencil Kernels from Stripped x86 Binaries to Halide DSL Code
"... Highly optimized programs are prone to bit rot, where performance quickly becomes suboptimal in the face of new hardware and com-piler techniques. In this paper we show how to automatically lift performance-critical stencil kernels from a stripped x86 binary and generate the corresponding code in th ..."
Abstract
- Add to MetaCart
(Show Context)
Highly optimized programs are prone to bit rot, where performance quickly becomes suboptimal in the face of new hardware and com-piler techniques. In this paper we show how to automatically lift performance-critical stencil kernels from a stripped x86 binary and generate the corresponding code in the high-level domain-specific language Halide. Using Halide’s state-of-the-art optimizations tar-geting current hardware, we show that new optimized versions of these kernels can replace the originals to rejuvenate the application for newer hardware. The original optimized code for kernels in stripped binaries is nearly impossible to analyze statically. Instead, we rely on dynamic traces to regenerate the kernels. We perform buffer structure recon-struction to identify input, intermediate and output buffer shapes. We abstract from a forest of concrete dependency trees which contain
∗School of Computer and Communication Sciences
"... Abstract—Security vulnerabilities plague modern systems be-cause writing secure systems code is hard. Promising approaches can retrofit security automatically via runtime checks that implement the desired security policy; these checks guard critical operations, like memory accesses. Alas, the induce ..."
Abstract
- Add to MetaCart
(Show Context)
Abstract—Security vulnerabilities plague modern systems be-cause writing secure systems code is hard. Promising approaches can retrofit security automatically via runtime checks that implement the desired security policy; these checks guard critical operations, like memory accesses. Alas, the induced slowdown usually exceeds by a wide margin what system users are willing to tolerate in production, so these tools are hardly ever used. As a result, the insecurity of real-world systems persists. We present an approach in which developers/operators can specify what level of overhead they find acceptable for a given workload (e.g., 5%); our proposed tool ASAP then automatically instruments the program to maximize its security while staying within the specified “overhead budget. ” Two insights make this approach effective: most overhead in existing tools is due to only a few “hot ” checks, whereas the checks most useful to security are typically “cold ” and cheap. We evaluate ASAP on programs from the Phoronix and SPEC benchmark suites. It can precisely select the best points in the security-performance spectrum. Moreover, we analyzed existing bugs and security vulnerabilities in RIPE, OpenSSL, and the Python interpreter, and found that the protection level offered by the ASAP approach is sufficient to protect against all of them. I.
1Large-scale Automated Software Diversity—Program Evolution Redux
"... Abstract—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 ..."
Abstract
- Add to MetaCart
(Show Context)
Abstract—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. Index Terms—Biologically-inspired defenses, artificial software diversity, return-oriented programming, jump-oriented program-ming, code reuse attacks
AInstruction Cache Locking for Improving Embedded Systems Performance
"... Cache memories in embedded systems play an important role in reducing the execution time of the applica-tions. Various kinds of extensions have been added to cache hardware to enable software involvement in re-placement decisions, thus improving the run-time over a purely hardware-managed cache. Nov ..."
Abstract
- Add to MetaCart
(Show Context)
Cache memories in embedded systems play an important role in reducing the execution time of the applica-tions. Various kinds of extensions have been added to cache hardware to enable software involvement in re-placement decisions, thus improving the run-time over a purely hardware-managed cache. Novel embedded systems, such as Intel’s XScale and ARM Cortex processors provide the facility of locking one or more lines in cache- this feature is called cache locking. This paper presents a method in for instruction-cache locking that is able to reduce the average-case runtime of a program. We demonstrate that the optimal solution for instruction cache locking can be obtained in polynomial time. However, a fundamental lack of correlation between cache hardware and software program points renders such optimal solutions impractical. Instead, we propose two practical heuristics based approaches to achieve cache locking. First, we present a static mechanism for locking the cache where the locked contents of the cache are kept fixed over the execution of the program. Next, we present a dynamic mechanism which accounts for changing program requirements at runtime. We devise a cost-benefit model to discover the memory addresses which should be locked in the cache. We implement our scheme inside a binary rewriter, thus widening the applicability of our scheme to binaries compiled using any compiler. Results obtained on a suite of MiBench benchmarks show that our static mechanism results in 20% improvement in the instruction-cache miss rate on average and upto 18 % improvement in the execution time on average for applications having instruction accesses as a bottleneck, compared to no cache locking. The dynamic mechanism improves the cache miss rate by 35 % on average and execution time by 32 % on instruction-cache constrained applications.
