Towards Vulnerability Discovery Using Staged Program Analysis

Eliminating vulnerabilities from low-level code is vital for securing software. Static analysis is a promising approach for discovering vulnerabilities since it can provide developers early feedback on the code they write. But, it presents multiple challenges not the least of which is understanding what makes a bug exploitable and conveying this information to the developer. In this paper, we present the design and implementation of a practical vulnerability assessment framework, called Melange. Melange performs data and control flow analysis to diagnose potential security bugs, and outputs well-formatted bug reports that help developers understand and fix security bugs. Based on the intuition that real-world vulnerabilities manifest themselves across multiple parts of a program, Melange performs both local and global analyses. To scale up to large programs, global analysis is demand-driven. Our prototype detects multiple vulnerability classes in C and C++ code including type confusion, and garbage memory reads. We have evaluated Melange extensively. Our case studies show that Melange scales up to large codebases such as Chromium, is easy-to-use, and most importantly, capable of discovering vulnerabilities in real-world code. Our findings indicate that static analysis is a viable reinforcement to the software testing tool set.Comment: A revised version to appear in the proceedings of the 13th conference on Detection of Intrusions and Malware & Vulnerability Assessment (DIMVA), July 201

The Unexplored Terrain of Compiler Warnings

The authors' industry experiences suggest that compiler warnings, a lightweight version of program analysis, are valuable early bug detection tools. Significant costs are associated with patches and security bulletins for issues that could have been avoided if compiler warnings were addressed. Yet, the industry's attitude towards compiler warnings is mixed. Practices range from silencing all compiler warnings to having a zero-tolerance policy as to any warnings. Current published data indicates that addressing compiler warnings early is beneficial. However, support for this value theory stems from grey literature or is anecdotal. Additional focused research is needed to truly assess the cost-benefit of addressing warnings

The Construction of a Static Source Code Scanner Focused on SQL Injection Vulnerabilties in Java

SQL injection attacks are a significant threat to web application security, allowing attackers to execute arbitrary SQL commands and gain unauthorized access to sensitive data. Static source code analysis is a widely used technique to identify security vulnerabilities in software, including SQL injection attacks. However, existing static source code scanners often produce false positives and require a high level of expertise to use effectively. This thesis presents the design and implementation of a static source code scanner for SQL injection vulnerabilities in Java queries. The scanner uses a combination of pattern matching and data flow analysis to detect SQL injection vulnerabilities in code. The scanner identifies vulnerable code by analyzing method calls, expressions, and variable declarations to detect potential vulnerabilities. To evaluate the scanner, malicious SQL code is manually injected in queries to test the scanner\u27s ability to detect vulnerabilities. The results showed that the scanner could identify a high percentage of SQL injection vulnerabilities. The limitations of the scanner include the inability to detect runtime user input validation and the reliance on predefined patterns and heuristics to identify vulnerabilities. Despite these limitations, the scanner provides a useful tool for junior developers to identify and address SQL injection vulnerabilities in their code. This thesis presents a static source code scanner that can effectively detect SQL injection vulnerabilities in Java web applications. The scanner\u27s design and implementation provide a useful contribution to the field of software security, and future work could focus on improving the scanner\u27s precision and addressing its limitations

What to Fix? Distinguishing between design and non-design rules in automated tools

Technical debt---design shortcuts taken to optimize for delivery speed---is a critical part of long-term software costs. Consequently, automatically detecting technical debt is a high priority for software practitioners. Software quality tool vendors have responded to this need by positioning their tools to detect and manage technical debt. While these tools bundle a number of rules, it is hard for users to understand which rules identify design issues, as opposed to syntactic quality. This is important, since previous studies have revealed the most significant technical debt is related to design issues. Other research has focused on comparing these tools on open source projects, but these comparisons have not looked at whether the rules were relevant to design. We conducted an empirical study using a structured categorization approach, and manually classify 466 software quality rules from three industry tools---CAST, SonarQube, and NDepend. We found that most of these rules were easily labeled as either not design (55%) or design (19%). The remainder (26%) resulted in disagreements among the labelers. Our results are a first step in formalizing a definition of a design rule, in order to support automatic detection.Comment: Long version of accepted short paper at International Conference on Software Architecture 2017 (Gothenburg, SE

Differentially Testing Soundness and Precision of Program Analyzers

In the last decades, numerous program analyzers have been developed both by academia and industry. Despite their abundance however, there is currently no systematic way of comparing the effectiveness of different analyzers on arbitrary code. In this paper, we present the first automated technique for differentially testing soundness and precision of program analyzers. We used our technique to compare six mature, state-of-the art analyzers on tens of thousands of automatically generated benchmarks. Our technique detected soundness and precision issues in most analyzers, and we evaluated the implications of these issues to both designers and users of program analyzers

Development of a static analysis tool to find securty vulnerabilities in java applications

Thesis (Master)--Izmir Institute of Technology, Computer Engineering, Izmir, 2010Includes bibliographical references (leaves: 57-60)Text in English Abstract: Turkish and Englishix, 77 leavesThe scope of this thesis is to enhance a static analysis tool in order to find security limitations in java applications. This will contribute to the removal of some of the existing limitations related with the lack of java source codes. The generally used tools for a static analysis are FindBugs, Jlint, PMD, ESC/Java2, Checkstyle. In this study, it is aimed to utilize PMD static analysis tool which already has been developed to find defects Possible bugs (empty try/catch/finally/switch statements), Dead code (unused local variables, parameters and private methods), Suboptimal code (wasteful String/StringBuffer usage), Overcomplicated expressions (unnecessary if statements for loops that could be while loops), Duplicate code (copied/pasted code means copied/pasted bugs). On the other hand, faults possible unexpected exception, length may be less than zero, division by zero, stream not closed on all paths and should be a static inner class cases were not implemented by PMD static analysis tool. PMD performs syntactic checks and dataflow analysis on program source code.In addition to some detection of clearly erroneous code, many of the .bugs. PMD looks for are stylistic conventions whose violation might be suspicious under some circumstances. For example, having a try statement with an empty catch block might indicate that the caught error is incorrectly discarded. Because PMD includes many detectors for bugs that depend on programming style, PMD includes support for selecting which detectors or groups of detectors should be run. While PMD.s main structure was conserved, boundary overflow vulnerability rules have been implemented to PMD

C++-ohjelmien laadun parantaminen staattisella koodianalyysillä

Static code analysis is the analysis of program code without executing it. Static analysis tools are therefore a useful part of automated software analysis. Typical uses for these tools are to detect software defects and otherwise suspect code. Several algorithms and formal methods are available specializing in code analysis. Token pattern matching is used by simpler tools, while more in-depth tools prefer formal methods such as abstract interpretation and model checking. The choice of algorithms thus depends on the preferred analysis precision and soundness. We introduced the practical problems facing static analysis, especially in the context of C++ software. For static analysis to work in a satisfiable way, the tool must understand the semantics of the code being analyzed. Many tools, particularly open-source ones, have deficiencies in their capabilities of code understanding due to being unable to correctly parse complex C++. Furthermore, we examined the difficulty of handling large numbers of warnings issued by these tools in mature software projects. As a summary, we presented a list of five open-source and six commercial static analysis tools that are able to analyze C++ source code. To find out the viability of integrating static analysis tools in real-world projects, we performed a two-part evaluation. The first part was a measurement of the detection accuracy of four open-source and two commercial tools in 30 synthetic test cases. We discovered that Clang excels in this test, although each tool found different sets of defects, thus reaffirming the idea that multiple tools should be used together. In the second part of the evaluation, we applied these tools on six consecutive point releases of DynaRoad. While none of the tools were able to detect any of the crash defects known in these releases, they proved to be valuable in finding other unknown problems in our code base. Finally, we detailed the integration effort of three static analysis tools into our existing build process.Staattisella koodianalyysilla tarkoitetaan ohjelmakoodin analysointia suorittamatta sitä. Tämä tekee siitä hyödyllistä ohjelmien automaattista analyysia varten. Tyypillisiä käyttökohteita ovat ohjelmavirheiden havaitseminen sekä tyylitarkastuksien tekeminen. Analyysityökalujen toteuttamiseen on useita algoritmeja sekä formaaleja menetelmiä. Yksinkertaisemmat työkalut turvautuvat merkeistä koostuvien hahmojen etsimiseen lähdekoodista. Toteutustavan valinta riippuu pitkälti halutusta analyysin tarkkuudesta. Työssä esiteltiin C++-ohjelmien analyysiin kohdistuvia ongelmia. Staattisen analyysityökalun on toimiakseen ymmärrettävä analysoitava koodi riittävän hyvin, jotta analyysin tuloksista olisi hyötyä. Monella analyysityökalulla on vaikeuksia ymmärtää monimutkaista lähdekoodia, mikä koskee erityisesti avoimen lähdekoodin ohjelmia. Työssä käsiteltiin lisäksi syitä miksi laajojen ohjelmien analysointi on hankalaa suurten varoitusmäärien takia. Lopuksi listattiin viisi avoimen lähdekoodin analysointiohjelmaa sekä kuusi kaupallista ohjelmaa. Työn tarkoituksena oli selvittää mahdollisuuksia integroida staattisia analyysiohjelmia olemassa oleviin kehitysprosesseihin suorittamalla ohjelmilla kaksiosainen arviointi. Ensimmäinen arviointi koostui 30:stä synteettisestä testistä, joissa mitattiin analyysityökalujen tarkkuutta havaita ennalta määriteltyjä ohjelmavirheitä. Clang-kääntäjä suoriutui parhaiten näistä testeistä. Kaikki analyysityökalut havaitsivat kuitenkin eri virheitä, mikä vahvistaa käsitystä siitä, että mahdollisimman monen työkalun käyttö on suositeltavaa. Toisessa arvioinnissa tutkittiin valituilla analyysityökaluilla kuutta eri DynaRoadin julkaisuversiota. Saaduilla tuloksilla pystyttiin vertailemaan analyysityökalujen pätevyyttä havaita ohjelmasta raportoituja kaatumisvikoja. Analyysityökalut eivät tunnistaneet yhtään tunnettua vikaa, mutta osoittivat hyödyllisyytensä löytämällä muita tuntemattomia vikoja. Työn lopuksi käytiin läpi kolmen analyysityökalun integrointi olemassa oleviin kehitysprosesseihin

Quantitative Assessment of the Impact of Automatic Static Analysis Issues on Time Efficiency

Background: Automatic Static Analysis (ASA) tools analyze source code and look for code patterns (aka smells) that might cause defective behavior or might degrade other dimensions of software quality, e.g. efficiency. There are many potentially negative code patterns, and ASA tools typically report a huge list of them even in small programs. Moreover, so far, little evidence is available about the negative impact on performance of code patterns identified by such tools. A consequence is that programmers cannot appreciate the benefits of ASA tools and tend not to include them in their workflow. Aims: Quantitatively assess the impact of issues signaled by ASA tools on time efficiency. Method: We select 20 issues and for each of them we set up two source code fragments: one containing the issue and the corresponding refactored version, functionally identical but without the issue. We set up three different platforms, isolated from network and other user programs, then we execute the code fragments, and measure the execution time of both code versions. Results: We find that eleven issues have an actual negative impact on performance. We also compute for each issue an estimation for the delay provoked by a single execution. Conclusions: We produce a set of issues with a verified negative impact on performance. They can be checked easily with an analysis tool and code can be refactored to obtain a provably more efficient code. We also provide the estimated delay cost of each issue in the environments where we conduct the tests. These results can be improved with the help of other researchers: repeating the tests in several platforms would make it possible to build up a wider benchmar

Who watches the watchers: Validating the ProB Validation Tool

Over the years, ProB has moved from a tool that complemented proving, to a development environment that is now sometimes used instead of proving for applications, such as exhaustive model checking or data validation. This has led to much more stringent requirements on the integrity of ProB. In this paper we present a summary of our validation efforts for ProB, in particular within the context of the norm EN 50128 and safety critical applications in the railway domain.Comment: In Proceedings F-IDE 2014, arXiv:1404.578