Detecting Exploit Primitives Automatically for Heap Vulnerabilities on Binary Programs

Automated Exploit Generation (AEG) is a well-known difficult task, especially for heap vulnerabilities. Previous works first detected heap vulnerabilities and then searched for exploitable states by using symbolic execution and fuzzing techniques on binary programs. However, it is not always easy to discovery bugs using fuzzing or symbolic technologies and solvable for internal overflow of heap objects. In this paper, we present a solution DEPA to detect exploit primitives based on primitive-crucial-behavior model for heap vulnerabilities. The core of DEPA contains two novel techniques, 1) primitive-crucial-behavior identification through pointer dependence analysis, and 2) exploit primitive determination method which includes triggering both vulnerabilities and exploit primitives. We evaluate DEPA on eleven real-world CTF(capture the flag) programs with heap vulnerabilities and DEPA can discovery arbitrary write and arbitrary jump exploit primitives for ten programs except for program multi-heap. Results showed that primitive-crucial-behavior identification and determining exploit primitives are accurate and effective by using our approach. In addition, DEPA is superior to the state-of-the-art tools in determining exploit primitives for the heap object internal overflowComment: 11 pages 9 figure

Automatic Software Repair: a Bibliography

This article presents a survey on automatic software repair. Automatic software repair consists of automatically finding a solution to software bugs without human intervention. This article considers all kinds of repairs. First, it discusses behavioral repair where test suites, contracts, models, and crashing inputs are taken as oracle. Second, it discusses state repair, also known as runtime repair or runtime recovery, with techniques such as checkpoint and restart, reconfiguration, and invariant restoration. The uniqueness of this article is that it spans the research communities that contribute to this body of knowledge: software engineering, dependability, operating systems, programming languages, and security. It provides a novel and structured overview of the diversity of bug oracles and repair operators used in the literature

Comparing Fuzzers on a Level Playing Field with FuzzBench

Fuzzing is a testing approach commonly used in industry to discover bugs in a given software under test (SUT). It consists of running a SUT iteratively with randomly generated (or mutated) inputs, in order to find as many as possible inputs that make the SUT crash. Many fuzzers have been proposed to date, however no consensus has been reached on how to properly evaluate and compare fuzzers. In this work we evaluate and compare nine prominent fuzzers by carrying out a thorough empirical study based on an open-source framework developed by Google, namely FuzzBench, and a manually curated benchmark suite of 12 real-world software systems. The results show that honggfuzz and AFL++ are, in that order, the best choices in terms of general purpose fuzzing effectiveness. The results also show that none of the fuzzers outperforms the others in terms of efficiency across all considered metrics, that no particular bug affinity is found for any fuzzer, and that the correlation found between coverage and number of bugs depends more on the SUT rather than on the fuzzer used

A tale of two worlds:assessing the vulnerability of enclave shielding runtimes

status: publishe

Program crash analysis : evaluation and application of current methods

After decades of development in computer science, memory corruption bugs still pose a threat to the reliability of software. Automatic crash reporting and fuzz testing are effective ways of gathering information about program bugs. However, these methods can potentially produce thousands of crash dumps, motivating the need for grouping and prioritizing crashes. In addition, the time necessary to analyze the root cause of crashes and to implement a reliable fix in source code should be reduced. This thesis demonstrates how fuzzing can produce a large set of different crashes in a real program. An empirical study explores methods for analyzing these crashes. Automatic bucketing and classification is performed. Call stack based grouping algorithms are compared, and modifications are suggested. Taint analysis is demonstrated as a complementary method to automatic classification based on crash dumps. Dynamic analysis using execution traces is demonstrated as a method for root cause analysis. The empirical study suggests some general results regarding program crash analysis. Crashes should be grouped based on related crash locations and identified similarities in call stacks. A distance algorithm can be used for call stack based grouping and to identify relations between groups. It is suggested that a weighted priority model should be used for prioritizing crashes based on a strategic policy. Some possible metrics are frequency, reliability, severity estimate and relations to already fixed bugs. In order to properly fix a memory corruption bug, the underlying cause should be understood at machine-level. Execution traces with logged operands, differential debugging, Crash Graphs and input analysis might help developers analyze different aspects of memory corruption bugs

Securing software : an evaluation of static source code analyzers

Thesis (M. Eng.)--Massachusetts Institute of Technology, Dept. of Electrical Engineering and Computer Science, 2003.Includes bibliographical references (leaves 100-105).This thesis evaluated five static analysis tools--Polyspace C Verifier, ARCHER, BOON, Splint, and UNO--using 14 code examples that illustrated actual buffer overflow vulnerabilities found in various versions of Sendmail, BIND, and WU-FTPD. Each code example included a "BAD" case with one or more buffer overflow vulnerabilities and a "PATCHED" case without buffer overflows. The buffer overflows varied and included stack, heap, bss and data buffers; access above and below buffer bounds; access using pointers, indices, and functions; and scope differences between buffer creation and use. Detection rates for the "BAD" examples were low except for Splint and PolySpace C Verifier, which had average detection rates of 57% and 87% respectively. However, average false alarm rates, as measured using the "PATCHED" programs, were high for these two systems. The frequency of false alarms per lines of code was high for both of these tools; Splint gave on average one false alarm per 50 lines of code, and PolySpace gave on average one false alarm per 10 lines of code. This result shows that current approaches can detect buffer overflows, but that false alarm rates need to be lowered substantially.by Misha Zitser.M.Eng

Leveraging Static Analysis for Bug Repair

We propose a method combining machine learning with a static analysis tool (i.e. Infer) to automatically repair source code. Machine Learning methods perform well for producing idiomatic source code. However, their output is sometimes difficult to trust as language models can output incorrect code with high confidence. Static analysis tools are trustable, but also less flexible and produce non-idiomatic code. In this paper, we propose to fix resource leak bugs in IR space, and to use a sequence-to-sequence model to propose fix in source code space. We also study several decoding strategies, and use Infer to filter the output of the model. On a dataset of CodeNet submissions with potential resource leak bugs, our method is able to find a function with the same semantics that does not raise a warning with around 97% precision and 66% recall.Comment: 13 pages. DL4C 202