When to Disclose

There's no good time for vulnerability discovery, but when's the right time to disclose it publicly?

The red-hot debate over the "responsible" disclosure of software vulnerabilities has nearly bubbled over lately, with eEye Digital Security's recent disclosure of the Microsoft IE patch that opened another hole in the browser, the Black Hat/Apple laptop wireless hack incident, and most recently, 3Com/Tipping Point's Zero Day Initiative (ZDI) this week publishing a list of vendors with unpatched vulnerabilities its researchers have found. (See IE Patch Created New Vulnerability, Black Hat Flaw Eludes Cisco, and TippingPoint Posts List of Upcoming Bugs.)

Researchers are quick to defend their work as altruistic and crucial to keeping networks and systems safe from exploits and cybercrime. Affected vendors like Microsoft and Apple, however, say researchers should report bugs to them first and then keep them under wraps until patches are released. Microsoft has made it clear it has no tolerance for researchers who reveal a vulnerability before it's patched, but ironically, eEye's disclosure raised questions about Microsoft's own disclosure policies. (See IE Patch Created New Vulnerability.)

Enterprises are the obvious victims if researchers and vendors aren't on the same page, but can the vendors be victims, too?

It certainly doesn't make things easier for a vendor whose product sports a new-found hole when a researcher goes public first. But researchers are often frustrated with slow responses (or none at all) when they report their findings to a vendor. So they go ahead and let the cat out of the bag.

"In light of recent events, I think that security companies have every right to pressure vendors with public disclosure of timelines," says Jon Ellch, an independent researcher. "Otherwise, you get vendors who do very unethical things."

Ellch and fellow researcher David Maynor of SecureWorks experienced first-hand just how sensitive the whole disclosure topic can be. They found themselves smack in the middle of an ugly war of words with pro-Apple bloggers and their supporters and even received electronic threats after they demo'ed vulnerabilities in wireless device drivers using an Apple MacBook and an unnamed third-party wireless device driver at the Black Hat conference earlier this month. As part of its responsible disclosure policy, SecureWorks won't give up the name of the driver vendor until a patch is out. Nonetheless, they were accused of misrepresenting the driver as Apple's, but the researchers have said publicly it was that of a third party. (See Apple's Core Is Secure.)

Meanwhile, security firms that pay researchers for vulnerabilities they find argue that it keeps more bugs off the street. David Endler, director of security research for 3Com/TippingPoint, which pays researchers for the vulnerabilities they find, says researchers in its program sign a contract promising not to reveal the bug until the said vendor has released a patch.

But that doesn't mean 3Com/TippingPoint lets vendors off the hook. As of this week, if vendors don't respond in a reasonable timeframe with a patch for a vulnerability 3Com/TippingPoint informed them about, the company publishes the vendor's name and number of unpatched vulnerabilities still in the pipeline. "We just want people to know which ones we're working on and when we submitted them to those vendors," Endler says. The list doesn't give away much, just the vendor name, severity of the vulnerability, number of them, and the dates they were reported to the vendor.

"Responsible disclosure doesn't always work when vendors don't respond in a timely manner," Endler says. "It's an artful balance. We're opening the kimono while still being true to our responsible disclosure policy."

But even the term "responsible disclosure" is a source of controversy. "It's a non-fact created by certain members of the software industry," says researcher HD Moore, who heads up the Metasploit Project. "A few security companies play by it, but most of them have consulting contracts with the software companies that defined it in the first place," including Microsoft, for example, he says.

And researchers say there's some underlying distrust about what they do. "There's a misconception that anyone who finds vulnerability is malicious. That's not true," Endler says. "There are legitimate reasons for finding a vulnerability, or it's serendipity -- they are trying to find an issue to protect other users."

But some security researchers are PR-savvy, says Michael Rothman, president of Security Incite. These are the ones, he says, who search for and reveal vulnerabilities to give their companies a boost or get their name out there if they are fledgling independents. "They are rock stars now," Rothman says.

Whether researchers wait for vendors to disclose bugs or not, there are plenty of potential bugs to go around. Richard Stiennon, president of IT-Harvest, says researchers should focus more on studying vulnerabilities in security products and server OS and application platforms, however, rather than on the obvious ones.

— Kelly Jackson Higgins, Senior Editor, Dark Reading