Buffer overflows likely to be around for another decade
By Edward Hurley, News Writer
30 Oct 2002 | SearchSecurity.com
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,
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
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
While they occur in many applications, buffer overflows are most
damaging in core infrastructure such as domain name servers and Web
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.
Bookmark with Del.icio.us