Buffer overflows likely to be around for another decade

By Edward Hurley, News Writer

Few classes of security flaws in software cause as many headaches as buffer overflows. Yet given the present programming paradigm, buffer overflows will be around for some time to come, experts say.

Buffer overflows in both Unix and Windows systems were common occurrences in the recently released SANS/FBI Top 20 List of Web vulnerabilities. Buffer overflows open gaping holes that attackers can exploit, as the recent Slapper worm showed. The worm took advantage of a buffer overflow in OpenSSL running on Linux Apache Web servers to set up peer-to-peer networks and to commandeer other computers for possible use in launching distributed denial-of-service attacks.

Often buffer overflow vulnerabilities are hard to find in the minutiae of computer code. Additionally, the nature of the popular C programming language makes them an easy programming error to make, experts said.

In essence, a buffer overflow occurs when too much data is stuffed into a memory space. They are common in applications written in C.

Gerhard Eschelbeck, vice president of engineering at Redwood Shores, Calif.-based Qualys Inc., compares buffer overflows to people filling in handwritten forms that allow one space for each letter of a person's name. A buffer overflow is similar to what happens when the writer does not having enough blocks for one's last name, he said.

The extra "letters" or data aren't lost but written into other places in memory. This could cause the application to act oddly or shut down, creating a denial-of-service condition. It can also allow an attacker to run malicious code on the system. "The code looks the same to the computer," Eschelbeck said.

Buffer overflows can occur in both the stack and heap areas of memory. Stack memory is a pool that all programs can share. When a buffer overflow occurs, the extra data is put into stack memory, much like a card is added to a deck, said Ted Doty, director of product management at Waltham, Mass.-based Okena Inc. The system doesn't realize that data may be malicious.

Buffer overflows in heap memory are similar, except that heap memory is specifically allocated to a program, Doty said.

Buffer overflows are hard to find, and that's why many make their way into finished software products. Basically, one has to squeeze large amounts of data into every area of a program that can accept it to find them, Doty said.

Once an attacker is able to find a buffer overflow, exploiting it is often quite simple.

Finding buffer overflows is especially hard in large server applications that may have as many as 40 million lines of code, Doty said. Software vendors are under too much pressure to get new versions out to market to audit every line of code, he added.

At their most basic, buffer overflow vulnerabilities are programming errors. Error-checking for a too-long string of data wasn't included in the program.

One reason for this is that the C programming language doesn't have boundary checking. It's assumed that someone programming in C would include error-checking in their code, Doty said.

Other languages such as Perl and Java have the utility, hence buffer overflows don't occur, Eschelbeck said. On the other hand, Perl and Java don't offer access to the system that is as deep as some programs need. "The C programming language is very powerful. You can go as deep as you need," he said.

Better programmer training and education would minimize buffer overflows. Certain C functions such as string copy need to be avoided in order to minimize buffer overflows. There are code-auditing tools that look for such flaws, but they are still pretty early in their development, Eschelbeck said.

Software users, however, need to keep on buffer overflows in the applications they run. This means keeping tabs on advisories released by the Computer Emergency Response Team at Carnegie Mellon University or by vendors. Installing the released patches is also a must.

While they occur in many applications, buffer overflows are most damaging in core infrastructure such as domain name servers and Web servers.

Even if all programs started today were written buffer-overflow free, the vulnerabilities will continue to be found for the next few years because of the millions of lines of code that have not been audited. "There's no doubt in my mind that we'll be dealing with buffer overflows for at least the next 10 years," Eschelbeck added.