News

Q&A: A look at static binary analysis and better app security

• By Jack Vaughan
• June 23, 2004

Programmers Report occasionally looks at security issues from the point of view of source code analysis and better coding practices. We recently met with Chris Wysopal, vice president of R&D for @stake Inc., and thought he had a different take on this issue. What follows are excerpts from an e-mail interview.

Q: What is your background in this area?

A: In the late 1980s, I started my career as a software engineer at Lotus Development Corp. building automated quality assurance tools. There wasn't a commercial testing tool industry at the time so we had to build our own [tools]. After Lotus, I moved to Radnet where I was the lead developer building WebShare, one of the first commercial Web application servers. I saw firsthand the challenges of designing and building secure software that executed user scripts, managed users and access control, and secured the data on the system. I caught a passion for security and took a security position at BBN, the company that defined and built some of the fundamental Internet technology. I performed research on the root causes of the security flaws in software, and published reports detailing examples of them in widely used commercial software such as Lotus Notes and Windows NT.

My work in exposing the problems in commercial software led to my presentation of expert testimony in May 1998 on the state of U.S. Government computer security to the U.S. Senate Committee on Governmental Affairs, and again in September 2003 on the problem of viruses and worms to the U.S. House Subcommittee on Technology.

As a founding member of the Organization for Internet Safety (OIS), I helped develop standards for best practices on how the technology industry will report and respond to security vulnerabilities. At @stake, I manage the company's vulnerability research and disclosure process for clients, vendors and consumers, and I'm also leading the product development team that is building a range of application security software tools, including SmartRisk Analyzer.

Q: How did @stake get involved in developing tools for securing software?

A: @stake's roots in building tools for secure software development come from the L0pht hacking collective, and the Secure Lint project in 1999, the year before the L0pht collective became part of @stake. Secure Lint, or SLINT, was a lexical analysis tool that was the first of its kind to automate the process of examining source code to find potential security flaws. This concept evolved over the last five years, changing as security practices have advanced. Our focus on the binary level evolved from our passion for analyzing malware, and the fact that a lot of external code is used in developing new software. Our consulting clients wanted a tool that could not only look at the code they were developing, but inside all the components and libraries that make up the bulk of many applications for which source code is not often available.

Q: What are the essential traits that mark your software?

A: SmartRisk Analyzer allows development and quality teams to automatically identify security vulnerabilities in software applications through the static analysis of application binary code. Using this approach, developers can perform an in-depth analysis by mapping all possible application control and data flow paths into a comprehensive security model, expediting new, legacy and outsourced code review. SmartRisk Analyzer builds a multidimensional model of the applications, and runs hundreds of risk analysis scans against the model to identify and prioritize security vulnerabilities. The strength of the risk analysis scans is the knowledgebase built by our application security consulting practice through its more than 1,000 customer engagements.

It works on the application binary, not the source code. Source code is interpreted by the compiler and is dependent on the environmental components that support it. Lexical [source code] scanners can look only at the source code in isolation. Binary analysis looks at the application and the application's deployment environment. This means the analysis includes any variables introduced by the runtime environment. Most importantly, binary analysis allows users to identify vulnerabilities introduced by third-party libraries -- even those for which the user does not have source code. Lexical analysis, even when using contextual analysis, cannot consider the context of the application's environment.

Q: Can you illustrate how this is different from traditional source code analysis?

A: Static analysis tools analyze software programs without the need to actually run the program. It also does away with the need to build a potentially complex and expensive environment to analyze the security of the program. [Early] static analysis methods included lexical analysis involving a simplistic search of source code for keywords, and keyword searches combined with contextual analysis. The static analysis approach that SmartRisk Analyzer takes -- automated binary code analysis -- significantly improves application security quality when compared with [source code analysis] alone. It lets you look at the applications within the deployment environment, peering deep into all code paths and data flows to find flaws at their source, inside the code in the runtime environment.

Unlike source code analysis, the deep binary approach creates a model of a program's control flow and data flow by reading the executable machine code and building a language-neutral representation of the program's behavior. This model can be traversed by automated scans to find security vulnerabilities, including back doors. A source code emitter can even build a source code representation of the program's behavior.

By building meaning from the individual instructions that are executed by the CPU, deep binary analysis understands program behavior that is inserted by the compiler. More important is the fact that vulnerabilities and back doors can't hide in the static and dynamic third-party libraries a program links to.

Q: What else do developers need to know about static binary analysis? Are they given guidance once flaws are located? Is it intuitive?

A: The software provides both detailed developer reports and summary reports for quality assurance and management. The detailed report offers a comprehensive listing on the source code, including annotated, in-line identification of each flaw. The report shows the developer exactly which lines are vulnerable and why, and also gives suggestions for fixing the problems, ranking each vulnerability by severity. The detailed reports allow engineers to prioritize vulnerabilities during the development cycle, when changes are most cost effective. SmartRisk Analyzer can create a specialized, less-detailed report for executives, showing the number and severity of the flaws in the code.

Summary reports of vulnerabilities by risk, severity and type allow quality assurance staff and management to track flaws and develop historical trends by various criteria. SmartRisk Analyzer assigns risk points for the application and assigns a Security Quotient that is independent of the program's size. The Security Quotient can be used to compare many applications to provide an enterprise-wide view of where the risk resides.

For @stake white papers, research and more go to http://www.atstake.com/research