Code catcher in a box
The BugScan appliance could be a developer’s best friend: It catches potential security holes in your application code
A programmer, even a good programmer, can produce insecure code. Not because of a mental slip-up, but simply because the programmer is focusing on solving the problem at hand (and meeting a deadline) rather than safeguarding that code from exploitation by some hypothetical hacker. But, as the Blaster worm's mayhem emphasized, software must do more than simply work well -- it must also run securely.
HBGary's BugScan is a static program analysis tool that locates an application's potential security problems, sections of code that could be attacked to crash the applications and, possibly, the host system.
BugScan analyzes binaries: C/C++ EXEs (Windows or Linux x86) and DLLs. The tool's static analysis traces all of a program's paths of execution, and from that uncovers insecure coding patterns. I tested the 2003 release of BugScan, and found it useful as part of a larger testing strategy, though its interface still needs a little smoothing out.
The Analyzing Appliance
BugScan arrives as a software/hardware combination appliance: a Dell PowerEdge 650 with a 2.4GHz Pentium 4, 256MB RAM, and 80GB of disk storage.
Installation could not be simpler. Plug the appliance in, connect an Ethernet cable, turn the system on, and dust off your hands ... you're done. BugScan appears at a nonroutable (internal) IP address. The system I tested was configured to 192.168.200.200, so I pointed my browser at the URL http://192.168.200.200/bugscan, and the log-in page appeared.
BugScan comes configured with two log-ins, "admin" and "guest." The former has full administration privileges; the latter has access to BugScan's analysis capabilities. Only five users can be simultaneously connected to BugScan; that’s the standard configuration, but you can get support for more users if necessary.
Putting BugScan to work on a file amounts to selecting the "Analyze a File" screen, entering the path to the file into a textbox, and clicking the submit button. BugScan downloads the executable to the appliance, and places an entry for the file in an input queue. The analysis loop in BugScan pulls items off the queue, processes them, and puts the results in a list of output reports on the Report page. It works at a nice clip -- somewhere between 100K and 1MB per second, depending on size and complexity of the code being processed.
BugScan's analysis is entirely static. It reads the executable file, partitions the codes into blocks, and plots how execution will flow from one block to another when the program executes. Once BugScan has the code mapped out, it uses pattern recognition to locate sections of code that are potential security risks. The process detects such situations as insecure library calls, potential buffer overflow sites, possibly problematic signed/unsigned conversions, poor randomness (which can create insecure cookies and IDs), and format string problems (which allow an attacker to snoop into memory via poorly-formed printf()-family calls).
This sort of analysis has its pluses and minuses. On the minus side, the code is never executed, so BugScan only identifies potential problem code. In other words, it's possible that BugScan will flag false positives, and the version I used doesn’t even provide a way to filter the tests.