The study, which surveyed Common Vulnerability Scoring System (CVSS) data from 1988 to 2012 found that buffer overflows were the most often reported vulnerability, with 7809 reported over the last 25 years - about 14% of the 54,000 software vulnerabilities that were assigned CVSS ratings. Sourcefire analyst Yves Younan will present the results of the survey at the RSA Security Conference in San Francisco on Friday.
Sourcefire’s analysis found that, just in terms of the number of vulnerability reports, buffer overflows were followed closely by cross-site scripting (XSS) vulnerabilities, with 7006 occurrences. But buffer overflows were the clear winner when the CVSS data was narrowed to vulnerabilities with “high” severity ratings. Of the almost 16,000 CVSS vulnerabilities rated “high”, there were 5528 buffer overflow vulnerabilities - more than a third of the total. In contrast, there were only 141 XSS vulnerabilities.
Buffer overflows are a kind of programmer-induced error in which software applications fail to properly manage memory allocation, allowing data written to a buffer in memory to overflow the buffer’s boundary, corrupting adjacent memory. Overflows are easy to create by novice or experienced developers who fail to do proper bounds checking on variables within their application code. Overflows can cause programs to crash and are commonly manipulated by hackers to place malicious code on a vulnerable system which the application can be tricked into running.
Despite the emergence of sophisticated static code analysis tools in the last 15 years, overflow errors remain stubbornly persistent problem. A report written in 2000 by faculty at the Oregon Graduate Institute of Science and Technology declared buffer overflows the “vulnerability of the decade” (that decade being the 1990s) and posited that “If buffer overflow vulnerabilities could be effectively eliminated, a very large portion of the most serious security threats would also be eliminated. ”
Alas - it was not to be. Although the overall numbers of buffer overflows have ebbed and flowed from year to year, Sourcefire’s analysis reveals their stubborn consistency: they were the top vulnerabilities every year between 1988 and 1998, before briefly falling from the top spot in 1999. They were the most common kind of vulnerability again in 2000, and then every year after until 2005 when they were displaced by cross-site scripting (XSS) vulnerabilities.
Some of this data needs to be taken with a grain of salt. Sourcefire found 22,000 vulnerabilities that weren’t categorized by type, leaving the company to normalize a huge chunk of vulnerability reports. There are also overlapping categories. So-called “input validation” vulnerabilities are tracked as a separate category of vulnerability, but “input validation” is a big tent that also holds SQL injection and buffer overflow - and even some cross-site scripting. The explosive growth of the web also led to an explosion in cross-site scripting (XSS) vulnerabilities that skewed the numbers for a few years. Initially, XSS holes were tracked individually, but they’re so ubiquitous that they rarely get a unique CVSS vulnerability number, leading to a “drop off” in the number of XSS holes that’s illusory.
“Vulnerabilities are here to stay,” said Younan. “We have to live with them and mitigate them.”
And times are changing. SQL injection and “access control” vulnerabilities were more common than buffer overflows in 2012. But the stubborn staying power of buffer overflows for more than two decades - despite gallons of industry ink spilled on the problem - is dispiriting and has to get us thinking about what it is we’re doing wrong as an industry.
Top on the list has to be developer education. As CA Veracode’s Chris Wysopal has noted, most Computer Science programs don’t teach aspiring students secure coding concepts, or the kinds of forensic skills that you need to discover vulnerabilities and fix them. SQL injection and buffer overflow problems are trivially easy to create and, in the struggle to get an application working, they might seem like a small matter. But, as we know, its a lot easier (and less expensive) to fix a problem in the development stage than it is to retrofit a fix after the application has been finished and released to customers.
As Chris has said, more of what we teach should be based in the real world and oriented to getting students comfortable writing the kinds of applications they’ll be asked to write out in the work world.
Beyond that, Younan said that the CVSS system could be improved by taking into account mitigation strategies for specific vulnerabilities, not just how exploit-able they are.
“You need to have a broad view of how the vulnerability affects the product and what to do about it,” he said.