Building cars with gas tanks that explode on impact wasn't a good idea, and automakers eventually phased that feature...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
out of their products. Software vendors could learn a lesson from that mistake, and deal with their own particular built-in security bomb: buffer overflows.
A Gartner study found buffer overflows to be the most common security flaw in programs. Unfortunately, matters haven't improved since that study was done in 1999. Not a week goes by without the announcement of yet another serious overflow-triggered vulnerability.
Overflows occur when a program tries to store more data than the allocated memory can hold. The extra data slops over into the adjacent memory area, overwriting what was already there, including data or instructions. Malicious hackers have become proficient at leveraging such overflows to introduce their own code into programs, effectively hijacking the computer.
At the same time, overflows occur when programmers do not include code to check the size of data before storing it. Some programming languages make overflows difficult or impossible, because they automatically expand the memory area as needed to accommodate incoming data. Other languages, including C, make overflows practically inevitable since they typically lack any automatic size checking and will happily cram "10 pounds of data" into a five-pound memory area.
Unless a programmer makes a special effort to test for overflow conditions, these flaws become part of the application. The deadline pressure to get code out the door exacerbates the problem: instead of developers or testers addressing the issue, flaws turn up on the computers of millions of users.
How widespread is this overflow problem? Are some software vendors worst offenders than others? You might expect so, since different companies use different programming standards in creating their applications. And is the problem getting better or worse?
A look at IT security company Secunia's database of advisories can provide an estimate on the status of the overflow problem. Selection criteria for this article included vulnerabilities that are serious, remotely exploitable and damaging (permitting denial of service, exposure of sensitive information or system information, system hijacking, ID spoofing, manipulation of data, privilege escalation, security bypass or system access).
It's immediately obvious that vulnerabilities due to overflows are extensive. Investigating advisories from September 2002 to March 2004 shows that a third are related to overflows (224 of 659). Every month during that time, there were at least four, and some months as many as 26, overflow-related advisories, with an average of 11 per month.
It's not just small, resource-deprived companies that are struggling with this issue. On the contrary, serious overflows have plagued the products of many large and well-known software vendors.
There are some differences among vendors in how many security vulnerabilities are attributable to overflows. Apple, Opera, Oracle, Symantec and Yahoo advisories were nearly all on overflows. However, less than half of Cisco, Microsoft and Sun advisories were about overflows. The differences can be interpreted in various ways. Perhaps the latter are better at avoiding overflows in their code, or maybe the former have eliminated all other types of vulnerabilities more effectively.