Secure Software Development Code Review With a Tool

Secure Software Development Code Review With a Tool Chapter 4 Rasool Jalili & M. S. Dousti Dept. of Computer Engineering Fall 2010

Code Review with a Tool • Debugging is at least twice as hard as programming. • If your code is as clever as you can possibly make it, then by definition you're not smart enough to debug it. • One artifact in common in all software projects: source code. • to center a software assurance activity around code itself. • In terms of bugs and flaws, code review is about finding and fixing bugs. • Architectural risk analysis + code review, tops in the list of software security touchpoints. • Using a tool makes sense because code review is boring and difficult. • Who practice code review are familiar with "get done, go home”. • Manual code review? ? Is anybody aware of that? Secure SW Development (SSD) Grad. Course (R. Jalili & M. S. Dousti) – Fall 2010 Software Security 2

Catching Implementation Bugs Early • A big problem is that security • • is not yet a standard part of the programming curriculum. You can't really blame programmers who introduce security problems into their software if nobody told them what to avoid or how to build SSW. Another problem: most programming languages were not designed with security in mind. Creating simple tools to help for these problems is an obvious way forward. Static analysis is to identify many common coding problems automatically, before a program is released. Manual auditing is very time consuming, and to do it effectively, human code auditors must first know how security vulnerabilities look. Static analysis has the potential to be applied before a program reaches a level of completion at which testing can be performed. The earlier security risks are identified and managed in the software lifecycle, the better. Secure SW Development (SSD) Grad. Course (R. Jalili & M. S. Dousti) – Fall 2010 Software Security 3

Binary Analysis? ! • what about those times when you don't have source code? One common situation arises when you buy commercial software that is delivered only in executable form. • Attackers really don't need source code to find vulnerabilities and develop exploits. • In fact, disassemblers and decompilers are tools are included prominently in the attacker's toolkit. • If the attackers can do this, why can't the good guys? • Finding one or two vulnerabilities in a binary is very easy; . . . • Since attackers need to find only one problem and defenders need to find all problems, attackers' tools can lack precision and still be useful. • If you are consuming more code than you produce, a binary scanner may be helpful for keeping your software vendors in line! Secure SW Development (SSD) Grad. Course (R. Jalili & M. S. Dousti) – Fall 2010 Software Security 4

Aim for Good, Not Perfect • No individual touchpoint or tool can solve all of your software security problems. • Static analysis tools look for a fixed set of patterns, or rules, in the code. • Beware of any tool says, "Zero defects found, your program is now secure. " • The appropriate output is, "Sorry, couldn't find any more bugs. “ • A static analysis tool's output still requires human evaluation. • knowledgeable people still need to get a program's design right to avoid any flaws. • Static analysis tools suffer from false negatives (in which the program contains bugs that the tool doesn't report) and false positives (in which the tool reports bugs that the program doesn't really contain). • False positives cause immediate reaction, but false negatives are dangerous because they lead to a false sense of security. • A tool is sound if, for a given set of assumptions, it produces no false negatives. • A tool is unsound if it tries to reduce false positives at the cost of sometimes letting a false negative born. Secure SW Development (SSD) Grad. Course (R. Jalili & M. S. Dousti) – Fall 2010 Software Security 5

History of Tools • The first code scanner built to look for security problems in code was Cigital's ITS 4. • looking for syntactic matches based on some simple "rules“ indicate possible security vulnerabilities. • One such rule might be "use of strcpy() should be avoided, “ • Rulset is a problem! When ITS 4 released as open source, over 15, 000 people downloaded ITS 4 in the first year, received even one rule to add to its knowledge base! • to serve as part of a minimum set of security rules that every static analysis tool should cover. Secure SW Development (SSD) Grad. Course (R. Jalili & M. S. Dousti) – Fall 2010 Software Security 6

Approaches to Static Analysis • Probably the simplest and most straightforward approach to static analysis is the UNIX utility “grep”. • Armed with a list of good search strings, “grep” can reveal a lot about a code base. • Lexical analysis tools are better than a step up from grep, they produce a large # of false positives because they make no effort on semantics. • To increase precision, a static analysis tool must leverage more compiler technology, by building an abstract syntax tree (AST) from source code. • Local analysis examines the program one function at a time and NO relationships between functions. • Module-level analysis considers one class or compilation unit at a time. • Global analysis involves analyzing the entire program. Secure SW Development (SSD) Grad. Course (R. Jalili & M. S. Dousti) – Fall 2010 Software Security 7

Overlap for ITS 4, RATS, and Source. Scope rules Secure SW Development (SSD) Grad. Course (R. Jalili & M. S. Dousti) – Fall 2010 Software Security 8

Commercial Tool Vendors • Expect great progress in static analysis during the next several years. • In 2004 and 2005, a number of startups formed to address the software security space. • Major vendors in the space include the following: – Coverity <http: //www. coverity. com> – Fortify <http: //www. fortifysoftware. com> – Ounce Labs <http: //www. ouncelabs. com> – Secure Software http: //www. securesoftware. com • Critical differentiator in the static analysis tools market is the kind of knowledge (the ruleset) that a tool enforces Secure SW Development (SSD) Grad. Course (R. Jalili & M. S. Dousti) – Fall 2010 Software Security 9

Secure SW Development (SSD) Grad. Course (R. Jalili & M. S. Dousti) – Fall 2010 Software Security 10

Secure SW Development (SSD) Grad. Course (R. Jalili & M. S. Dousti) – Fall 2010 Software Security 11

Secure SW Development (SSD) Grad. Course (R. Jalili & M. S. Dousti) – Fall 2010 Software Security 12

Commercial Source Code Analyzers • One of the main reasons to use a source code analysis tool is that manual review is costly and time consuming. • Integrating a source code analyzer into your development lifecycle can be painless and easy. • Keeping a list of all known security problems found in a language like C (several hundred) in your head while attempting to trace control flow, data flow, and an explosion of states by hand is extremely difficult! • The root cause of most security problems can be found in the source code and configuration files of common software applications, especially custom apps that you write yourself. • Using an advanced software security tool that returns a small set of potential vulnerabilities can locate actual vulnerabilities in a matter of seconds • Most bad guys know this and will use these kinds of tools themselves Secure SW Development (SSD) Grad. Course (R. Jalili & M. S. Dousti) – Fall 2010 Software Security 13

Key Characteristics of a Tool • a source code analysis tool must have six key characteristics 1 - Be designed for security. Software security may well be a subset of software quality, but software security requires the ability to think like a bad guy. 2 - Support multiple tiers. Modern software applications are rarely written in a single programming language or targeted to a single platform. 3 - Be extensible. Security problems evolve, grow, and transform. 4 - Be useful for security analysts and developers alike. Good tools support not only analysts but also the poor developers who need to fix! 5 - Support existing development processes. Interoperate with existing compilers used on the various platforms and support popular build tools like make. 6 - Make sense to multiple stakeholders. SWS is an ongoing process that necessarily involves the contributions of many people across an organization. Secure SW Development (SSD) Grad. Course (R. Jalili & M. S. Dousti) – Fall 2010 Software Security 14

Three Characteristics to Avoid • Early approaches suffered from a number of unfortunate problems. 1 - Too many false positives; a false positive rate under 40% are okay. ITS 4 would sometimes produce rates in the range of 90% and higher, making it a real pain to use 2 - Spotty integration with IDEs (Integrated Development Env. ). 3 - Single-minded support for C. If your system is built of more than C, make sure you don't skip the "non-C" parts when you review code. Secure SW Development (SSD) Grad. Course (R. Jalili & M. S. Dousti) – Fall 2010 Software Security 15

Secure SW Development (SSD) Grad. Course (R. Jalili & M. S. Dousti) – Fall 2010 Software Security 16

Touchpoint Process: Code Review • The last slide shows a very simple process for applying a static analysis. • Note that this is only one of many processes that can be wrapped around a source code analysis tool. • Fixing the code itself is not part of this process. • Good static analysis tools must be easy to use, even for non-security people. • Results from these tools must be understandable to normal developers who might not know much about security. • Static analysis for security should be applied regularly as part of any modern development process. Secure SW Development (SSD) Grad. Course (R. Jalili & M. S. Dousti) – Fall 2010 Software Security 17