The chilling effect

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

The rise of responsible disclosure

In the same way that light baffles physicists because it behaves simultaneously like a wave and a particle, software baffles economists because it behaves simultaneously like a manufactured good and a creative expression. It's both product and speech. It carries the properties of a car and a novel at the same time. With cars, manufacturers determine quality largely before they're released and the quality can be proven, quantified. Either it has air bags or it doesn't. With novels (the words, not the paper stock and binding), quality depends on what consumers get versus what they want. It is subjective and determined after the book has been released. Moby-Dick is a high-quality creative venture to some and poor quality to others. At any rate, this creates a paradox. If software is both scientifically engineered and creatively conjured, its quality is determined both before and after it's released and is both provable and unprovable.

In fact, says economist Ashish Arora at Carnegie Mellon University, it is precisely this paradox that leads to a world full of vulnerable software. "I'm an economist so I ask myself, Why don't vendors make higher quality software?" After all, in a free market, all other things being equal, a better engineered product should win over a lesser one with rational consumers. But with software, lesser-quality products, requiring massive amounts of repair post-release, dominate. "The truth is, as a manufactured good, it's extraordinarily expensive [and] time-consuming [to make it high quality]." At the same time, as a creative expression, making "quality" software is as indeterminate as the next best-seller. "People use software in so many ways, it's very difficult to anticipate what they want.

"It's terrible to say," Arora concedes, "but in some ways, from an economic perspective, it's more efficient to let the market tell you the flaws once the software is out in the public." The same consumers who complain about flawed software, Arora argues, would neither wait to buy the better software nor pay the price premium for it if more-flawed, less-expensive software were available sooner or at the same time. True, code can be engineered to be more secure. But as long as publishing vulnerable software remains legal, vulnerable software will rule because it's a significantly more efficient market than the alternative, high-security, low-flaw market.

The price consumers pay for supporting cheaper, buggy software is they become an ad hoc quality control department. They suffer the consequences when software fails. But vendors pay a price, too. By letting the market sort out the bugs, vendors have ceded control over who looks for flaws in their software and how flaws are disclosed to the public. Vendors can't control how, when or why a bug is disclosed by a public full of people with manifold motivations and ethics. Some want notoriety. Some use disclosure for corporate marketing. Some do it for a fee. Some have collegial intentions, hoping to improve software quality through community efforts. Some want to shame the vendor into patching through bad publicity. And still others exploit the vulnerabilities to make money illicitly or cause damage.

"Disclosure is one of the main ethical debates in computer security," says researcher Steve Christey. "There are so many perspectives, so many competing interests, that it can be exhausting to try and get some movement forward."

What this system created was a kind of free-for-all in the disclosure bazaar. Discovery and disclosure took place without any controls. Hackers traded information on flaws without informing the vendors. Security vendors built up entire teams of researchers whose job was to dig up flaws and disclose them via press release. Some told the vendors before going public. Others did not. Freelance consultants looked for major flaws to make a name for themselves and drum up business. Sometimes these flaws were so esoteric that they posed minimal real-world risk, but the researcher might not mention that. Sometimes the flaws were indeed serious, but the vendor would try to downplay them. Still other researchers and amateur hackers tried to do the right thing and quietly inform vendors when they found holes in code. Sometimes the vendors chose to ignore them and hope security by obscurity would protect them. Sometimes, Arora alleges, vendors paid mercenaries and politely asked them to keep it quiet while they worked on a fix.

Vulnerability disclosure came to be thought of as a messy, ugly, necessary evil. The madness crested, famously, at the Black Hat hacker conference in Las Vegas in 2005, when a researcher named Michael Lynn prepared to disclose to a room full of hackers and security researchers serious flaws in Cisco's IOS software, the code that controls many of the routers on the Internet. His employer, ISS (now owned by IBM) warned him not to disclose the vulnerabilities. So he quit his job. Cisco in turn threatened legal action and ordered workers to tear out pages from the conference program and destroy conference CDs that contained Lynn's presentation. Hackers accused Cisco of spin and censorship. Vendors accused hackers of unethical and dangerous speech. In the end, Lynn gave his presentation. Cisco sued. Lynn settled and agreed not to talk about it anymore.

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.

Join the newsletter!


Sign up to gain exclusive access to email subscriptions, event invitations, competitions, giveaways, and much more.

Membership is free, and your security and privacy remain protected. View our privacy policy before signing up.

Error: Please check your email address.
Follow our new CSO Australia LinkedIn
Follow our new social and we'll keep you in the loop for exclusive events and all things security!
Have an opinion on security? Want to have your articles published on CSO? Please contact CSO Content Manager for our guidelines.

More about ABC NetworksACTAltavistaCarnegie Mellon University AustraliaCBS CorporationCERT AustraliaCiscoCreativeFBIGatewayGoogleHISIBM AustraliaIETFInternet Engineering Task ForceISS GroupMcAfee AustraliaMellonMessengerMicrosoftMozillaNetcraftNikePayPalPetcoPromiseSecure ComputingSpeedUSCVIAWarner Bros

Show Comments

Featured Whitepapers

Editor's Recommendations

Brand Page

Stories by Scott Berinato

Latest Videos

More videos

Blog Posts