Catching Implementation Bugs Early (with a Tool)

Programmers make little mistakes all the timea missing semicolon here, an extra parenthesis there. Most of the time, such gaffes are inconsequential; the compiler notes the error, the programmer fixes the code, and the development process continues. This quick cycle of feedback and response stands in sharp contrast to what happens with most security vulnerabilities, which can lie dormant (sometimes for years) before discovery. The longer a vulnerability lies dormant, the more expensive it can be to fix. Adding insult to injury, the programming community has a long history of repeating the same security-related mistakes.

One of the big problems 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 ever told them what to avoid or how to build secure software. Another big problem is that most programming languages were not designed with security in mind. Unintentional (mis)use of various functions built into these languages leads to very common and often exploited vulnerabilities.

Creating simple tools to help look for these problems is an obvious way forward. The promise of static analysis is to identify many common coding problems automatically, before a program is released.

Static analysis tools (also called source code analyzers) examine the text of a program statically, without attempting to execute it. Theoretically, they can examine either a program's source code or a compiled form of the program to equal benefit, although the problem of decoding the latter can be difficult. We'll focus on source code analysis in this chapter because that's where the most mature technology exists (though see the box Binary Analysis?!).

Manual auditing of the kind covered in Tom Gilb's work is a form of static analysis. Manual auditing is very time consuming, and to do it effectively, human code auditors must first know how security vulnerabilities look before they can rigorously examine the code. Static analysis tools compare favorably to manual audits because they're faster, which means they can evaluate programs much more frequently, and they encapsulate security knowledge in a way that doesn't require the tool operator to have the same level of security expertise as a human auditor. Just as a programmer can rely on a compiler to enforce the finer points of language syntax consistently, the operator of a good static analysis tool can successfully apply that tool without being aware of the finer points of security bugs.

Binary Analysis?!

Source code analyzers are particularly useful when you're building software, but 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. As Exploiting Software explains, attackers really don't need source code to find vulnerabilities and develop exploits [Hoglund and McGraw 2004]. In fact, disassemblers and decompilers are tools that feature prominently in the attacker's toolkit. If the attackers can do this, why can't the good guys?

The answer is not so simple. Finding one or two vulnerabilities in a binary is very easy. In fact, grep-like engines that look for simple patterns in binaries in much the same way that ITS4 looks for them in source code already exist. One of the first was Hoglund's BugScan. The complexity of the problem has its roots deep in the basic asymmetry of computer security. Since attackers need to find only one problem (and build an exploit for it) and defenders need to find all problems (and fix them or otherwise defend against attack), attackers' tools can lack precision and still be useful.

Building a binary scanner is an uphill battle, but it is not impossible. The main problem is creating the same kind of abstract internal representation of a binary that is created when a sophisticated source code analyzer does its thing. Once that is done, standard sorts of analysis engines can be applied to this representation just as in the (easier) source code approach.

Of course, once you find a problem in a binary, what are you to do about it? If you don't have the source code, it seems you are left with either building and applying a binary patch or creating a rule for an external filter. Not pretty.

In the end, it should be clear why source code analysis is superior if you are concerned about the software security big picture and you are creating code. If you are consuming more code than you produce, a binary scanner may be helpful for keeping your software vendors in line.

Testing for security vulnerabilities is complicated by the fact that they often exist in hard-to-reach states or crop up in unusual circumstances. Static analysis tools can peer into more of a program's dark corners with less fuss than dynamic analysis, which requires actually running the code. Static analysis also has the potential to be applied before a program reaches a level of completion at which testing can be meaningfully performed. The earlier security risks are identified and managed in the software lifecycle, the better.