Microsoft Corp. last week announced a new system for rating the severity of security holes in its software. But it also urged the security community to exercise better judgment about publicizing software vulnerabilities and detailing how they can be exploited.
The practice of publishing explicit, step-by-step instructions for exploiting vulnerabilities contributed to the damage that was inflicted on users of Windows-based systems by recent worms such as Code Red and Nimda, said Scott Culp, manager of Microsoft’s Security Response Center.
But several users said that while Microsoft had raised a valid and long-standing issue, the company itself is to blame for many of the security problems affecting its software.
“The problems are most certainly not caused by full disclosure. They’re caused by bad coding practices,” said Josh Turiel, network services manager at Holyoke Mutual Insurance Co. in Salem, Mass.
In a commentary published on Microsoft’s Web site, Culp lashed out at the “information anarchy” that “allows even relative novices to build highly destructive ‘malware'” using published information about vulnerability exploits.
People who make such information available argue that it can help systems administrators figure out how to protect their systems. But Culp said in an interview that Microsoft’s investigations of worms such as Nimda, Code Red and Sadmind clearly showed that the worms used exploit techniques similar to ones that had been detailed publicly, in some cases employing even the same file names and exploit code.
As a result, it’s better to tell users only which systems are affected, how they’re affected and what can be done to plug the holes, Culp said. For example, Microsoft said its new severity rating system is meant to give users a better idea of the risks posed by different vulnerabilities.
Leaving specific examples of exploit code out of vulnerability information is generally a good idea, Turiel agreed. But, he added, “the danger as I see it is that if someone discovers a flaw and it’s not repaired or disclosed to the public, how do we defend against people who know about it?”
David Lelievre, a project manager at Clinton Township, Mich.-based application service provider Tweddle Information Services Inc., said the notion that “a systems administrator should bury his head in the sand and install patches without knowing what they are going to actually do to the system is ridiculous.” A mere lack of published information is “not going to prevent the next wonder kid from writing a virus,” he added.
With that in mind, Microsoft should focus its energy on fixing the vulnerabilities in its software, not on criticizing those who publicize exploit information, said David Krauthamer, MIS manager at Advanced Fibre Communications Inc., a Petaluma, Calif.-based maker of telecommunications equipment.
However, Daniel McCall, an analyst at Waltham, Mass.-based security consultancy Guardent Inc., said Microsoft does have a point.
“Our view is, don’t tell people how to break a system,” McCall said. A far better approach is to release vulnerability information only after a fix has been developed, he said, adding that Guardent’s policy is to inform vendors and other relevant parties when holes are discovered, then wait until patches are available before publicizing the flaws.
