Security Vendor Pushes the Limits of Ethical Exploit Reporting : Page 2

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.

Previous Page