Programming resources boost software security

In 2008, a team of researchers found security vulnerabilities in an implantable cardiac defibrillator that could have put patients’ lives at risk. While this discovery was dramatic, it was depressingly unsurprising given that the state of software security has been dire for decades and is increasingly affecting embedded devices.

As functionality grows, embedded devices are becoming a more appealing target to attackers. The widespread adoption of network and wireless interfaces is increasing the attack surface, in other words, the number of ways in which an attacker can attempt to gain access. While developers in other domains such as e-commerce have dealt with these issues for many years, their techniques and tools do not necessarily work well for embedded development. Embedded developers are finding that they need a new awareness of security vulnerabilities and practical ways to prevent them.

Identifying and avoiding mistakes

The first lesson of software security is that it is imperative to consider security requirements during system design, as it is notoriously difficult to retrofit security measures later. The Build Security In portal (https://buildsecurityin.us-cert.gov) provides several useful resources to help developers accomplish this.

However, design isn’t everything. Many seemingly secure designs can be fatally undermined because of simple and avoidable programming mistakes. For example, a design could contain dozens of security holes because a programmer failed to consider the possibility of a buffer overflow. Other such errors include race conditions, resource leaks, uninitialized variables, and many more. Bugs such as these can allow an attacker to gain control of the system or prevent it from operating properly.

One of the first things a developer should do is learn about which bugs can lead to security problems and why. One useful resource is the Common Weakness Enumeration (CWE), which is essentially a field guide to bugs. This community-developed dictionary catalogs hundreds of different kinds of bugs and describes their risks and implications. The entry for each bug describes how to avoid it and gives advice on how to find it with testing or static analysis. The best starting point from a security perspective is the CWE/SANS Top 25 most dangerous programming errors (http://cwe.mitre.org/top25), which lists the most important bugs to avoid to reduce security risks.

The most effective way to avoid these bugs is by prevention. The Computer Emergency Response Team Coordination Center (CERT/CC) at Carnegie Mellon University has observed that most security vulnerabilities originate with a few types of programming errors. The team has developed a set of secure coding practices designed to minimize the probability of these bugs making it into production code (www.cert.org/secure-coding). Note that there is some overlap between these rules and other safety-critical programming guidelines such as Misra C or “The Power of 10: Ten Rules for Writing Safety-Critical Code” (http://spinroot.com/p10).

The traditional way to attempt to locate bugs is through rigorous testing. Testing suffers from being expensive and time-consuming, and the results are only as good as the test suite. Although testing is essential, it won’t find everything, and other techniques can be useful as well. A complementary approach that has recently gained popularity is the use of static analysis tools. These tools are effective because they explore many more potential executions than can be realistically covered by any test suite, but without ever having to actually execute the program.

Sophisticated tools for finding bugs

Several products on the market are specifically designed to find security vulnerabilities statically. Among the most prominent products are the security scanners sold by Fortify and Ounce (recently acquired by IBM). Because these tools were designed to address corporate security problems such as those found in network and desktop applications, they are not as effective for embedded development.

Most embedded developers are better served by an entirely different class of static analysis tools. Advanced static analysis tools such as GrammaTech’s CodeSonar use highly sophisticated symbolic execution techniques to find serious programming errors. These tools are much more effective at finding bugs than security scanners, and because there is a strong correlation between bugs and security vulnerabilities in C/C++ programs, they are essential for improving software security. Many developers are already familiar with these tools, as they are used to find many different kinds of bugs.

The key difference between scanners and advanced static analysis tools is the depth of their analysis. In addition to their ability to scan programs written in several different languages including Java, PHP, and Perl, security scanners know the security properties of various APIs. Scanners also use data flow analysis techniques to find paths through the code where untrusted inputs are not correctly sanitized before being processed. These techniques can help find vulnerabilities such as cross-site scripting errors and command injection flaws.

For many domains, it is extremely important to find such problems; however, embedded systems vulnerabilities are more likely to take the form of low-level bugs such as race conditions, numeric overflows, and resource leaks – problems that advanced static analysis tools excel at finding. Furthermore, advanced static analysis tools report many fewer false positives than security scanners.

For example, consider the C library function strcpy, a widely used library function familiar to most embedded C programmers. If used incorrectly, strcpy can cause a buffer overrun, so its use is forbidden by some security coding standards. A security scanner might report all or most uses of that function as potential security vulnerabilities regardless of context. On the other hand, an advanced static analysis tool is capable of much finer discrimination because it performs a deeper analysis.

In this example, the tool’s symbolic execution explores paths through the code, and along each path it knows which pointers address which buffer, how many bytes are available in each buffer, and the position of the null terminator therein. Consequently, the analysis can tell the difference between a legal use of the function and one that could cause a buffer overrun. If a warning is issued, the tool shows not only the point at which the buffer is overflowed, but also the path through the code to that point and the values of variables that contribute to whether or not the bug will occur. To illustrate this analysis, Figure 1 shows a CodeSonar report of a buffer overrun found in an open source project. The overrun occurs on line 599 as a consequence of a mistake on line 597, where the author placed the +1 on the wrong side of the parenthesis.

Figure 1: Advanced static analysis tools such as CodeSonar can identify a buffer overrun caused by incorrect use of the C library function . (click graphic to zoom by 1.9x)

Support for security efforts

Considering the implications of these types of bugs, it is clear that embedded software security risks are increasing, and embedded developers should thus actively evaluate the security aspects of their code. Fortunately, a variety of resources such as catalogs of dangerous security vulnerabilities, rules for avoiding these problems, and tools for finding and eliminating them in software are available to aid their efforts.

Paul Anderson is VP of engineering at GrammaTech, a spin-off of Cornell University that specializes in static analysis. His research on static analysis tools and techniques has been reported in numerous articles, journal publications, book chapters, and international conferences. Paul received his BSc from King’s College, University of London and his PhD in Computer Science from City University London.

GrammaTech 607-273-7340 paul@grammatech.com www.grammatech.com