Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Security Vendor Pushes the Limits of Ethical Exploit Reporting

The issue of when—and how—to report new security vulnerabilities raises its ugly head once more, as a security company releases details of a security vulnerability under a dubious 24-hour policy.


advertisement
ome of the grubbiest ethical quandaries in IT never quite get resolved; we make progress, we debate, we set guidelines, but burying such issues for good—with accepted industry policy—is a hard-fought battle. In the meantime, IT practitioners are left in the lurch, trying to keep the menace of uncertainty at bay—and out of the enterprise. And nowhere is this more poignant than in the debate over security exploit reporting. It seems there's a newly disclosed vulnerability in the Microsoft Jet engine, which potentially lets an attacker run malicious code on Windows machines via an infected Access database (.mdb) file. A serious but not highly critical vulnerability, it is nonetheless extremely unfortunate and exacerbated by the fact that Access is widely deployed. What's more unfortunate, however, is the way this information was reported: with no consideration for conventional guidelines and even less consideration for the Microsoft customers, IT personnel, and end users who rely on professional procedures that allow vendors to react responsibly to such discoveries.

On March 30, a company named HexView claims they notified Microsoft via email concerning this flaw. Then, On March 31, they announced the vulnerability by publishing not only the existence of the problem, but all the details as well. You can read HexView's report on the vulnerability here. HexView says the message was relayed to Microsoft via the security@microsoft.com email address on Mar 30 and that the message described the problem and the company's disclosure policy. "A few minutes later we received an automated acknowledgment," said a HexView representative via email (no personally identifying information was given). "No other communications occurred, so we decided to publish the vulnerability on March 31st."

Secunia picked up the report this week, publishing an advisory, which was then picked up by the media. HexView explained that they believe the fear of reported vulnerabilities has been blown out of proportion, hastened by media coverage, writing:

"The buzz around newly discovered vulnerabilities is in most cases the fear of unknown. 'Everyone knows about the hole and we can get hit any minute!' We seem to be entering the era of security paranoia, and it is going to get worse. In the reality, statistic shows just the opposite. It takes months before vendors make patch available for the problem that is not published, and it takes days or even hours to release the same patch when vulnerability details are publicly available."
Conventional Wisdom
So what is the conventional wisdom on when and how to report security vulnerabilities? To find out, DevX talked to Art Manion, Internet Security Analyst for the CERT Coordination Center, which is generally considered to be the organization at the vanguard of the security field. Manion admits that there's "no standard" but explains that CERT/CC would typically wait 45 days after notifying a vendor of a vulnerability—even in the absence of any reply from that vendor—before taking further action, unless the vendor fixes the problem sooner than that.


Indeed, according to this FAQ from CERT/CC, even waiting that long can be insufficient in some cases. CERT/CC says, "We think that 45 days can be a pretty tough deadline for a large organization to meet. Making it shorter won't realistically help the problem. In the absence of evidence of exploitation, gratuitously announcing vulnerabilities may not be in the best interest of public safety." And, in this case, it seems that the vulnerability isn't being exploited—at least not yet. A Microsoft spokesperson said yesterday: "We have not been made aware of any attacks attempting to use the reported vulnerabilities or customer impact at this time, but we are aggressively investigating the public reports. Upon completion of this investigation, Microsoft will take the appropriate action to protect our customers, which may include providing a fix through our monthly release process or an out-of-cycle security update, depending on customer needs."

Microsoft also claims they never received the initial email from HexView on March 30, saying: "The MSRC [Microsoft Security Response Center] has found no record of the finder contacting us with this report. As is a standard MSRC practice, we have outreached to the finder to try and work with them to learn more about the vulnerability and in turn be able to provide customers with the appropriate solution." While that's ultimately a case of 'he said-she said,' it does underscore in a very pronounced way just how unfair HexView's "policy" is, at best, and, at worst, casts a very suspicious light on HexView for seeming to care so very little whether their message was received before rushing the stage to receive credit for their find.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap