Checking for Application Vulnerabilities Using Fault Injection

This thesis introduces a fault injector, called "Pulad", specifically developed for finding application vulnerabilities. Most previous approaches for finding application vulnerabilities involved static verification methods. With these methods, the source code is not executed. Since vulnerabilities can only be revealed when they are exploited, the use of a dynamic verification method, executing the source code, seems needed. The main two dynamic verification areas are software testing and fault injection. This thesis focuses on fault injection. Pulad, the fault injector described in this thesis consists of two main parts called the "collector" and the "fault injector". The goal of the collector is to record all the environment-application interactions when the application is running. These interactions focusing on the environment files are then analyzed and the following fields are uploaded into a database including the file name, file extension, file size, file directory, number of times the file was used, file permission (includes symbolic link and ownership) and number of times an error occurred. The fault injector allows to inject faults either using a graphical user interface (GUI) or directly through a text file. The faults in the files include the file name, the directory name, the execution path, the library path, the file existence, the file ownership, the file permission, etc. For each of the faults, the specific type of fault needs to be indicated. Moreover, the interaction points where the faults should be injected are also provided by the user

On the Use of Fault Injection to Discover Security Vulnerabilities in Applications

The advent of the Internet has enabled developers to write and share software components with each other more easily. Developers have become increasingly reliant on code other than their own for application development; code that is often not well tested, and lacking any kind of security review, thus exposing its consumers to security vulnerabilities. The goal of this thesis is to adapt existing techniques, and discover new approaches that can be used to discover security vulnerabilities in applications. We use fault injection in each of our techniques and define a set of criteria to evaluate these approaches. The hierarchy of approaches, starting from a black box and ending in a full white box approach, allows a security reviewer to choose a technique depending on the amount of information available about the application under review, time constraints, and extent of security analysis and confidence desired in the program

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

Repeating the past experimental and empirical methods in system and software security

I propose a new method of analyzing intrusions: instead of analyzing evidence and deducing what must have happened, I find the intrusion-causing circumstances by a series of automatic experiments. I first capture process';s system calls, and when an intrusion has been detected, I use these system calls to replay some of the captured processes in order to find the intrusion-causing processes—the cause-effect chain that led to the intrusion. I extend this approach to find also the inputs to those processes that cause the intrusion—the attack signature. Intrusion analysis is a minimization problem—how to find a minimal set of circumstances that makes the intrusion happen. I develop several efficient minimization algorithms and show their theoretical properties, such as worst-case running times, as well as empirical evidence for a comparison of average running times. Our evaluations show that the approach is correct and practical; it finds the 3 processes out of 32 that are responsible for a proof-of-concept attack in about 5 minutes, and it finds the 72 out of 168 processes in a large, complicated, and difficult to detect multi-stage attack involving Apache and suidperl in about 2.5 hours. I also extract attack signatures in proof-of-concept attacks in reasonable time. I have also considered the problem of predicting before deployment which components in a software system are most likely to contain vulnerabilities. I present empirical evidence that vulnerabilities are connected to a component';s imports. In a case study on Mozilla, I correctly predicted one half of all vulnerable components, while more than two thirds of our predictions were correct.Ich stelle eine neue Methode der Einbruchsanalyse vor: Anstatt Spuren zu analysieren und daraus den Ereignisverlauf zu erschließen, finde ich die einbruchsverursachenden Umstände durch automatische Experimente. Zunächst zeichne ich die Systemaufrufe von Prozessen auf. Nachdem ein Einbruch entdeckt wird, benutze ich diese Systemaufrufe, um Prozesse teilweise wieder einzuspielen, so dass ich herausfinden kann, welche Prozesse den Einbruch verursacht haben —die Ursache-Wirkungs-Kette. Ich erweitere diesen Ansatz, um auch die einbruchsverursachenden Eingaben dieser Prozesse zu finden — die Angriffs-Signatur. Einbruchsanalyse ist ein Minimierungsproblem — wie findet man eine minimale Menge von Umständen, die den Einbruch passieren lassen? Ich entwickle einige effiziente Algorithmen und gebe sowohl theroretische Eigenschaften an, wie z.B. die Laufzeit im ungünstigsten Fall, als auch empirische Ergebnisse, die das mittlere Laufzeitverhalen beleuchten. Meine Evaluierung zeigt, dass unser Ansatz korrekt und praktikabel ist; er findet die 3 aus 32 Prozessen, die für einen konstruierten Angriff verantwortlich sind, in etwa 5 Minuten, und er findet die 72 von 168 Prozessen, die für einen echten, komplizierten, mehrstufigen und schwer zu analysierenden Angriff auf Apache und suidperl verantwortlich sind, in 2,5 Stunden. Ich kann ebenfalls Angriffs-Signaturen eines konstruierten Angriffs in vernünftiger Zeit erstellen. Ich habe mich auch mit dem Problem beschäftigt, vor der Auslieferung von Software diejenigen Komponenten vorherzusagen, die besonders anfällig für Schwachstellen sind. Ich bringe empirische Anhaltspunkte, dass Schwachstellen mit Importen korrelieren. In einer Fallstudie über Mozilla konnte ich die Hälfte aller fehlerhaften Komponenten korrekt vorhersagen, wobei etwa zwei Drittel aller Vorhersagen richtig war

Higher Order Mutation Testing

Mutation testing is a fault-based software testing technique that has been studied widely for over three decades. To date, work in this field has focused largely on first order mutants because it is believed that higher order mutation testing is too computationally expensive to be practical. This thesis argues that some higher order mutants are potentially better able to simulate real world faults and to reveal insights into programming bugs than the restricted class of first order mutants. This thesis proposes a higher order mutation testing paradigm which combines valuable higher order mutants and non-trivial first order mutants together for mutation testing. To overcome the exponential increase in the number of higher order mutants a search process that seeks fit mutants (both first and higher order) from the space of all possible mutants is proposed. A fault-based higher order mutant classification scheme is introduced. Based on different types of fault interactions, this approach classifies higher order mutants into four categories: expected, worsening, fault masking and fault shifting. A search-based approach is then proposed for locating subsuming and strongly subsuming higher order mutants. These mutants are a subset of fault mask and fault shift classes of higher order mutants that are more difficult to kill than their constituent first order mutants. Finally, a hybrid test data generation approach is introduced, which combines the dynamic symbolic execution and search based software testing approaches to generate strongly adequate test data to kill first and higher order mutants