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 [email protected] 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.

HexView’s Vulnerability Disclosure Policy
According to HexView’s vulnerability disclosure policy, after notifying the vendor, if it receives a human reply from the vendor, it will refrain from publishing details about flaws rated “high” or “critical” (HexView rates this one as “high”) for 30 days. HexView says it received only an automated reply from Microsoft and therefore proceeded to release the details after 24 hours.

Don’t overlook the fact that the date on HexView’s published policy is March 29, 2005. In other words, HexView published the details of this exploit under the rules of a policy they created or altered one day before allegedly notifying Microsoft.

Dates aside, HexView’s policy is by far the most liberal disclosure practice we could find. The next-most disclosure-friendly policy we could find, well-known hacker Rainforest Puppy’s RFPolicy 2.0, suggests that “The MAINTAINER is to be given 5 working days (in respects to the ORIGINATOR [the person or organization reporting the vulnerability]) from the DATE OF CONTACT; should no contact occur by the end of 5 working days, the ORIGINATOR should disclose the ISSUE.”

HexView defended their policy: “Even if there is no confirmation that vendor is working on the patch, we weigh all factors before announcing critical vulnerabilities and we carefully select which details should be included in such disclosures. We ask the media to please stop pouring oil into the fire. The Jet DB vulnerability is not that critical. There are numerous and more serious problems with other document formats, MS Office is just most popular.”

HexView Advisory Quality
HexView doesn’t have a good track record. The company has previously been taken to task for announcing security vulnerabilities before notifying vendors. Last October they announced a RIM Blackberry “buffer overflow” vulnerability with no prior warning whatsoever to the company. At that time, HexView was operating under a different disclosure policy, which made no provision for the vendor to respond ahead of time.

In that case, the original advisory charged that the buffer overflow could let an attacker execute malicious code?a claim later refuted by RIM. HexView’s subsequent retraction says:

“There is no buffer overflow condition. Device reset is triggered by a watchdog timer that times out when a long message is being stored in flash memory. Other issues are being investigated by RIM.”

Watch Your Files
There’s no information yet from Microsoft about the validity of this announcement?and we have no reason to believe it isn’t correct?but one can’t help being left with the feeling that HexView has its own best interests well in mind rather than those of the responsible security researchers, the millions of Windows users whose systems use Jet, and security administrators everywhere?to say nothing of Microsoft itself. Even two weeks is not enough for a vendor like Microsoft to begin to prepare a patch, says Robert Richardson, Editorial Director of the Computer Security Institute. “At a minimum, they’d be asking to wait until the next month,” to give them a chance to get the bug into their patch release schedule. “There’s no way Microsoft could have reacted that fast and kept the stated commitment?to keep people from getting buried in patches every week.”

By not giving Microsoft sufficient time?at least one full monthly security cycle?to address and provide a patch for the vulnerability, HexView has put a huge number of people at least potentially at risk. One can only hope that the publicity they’ll gain by this stunt proves to be less positive than they evidently expect.

In response to our inquiries, HexView provided the following analogy, by way of explanation:

“We notify vendors in advance, and we are open for communications. We do think though that we should let people know about the problem in case vendor does not want to cooperate. Consider this analogy: you open your door one morning and you find a dead body in front of it. What would you do? Call the police. Now imagine that after you dial their number they play “thank you for your call, we’ll get in touch with you if we find it important” recording. What would you do next? Wait for them to appear? For how long? And if they won’t come? Would you push the body out of the way and pretend nothing happened, or call the press?”

I don’t know about you, but I think there’s a world of difference between finding a software vulnerability and finding a dead body on your doorstep. And in today’s security-conscious environment, where all software vendors?including Microsoft?are pilloried by even the implication of ambivalence, the inference that a vendor would not be motivated to cooperate is unsupported. By providing so little time for vendors to respond, one can only assume that HexView has little wish to ever hear a word from any vendor they notify.

While HexView has committed no legal malfeasance, their action is irresponsible. And they make it all the more difficult for the industry to ever put a lid on this issue, which ultimately harms us all.