Sybase has threatened to sue a UK-based security research firm if it publicly discloses the details of eight holes it found in Sybase's database software last year in a move that is evoking sharp criticism from some IT managers but sympathetic comments from others.
Blocking the release of vulnerability information "would set a bad precedent" for the software industry, says Tim Powers, senior network administrator at Southwire a US-based maker of electrical wires and cables.
Responsible disclosure of software flaws by vulnerability researchers has "significantly improved" the security of products, Powers says. "Preventing disclosure through the threat of legal action can only hurt security," he added.
But Kim Milford, information security manager at the University of Rochester in New York, says she thinks that most IT support workers would contact their software vendors directly for help if security patches weren't effective or couldn't be applied to their systems. In such cases, "hackers tend to benefit the most from the release of technical details" about security vulnerabilities, she says.
California-based Sybase sent a letter to Next Generation Security Software warning of legal consequences if the company went ahead with plans to release information about the flaws it discovered in Version 12.5.3 of Sybase's Adaptive Server Enterprise (ASE) software.
NGS initially disclosed the existence of the flaws only to Sybase, which released a fully patched and updated version of the affected software in February. In line with its stated practice of waiting for vendors to issue patches, NGS had said it would publicly release details of the flaws last Monday. But it decided not to after receiving Sybase's letter.
"We were quite shocked," NGS co-founder David Litchfield says via email. "They claim that looking for security bugs comes under the banner of database performance testing and benchmarking." Litchfield noted that the licence agreement for the Development Edition of Sybase ASE prohibits the publication of performance testing and benchmarking results without Sybase's permission.
In an -mailed statement, a Sybase spokeswoman defended the company's action and says it was motivated by concern for the security of ASE users. "Sybase does not object to publication of the existence of [security] issues discovered in its products," the statement read. "However, the company does not believe that publication of highly specific details relating to issues is in the best interest of its customers."
The case highlights the need for more cooperation between software vendors and vulnerability researchers, says Eric Beasley, senior network manager at Baker Hill, a US provider of application services to the banking industry.
"I think it's a very bad idea to try and squash vulnerability research because then, obviously, most [vendors] are not going to endeavor to make safer software," Beasley says. "Security through obscurity just does not work."
At the same time, though, security researchers need to work with vendors and ensure that information is disclosed only in a responsible and safe manner, Beasley added. "The two sides need to be looking at such problems together and not get into such an adversarial relationship," he says.
Sybase's warning, though rare, isn't entirely unprecedented, says Michael Sutton, director of vulnerability research at iDefense in Virginia. In the past, iDefense has been threatened with similar actions by software vendors, though none has yet gone to the extent of sending a formal legal notice like Sybase did, Sutton says.
Bruce Schneier, chief technology officer at Counterpane Internet Security and a longtime advocate of public disclosures of vulnerabilities, says the notion that bug hunters only increase security risks by unearthing and disclosing well-hidden software problems is just plain wrong.
"That is just naive," Schneier says. "Don't shoot the messenger. Just fix the problems in your software."
But Bob Bagamery, a systems support specialist at a large Canadian utility that he asked not to be named, said the threat of disclosing detailed information about vulnerabilities should be used by security researchers only "when not enough effort is being made to correct the flaw, or when the software manufacturer is trying to blow off" the issue.