gannimo

Modern grey-box fuzzers are the most effective way of finding bugs in complex code bases, and instrumentation is fundamental to their effectiveness. Existing instrumentation techniques either require source code (e.g., afl-gcc, ASan) or have a high runtime performance cost (roughly 10x slowdown for e.g., afl-qemu). We introduce Retrowrite, a binary rewriting framework that enables direct static instrumentation for both user-mode binaries and Linux kernel modules. Unlike dynamic translation and trampolining, rewriting code with Retrowrite does not introduce a performance penalty. We show the effectiveness of Retrowrite for fuzzing by implementing binary-only coverage tracking and ASan instrumentation passes. Our binary instrumentation achieves performance similar to compiler-based instrumentation.

Fuzzing is the method of choice for finding security vulnerabilities in software due to its simplicity and scalability, but it struggles to find deep paths in complex programs, and only detects bugs when the target crashes. Instrumentation greatly helps with both issues by (i) collecting coverage feedback, which drives fuzzing deeper into the target, and (ii) crashing the target immediately when bugs are detected, which lets the fuzzer detect more bugs and produce more precise reports. One of the main difficulties of fuzzing closed-source software is that instrumenting compiled binaries comes at a huge performance cost. For example, simple coverage instrumentation through dynamic binary translation already incurs between 10x and 100x slowdown, which prevents the fuzzer from finding interesting inputs and bugs. In this talk we show how we used static binary rewriting for instrumentation: our approach has low overhead (comparable to compile-time instrumentation) but works on binaries. There are three main techniques to rewrite binaries: recompilation, trampoline insertion and reassembleable assembly. Recompilation is the most powerful but it requires expensive analysis and type recovery, which is an open/unsolved problem. Trampolines add a level of indirection and increase the size of the code, both of which have a negative impact on performance. Reassembleable assembly, the technique that we use, suffers from neither problem. In order to produce reassembleable assembly, we first disassemble the binary and then symbolize all code and data references (replacing offsets and references with references to unique labels). The output can then be fed to a standard assembler to produce a binary. Because symbolization replaces all references with labels, we can now insert instrumentation in the code and the assembler will fix the references for us when reassembling the binary. Symbolization is possible because references to code and global data always use RIP-relative addressing in the class of binaries that we support (position-independent x86_64 binaries). This makes it easy to distinguish between references and integer constants in the disassembly. We present Retrowrite, a framework for static binary rewriting that can add efficient instrumentation to compiled binaries and scales to real-world code. Retrowrite symbolizes x86_64 position-independent Linux binaries and emits reassembleable assembly, which can be fed to instrumentation passes. We implement a binary version of Address Sanitizer (ASan) that integrates with the source-based version. Retrowrite’s output can also be fed directly to AFL’s afl-gcc to produce a binary with coverage-tracking instrumentation. RetroWrite is openly available for everyone to use and we will demo it during the presentation. We also present kRetrowrite, which uses the same approach to instrument binary kernel modules for Linux. While many devices can be used with open-source drivers, some still require binary drivers. Device drivers are an inviting target for attackers because they run at the highest privilege level, and a buggy driver could result in full system compromise. kRetrowrite can instrument binary Linux modules to add kCov-based coverage tracking and KASan instrumentation.

Other people: Nspace

Type confusion, often combined with use-after-free, is the main attack vector to compromise modern C++ software like browsers or virtual machines. Typecasting is a core principle that enables modularity in C++. For performance, most typecasts are only checked statically, i.e., the check only tests if a cast is allowed for the given type hierarchy, ignoring the actual runtime type of the object. Using an object of an incompatible base type instead of a derived type results in type confusion. Attackers have been abusing such type confusion issues to compromise popular software products including Adobe Flash, PHP, Google Chrome, or Firefox, raising critical security concerns. We discuss the details of this vulnerability type and how such vulnerabilities relate to memory corruption. Based on an LLVM-based sanitizer that we developed, we will show how to discover such vulnerabilities in large software through fuzzing and how to protect yourself against this class of bugs.

C++ is popular in large software projects that require both the modularity of object-oriented programming and the high efficiency offered by low-level access to memory and system intrinsics. Examples of such software are Google Chrome, Microsoft Windows, Mozilla Firefox, or Oracle's JVM. Unfortunately, C++ enforces neither type nor memory safety. This lack of safety leads to type confusion vulnerabilities that can be abused to attack programs. Type confusion arises when the program interprets an object of one type as an object of a different type due to unsafe typecasting, leading to reinterpretation of memory areas in different contexts. For instance, a program may cast an instance of a parent class to a descendant class, even though this is not safe if the parent class lacks some of the fields or virtual functions of the descendant class. When the program subsequently uses these fields or functions, it may use data, say, as a regular field in one context and as a virtual function table (vtable) pointer in another. Exploitable type confusion bugs have been found in a wide range of software products, such as Adobe Flash (CVE-2015-3077), Microsoft Internet Explorer (CVE-2015-6184), PHP (CVE-2016-3185), and Google Chrome (CVE-2013-0912). According to Microsoft, type confusion is the 4th most common vulnerability type in their bug bounty program (after use-after-free, memory corruption, and heap out-of-bounds read) with the majority of type confusion bugs also fitting into one of the earlier categories. We have developed an extension to the Clang/LLVM compiler that detects type-confusion bugs with low overhead and high coverage. Our prototype consists of two parts: an object tracing facility and typecasting verification. Such an enforcement mechanism is useful as a runtime monitor and online defense mechanism to protect applications against attacks. In a development setting, the mechanism can be combined with a fuzzing framework to detect type confusion before the underlying memory corruption triggers. In this talk we will first discuss how type safety protects against type confusion-based attacks. We will then introduce our prototype implementation and show how it actively defeats realistic attacks. Finally, we show how to leverage type safety in a fuzzing framework to find security vulnerabilities faster. We will release all components as open-source. We introduce the concept of a type sanitizer that checks all casts in an application (replacing static casts with fully explicit runtime checks) and show how we have developed a low-overhead framework for these checks. Building on this framework we argue that it can be used as a runtime monitor in an always on configuration to protect users against attacks and how developers, security researchers, and hackers can use it to find new vulnerabilities in real software. The expected audience includes people interested in system software, reverse engineering, fuzzing, type confusion-based attacks, and memory corruption-based attacks and their defense mechanisms. General programming and low-level knowledge is expected but the talk will be self contained and does not expect the audience to know the upcoming defense mechanisms or attacks.

Memory corruption is an ongoing problem and in past years we have both developed a set of defense mechanisms and novel attacks against those defense mechanisms. Novel defense mechanisms like Control-Flow Integrity (CFI) and Code-Pointer Integrity (CPI) promise to stop control-flow hijack attacks. We show that, while they make attacks harder, attacks often remain possible. Introducing novel attack mechanisms, like Control-Flow Bending (CFB), we discuss limitations of the current approaches. CFB is a generalization of data-only attacks that allows an attacker to execute code even if a defense mechanism significantly constrains execution.

Memory corruption plagues systems not just since Aleph1's article on stack smashing but since the dawn of computing. With the rise of defense techniques like stack cookies, ASLR, and DEP, attacks have grown more sophisticated but control-flow hijack attacks are still prevalent. Attackers can still launch code reuse attacks, often using some form of information disclosure. Stronger defense mechanisms have been proposed but none have seen wide deployment so far due to the time it takes to deploy a security mechanism, incompatibility with specific features, and most severely due to performance overhead. Control-Flow Integrity (CFI) and Code-Pointer Integrity (CPI) are two of the hottest upcoming defense mechanisms. After quickly introducing them, we will discuss differences and advantages/disadvantages of both approaches, especially the security benefits they give under novel memory corruption attacks. CFI guarantees that the dynamic control flow follows the statically determined control-flow of the compiled program but an attacker may reuse any of the statically valid transitions at any control flow transfer. CPI on the other hand is a dynamic property that enforces memory safety guarantees like bounds checks for code pointers by separating code pointers from regular data. Data-only attacks are possible both for CFI and CPI. Counterfeit Object-Oriented Programming (COOP) and Control-Flow Bending (CFB) are two novel attack mechanisms. COOP reuses complete functions as gadgets, mitigating several defense mechanisms and CFB bends the control flow along valid but unintended paths in the control flow graph of a program. We will discuss COOP and CFB attacks, focusing on mitigating strong novel defense mechanisms.

Other people: npc@berkeley.edu

Programs are full of bugs, leading to vulnerabilities. We'll discuss power and limitations of code-pointer integrity (CPI), a strong but practical security policy that enforces memory safety for all code pointers, protecting against any form of control-flow hijack attack (e. g., ROP or JOP).

Systems code is often written in low-level languages like C/C++, which offer many benefits but also delegate memory management to programmers. This invites memory safety bugs that attackers can exploit to divert control flow and compromise the system. Deployed defence mechanisms (e. g., ASLR, DEP) are incomplete, and stronger defence mechanisms (e. g., CFI) often have high overhead and limited guarantees (and are therefore not generally deployed). In this talk we discuss code-pointer integrity (CPI), a strong security policy that guarantees the integrity of all code pointers in a program (e.g., function pointers, saved return addresses) and thereby prevents all control-flow hijack attacks, including return-oriented programming and jump-oriented programming. We also introduce code-pointer separation (CPS), a relaxation of CPI with better performance properties. Both CPI and CPS offer substantially better security-to-overhead ratios than the state of the art, they are practical (we protect a complete FreeBSD system and over 100 packages like apache and postgresql), effective (prevent all attacks in the RIPE benchmark), and efficient, resulting in very low to negligible performance overhead. We will also discuss technical challenges in the CPI prototype implementation, practical challenges we faced when protecting a full FreeBSD distribution, and give more details on the scope of protection which will be interesting to hackers. The full prototype implementation is open-source, all changes to FreeBSD are open-source and we're working on integrating the patches into LLVM.

Memory corruption has been around forever but is still one of the most exploited problems on current systems. This talk looks at the past 30 years of memory corruption and systematizes the different existing exploit and defense techniques in a streamlined way. We evaluate (i) how the different attacks evolved, (ii) how researchers came up with defense mechanisms as an answer to new threats, and (iii) what we will have to expect in the future.

Memory corruption (e.g., buffer overflows, random writes, memory allocation bugs, or uncontrolled format strings) is one of the oldest and most exploited problems in computer science. These problems are here to stay as low-level languages like C or C++ continue to trade safety for potential performance. A small set of all proposed solutions (e.g., Address Space Layout Randomization, Data Execution Prevention, and stack canaries) is applied in practice but real exploits show that all currently deployed protections can be defeated. In this talk we systematize the existing knowledge about (i) attack vectors and specific techniques to exploit running software and (ii) defense mechanisms that protect against the attack vectors. Many of these techniques have been developed hand in hand. We take a methodological approach and cover the complete design space for control-flow based and data-flow based attacks for low-level languages. The problems of current protection mechanisms calls for novel approaches towards software protection that adhere to the three laws of software defenses: low overhead for high security guarantees, no changes to the original source code, and compatibility to existing libraries and binaries (including a partial migration strategy).

Symbolic Execution (SE) is a powerful way to analyze programs. Instead of using concrete data values SE uses symbolic values to evaluate a large set of parallel program paths at once. A drawback of many systems is that they need source code access and only scale to few lines of code. This talk explains how SE and binary analysis can be used to (i) reverse-engineer components of binary only applications and (ii) construct specific concrete input that triggers a given condition deep inside the application (think of defining an error condition and the SE engine constructs the input to the application that triggers the error).

Analysis and reverse engineering of binary programs is cumbersome. Consider the problem that we have a given interesting (error) condition inside the program that we want to trigger. How can we generate a specific input to the program that, during the execution of the program, will trigger the condition. In this talk we use a combination of binary analysis techniques that recover high-level control-flow and data-flow information from a binary-only application and Symbolic Execution (SE) to automate the analysis of such problems. Existing SE tools have often been used to achieve high coverage across all code paths in an application to find implementation bugs. We use SE for a different purpose; given a vulnerability condition hidden deep inside the application what is the input that triggers that condition. We tackle the given problem in three major steps: (i) gathering information about the binary, (ii) analyzing the information-flow and control-flow of the binary, and (iii) using symbolic execution to generate a specific input example that triggers the specified condition. During the information gathering process we define the interesting condition and use regular analysis techniques to set-up later stages. In the information-flow and control-flow analysis we use a given sample input to collect a complete execution trace of the application that is then parsed into a graph that dissects the computation of the application into individual components. The last steps uses fuzzBall, our open-source SE engine to compute specific vulnerability-triggering inputs for the identified components. To evaluate our technique we will show several examples using real programs, showing how we can use specific vulnerability conditions to automatically generate input that triggers this condition. In addition, we will show how our SE engine can be used for other interesting analysis on binary only applications. Our tools are available as open-source and we invite other hackers to join in on this project.