Bug-reporting protocol draws flak

A draft protocol designed to lay down guidelines for a responsible method of reporting security bugs will let software vendors off the hook and stigmatise those who report bugs, say critics.

The draft document, published earlier this month by the Internet Engineering Task Force (IETF), is drawing criticism on several fronts, not least because one of the authors is Scott Culp, manager for Microsoft's security response centre. It was Culp, who in his call for more responsible reporting, decried the information and example code released by some companies and independent security consultants as "information anarchy".

With its draft protocol, the IETF recognises that during the process of disclosure, many vendors, security researchers, and other parties follow a variety of unwritten or informal guidelines for how they interact and share information. "Some parties may be unaware of these guidelines, or they may intentionally ignore them," says the document. "This state of affairs can make it difficult to achieve a satisfactory outcome for everyone who uses or is affected by vulnerability information."

The purpose of the document, says the IETF, is to describe best practices for a responsible disclosure process that involves vulnerability reporters, product vendors or maintainers, third parties, the security community and ultimately customers and users.

But it has drawn criticism for its similarity with Scott Culp's essay on the subject, leading to obvious charges that Microsoft is trying to get off the hook for security vulnerabilities in its products. Noted security guru Georgi Guninski pointed out that the IETF draft is "quite similar to (the) Seattle users' rant."

However, Guninski saves his major criticisms for specific parts of the draft document. In particular, Guninski points to section 3.6.2, which deals with "Reporter Responsibilities". This part of the document states that the reporter should recognise that it may be difficult for a vendor to resolve a vulnerability within 30 days. It gives several examples of where this may be the case: first, when the problem is related to insecure design; second, when the vendor has a diverse set of hardware, operating systems, and/or product versions to support; and third, when the vendor is not skilled in security.

In any of these circumstances, says the document, the reporter should grant time extensions to the vendor "if the vendor is acting in good faith to resolve the vulnerability."

This is dangerous, says Guninski. First, he points out that it would allow vendors to label reporters as "irresponsible" under the terms of the protocol, "while shifting the focus from their buggyware".

As an example, Guninski draws on the recent disclosure of a bug in Microsoft's .Net framework and the Windows operating system by software risk management firm Cigital. Although Cigital said it followed the unwritten rules of responsible disclosure in the company's announcement, some security experts -- including Microsoft -- criticised it as being irresponsible.

"So the vendor denies this is any kind of bug to avoid negative publicity and instead the reporter is labelled irresponsible," said Guninski.

Guninski is also adamant that the software and security communities should encourage disclosure of bugs whether or not they are fully and publicly disclosed. "People with skills will always find bugs, but they may not disclose them," he said.

"I don't find it logical for it to be responsible to sell under-tested and under-quality software, and for it to be irresponsible to disclose a bug," he said. Furthermore, any vendor who sells software with disclaimers that disclaim any liability should not use the word "responsible", according to Guninski.

And in a final sideswipe against Microsoft, he adds: "I personally have disclosed vulnerabilities since 1996 about Oracle, IBM, Microsoft, Netscape, FreeBSD, OpenBSD, Sun and others. Only one of the above has claimed I am irresponsible."

The full IETF draft document can be found here.

Have your say instantly, and see what others have said. Go to the Security forum.

Let the editors know what you think in the Mailroom.