Towards Fuzzing Target Lines

Soundness and completeness are two primary concerns of a static analysis tool for finding defects in software. Exhaustive static analysis of the program through all paths is not always possible, especially for a large software causing incompleteness in the analysis. Also, exhaustive testing of the program to detect all bugs is not possible. In this work, we describe a technique which uses coverage data from testing to remove the tested paths and then statically analyzes the remaining code. This pruning of tested paths allows a static analyzer to perform a more thorough analysis of the reduced code, thereby improving its effectiveness. This work is a step towards integration of static analysis and testing frameworks. The proposed technique is applied with a few static analyzers publicly available. Our experience shows that the approach results in lesser false positives as well as detection of more serious errors which might have gone unnoticed otherwise.

Leveraging and acting on the results of static analysis is a well-known best practice. Static analysis also is an integral part of software quality assurance which is highlighted by the inclusion of static analysis results in software quality models like ColumbusQM and Quamoco. Although there are studies that explore if tools for static analysis are used and how they are configured, few publications explore the longitudinal effects of acting on static analysis results on software and on the evolution of software. Especially effects on quality criteria, e.g., software quality metrics, defects, or readability are missing. With our research, we will bridge this gap and measure the effects of static analysis on software quality evolution. We will measure the effect the removal of code that generates static analysis warnings has on software quality metrics. Furthermore, we will measure long term effects on external quality attributes, e.g., reported issues and defects. Finally, we want to predict false positives of static analysis warnings by training predictive models on our collected data.

Programming errors in traversal programs over structured data

The biggest problem in computer security is that most systems aren't constructed with security in mind. Being aware of common security weaknesses in programming might sound like a good way to avoid them, but awareness by itself often proves to be insufficient. Understanding security is one thing and applying your understanding in a complete and consistent fashion to meet your security goals is quite another. For this reason, static analysis is advocated as a technique for finding common security errors in source code. Manual security static analysis is a tedious work, so automatic tools which can guide programmers to detect security concerns is suggested. Good static analysis tools provide a fast way to get a detailed security related evaluation of program code. In this paper a new architecture (CBRFD) for software flaw detector, based on the concept of clone detection and case base reasoning, is proposed and various issues which concern detection of security weakness of codes through code clone detector is investigated.

Static code analysis is widely used to support the development of high-quality software. It helps developers detect potential bugs and security vulnerabilities in a program's source code without executing it. While the potential benefits of static analysis tools are beyond question, their usability is often criticised and prevents software developers from using static analysis to its full potential. In the past decade, researchers have studied developer needs and contrasted them to available static analysis tool functionalities. In this paper, we summarize the main design challenges for building usable static analysis tools, and show that they revolve around the notion of explainability, which is a subarea of usability. We present existing analysis tools and current research in static analysis usability, and detail how they approach those challenges. This leads us to proposing potential lines of future work in explainability for static analysis, namely turning static analysis tools into assistants and teachers.

Static and dynamic program analysis tools mostly focus on the detection of a priori defined defect patterns and security vulnerabilities. Automated detection of logical errors, due to a faulty implementation of applications’ functionality is a relatively uncharted territory. Automation can be based on profiling the intended behavior behind the source code. In this paper, we present a new code profiling method that combines the crosschecking of dynamic program invariants with symbolic execution, an information flow analysis, and the use of fuzzy logic. Our goal is to detect logical errors and exploitable vulnerabilities. The theoretical underpinnings and the practical implementation of our approach are discussed. We test the APP_LogGIC tool that implements the proposed analysis on two real-world applications. The results show that profiling the intended program behavior is feasible in diverse applications. We discuss the heuristics used to overcome the problem of state space explosion and of the large data sets. Code metrics and test results are provided to demonstrate the effectiveness of the approach.

Programming tools have expanded both in scope of the problems they solve, and in the kinds of techniques they use. Traditionally, programming tools have focused on detecting errors in programs. Recently, this scope has broadened to help with other programming tasks, including inferring specifications, helping diagnose root cause of errors during debugging, and managing knowledge in large projects. Also, traditionally programming tools have been based on either static or dynamic program analysis. Modern programming tools combine static and dynamic program analysis together with techniques from other disciplines such as statistical and probabilistic inference, and information retrieval. This paper reports on some such tools built by the Rigorous Software Engineering group at Microsoft Research India.

How to apply automated verification technology such as model checking and static program analysis to millions of lines of embedded C/C++ code? How to package this technology in a way that it can be used by software developers and engineers, who might have no background in formal verification? And how to convince business managers to actually pay for such a software? This work addresses a number of those questions. Based on our own experience on developing and distributing the Goanna source code analyzer for detecting software bugs and security vulnerabilities in C/C++ code, we explain the underlying technology of model checking, static analysis and SMT solving, steps involved in creating industrial-proof tools.

Embedded software often involves intensive numerical computations and suffers from a number of runtime errors. The technique of numerical static analysis is of practical importance for checking the correctness of embedded software. However, most of the existing approaches of numerical static analysis consider sequential programs, while interrupts are a commonly used facility that introduces concurrency in embedded systems. Therefore, a numerical static analysis approach is highly desired for embedded software with interrupts. In this article, we propose a static analysis approach specifically for interrupt-driven programs based on sequentialization techniques. We present a method to sequentialize interrupt-driven programs into nondeterministic sequential programs according to the semantics of interrupts. The key benefit of using sequentialization is the ability to leverage the power of state-of-the-art analysis and verification techniques for sequential programs to analyze interrupt-driven programs, for example, the power of numerical abstract interpretation to analyze numerical properties of the sequentialized programs. Furthermore, to improve the analysis precision and scalability, we design specific abstract domains to analyze sequentialized interrupt-driven programs by considering their specific features. Finally, we present encouraging experimental results obtained by our prototype implementation.

Self-stabilizing programs automatically recover from state corruption caused by software bugs and other sources to reach the correct state. A number of applications are inherently self-stabilizing---such programs typically overwrite all non-constant data with new input data. We present a type system and static analyses that together check whether a program is self-stabilizing. We combine this with a code generation strategy that ensures that a program continues executing long enough to self-stabilize. Our experience using SJava indicates that (1) SJava annotations are easy to write once one understands a program and (2) SJava successfully checked that several benchmarks were self-stabilizing.

Predicting the outcomes of software projects using data available in early development phases allows developers and managers more time to re-plan or re-design systems as needed to increase success. This research investigates early lifecycle predictive models of software faults and effort using information available no later than the system design phase. Static analysis of system designs characterizes intra- and inter-component control flow structure to calculate objective system design metrics. The model building process composes these design metrics into a set of relative factors that calibrate the relationships between the metrics and software faults and effort. These component-based predictive models provide a powerful approach to capture and analyze the designs of complex systems. These models facilitate the identification of essential system characteristics in terms of component structures and interactions, and they enable comprehensive analysis by being scalable to large systems. The research approach applies static analysis tools to the designs of 23 large-scale NASA systems containing over 5000 software components in order to automatically generate state- and interaction-based models of their designs. The static analysis tools derive the number of internal states for a component from its internal control flow design structure using cyclomatic complexity, and they calculate the number of interactions between components from the passing of control flow or data abstractions between components. The research approach evaluates the models by characterizing their relationships to favorable or unfavorable aspects of the system designs, in terms of component development faults and effort. The data analysis focuses on describing the characteristics of the state- and interaction-based models and identifying system design factors revealed by the models that relate to low or high faults, fault correction effort, and development effort. The results include the following, with comparative data being statistically significant at α < 0.05: ♦ The static analysis tools successfully generated state- and interaction-based models of the 23 system designs comprised of 5469 components. The numbers of states per component were exponentially distributed with an average of 14.3 and a median of 7.0. The numbers of interactions per component were exponentially distributed with an average of 8.8 and a median of 4.0. During system development, the components had 0.60 faults on average. ♦ Components with the most states (top 20%) had 7.8 times more faults than did those with the fewest states (bottom 20%). Components with the most states also had 22.5 times more fault correction effort and 5.4 times more development effort than did those with the fewest states. ♦ Components with the most interactions (top 20%) had 2.9 times more faults than did those with the fewest interactions (bottom 20%). Components with the most interactions also had 3.9 times more fault correction effort and 2.7 times more development effort than did those with the fewest interactions. In conclusion, we outline future research directions that build on these system modeling ideas and strategies.

We introduce the concept of “residual investigation” for program analysis. A residual investigation is a dynamic check installed as a result of running a static analysis that reports a possible program error. The purpose is to observe conditions that indicate whether the statically predicted program fault is likely to be realizable and relevant. The key feature of a residual investigation is that it has to be much more precise (i.e., with fewer false warnings) than the static analysis alone, yet significantly more general (i.e., reporting more errors) than the dynamic tests in the program's test suite pertinent to the statically reported error. That is, good residual investigations encode dynamic conditions that, when taken in conjunction with the static error report, increase confidence in the existence of an error, as well as its severity, without needing to directly observe a fault resulting from the error.

Static analysis tools (e.g., FindBugs) are widely used to detect potential defects in software development. A recent study suggests that there is a moderate correlation between the alerts reported by static analysis tools and software defects [1]. However, despite the actionable alerts reported by static analysis tools, they may report too many meaningless unactionable alerts. Actionable alert refers to the alert which is meaningful and fixable. Unactionable alert (i.e., false positive alert) refers to the alert which is regarded as unimportant to developers, inessential to source code, or will not be fixed by developers. Are all alerts (including both actionable and unactionable alerts) suitable for indicating software defects? To address this question, we classify all the alerts into two categories, namely actionable alerts and unactionable alerts. By the following, we conduct an empirical study to evaluate the degree of correlation between defects and alerts on the evolution of three open source projects with totally 40 releases. The objective of the study is to explore two kinds of correlation analysis: one is the correlation between all the alerts reported by FindBugs and defects among the release history of a project, the other is the correlation between the actionable alerts and defects. As a result, we find that not all the alerts but the actionable alerts are suitable to be an early predictor of defects.

Whitebox fuzzing is a novel form of security testing based on dynamic symbolic execution and constraint solving. Over the last couple of years, whitebox fuzzers have found many new security vulnerabilities (buffer overflows) in Windows and Linux applications, including codecs, image viewers and media players. Those types of applications tend to use floating-point instructions available on modern processors, yet existing whitebox fuzzers and SMT constraint solvers do not handle floating-point arithmetic. Are there new security vulnerabilities lurking in floating-point code?A naive solution would be to extend symbolic execution to floating-point (FP) instructions (months of work), extend SMT solvers to reason about FP constraints (months of work or more), and then face more complex constraints and an even worse path explosion problem. Instead, we propose an alternative approach, based on the rough intuition that FP code should only perform memory safe data-processing of the payload of an image or video file, while the non-FP part of the application should deal with buffer allocations and memory address computations, with only the latter being prone to buffer overflows and other security critical bugs. Our approach combines (1) a lightweight local path-insensitive may static analysis of FP instructions with (2) a high-precision whole-program path-sensitive must dynamic analysis of non-FP instructions. The aim of this combination is to prove memory safety of the FP part of each execution and a form of non-interference between the FP part and the non-FP part with respect to memory address computations.We have implemented our approach using two existing tools for, respectively, static and dynamic x86 binary analysis. We present preliminary results of experiments with standard JPEG, GIF and ANI Windows parsers. For a given test suite of diverse input files, our mixed static/dynamic analysis is able to prove memory safety of FP code in those parsers for a small upfront static analysis cost and a marginal runtime expense compared to regular dynamic symbolic execution.

Static analysis is a tremendous help when trying to find faults in complex software. Writing multi-threaded programs is difficult, because the thread scheduling increases the program state space exponentially, and an incorrect thread synchronization produces faults that are hard to find. Program checkers have become sophisticated enough to find faults in real, large-scale software. In particular, Jlint, a very fast Java program checker; can check packages in a highly automated manner. The original version, Jlint1, still lacked full support for synchronization statements in Java. We extended Jlint1's model to include synchronizations on arbitrary objects, and named our version Jlint2. Our statistical analysis proves that these extensions are relevant and useful. Applying Jlint2 to various large software packages, including commercial packages from Trilogy, found 12 faults, two of which related to multi-threading.