Home » Data Protection » Application Security

Software Vulnerability Disclosure: The Chilling Effect

How the Web makes creating software vulnerabilities easier, disclosing them more difficult and discovering them possibly illegal

The confounding part of all the grandstanding, though, was how unnecessary it was. In fact, as early as 2000, a hacker known as Rain Forest Puppy had written a draft proposal for how responsible disclosure could work. In 2002, researchers Chris Wysopal and Christey picked up on this work and created a far more detailed proposal. Broadly, it calls for a week to establish contact between the researcher finding a vulnerability and a vendor's predetermined liaison on vulnerabilities. Then it gives the vendor, as a general guideline, 30 days to develop a fix and report it to the world through proper channels. It's a head-start program, full disclosure—delayed. It posits that a vulnerability will inevitably become public, so here's an opportunity to create a fix before that happens, since the moment it does become public the risk of exploit increases. Wysopal and Christey submitted the draft to the IETF (Internet Engineering Task Force), where it was well-received but not adopted because it focused more on social standards, not technical ones.

Still, its effects were lasting, and by 2004, many of its definitions and tenets had been folded into the accepted disclosure practices for shrink-wrapped software. By the time Lynn finally took the stage and disclosed Cisco's vulnerabilities, US-CERT, Mitre's CVE dictionary (Christey is editor), and Department of Homeland Security guidelines all used large swaths of Wysopal's and Christey's work.

Recently, economist Arora conducted several detailed economic and mathematical studies on disclosure, one of which seemed to prove that vendors patch software faster when bugs are reported through this system. For packaged software, responsible disclosure works.

From Buffer Overflows to Cross-Site Scripting

Three vulnerabilities that followed the responsible disclosure process recently are CVE-2006-3873, a buffer overflow in an Internet Explorer DLL file; CVE-2006-3961, a buffer overflow in an Active X control in a McAfee product; and CVE-2006-4565, a buffer overflow in the Firefox browser and Thunderbird e-mail program. It's not surprising that all three are buffer overflows. With shrink-wrapped software, buffer overflows have been for years the predominant vulnerability discovered and exploited.

But shrink-wrapped, distributable software, while still proliferating and still being exploited, is a less desirable target for exploiters than it once was. This isn't because shrink-wrapped software is harder to hack than it used to be—the number of buffer overflows discovered has remained steady for half a decade, according to the CVE (see chart on Page 21). Rather, it's because websites have even more vulnerabilities than packaged software, and Web vulnerabilities are as easy to discover and hack and, more and more, that's where hacking is most profitable. In military parlance, webpages provide a target-rich environment.