Internet Draft on Vulnerability Disclosures

Cowboy71 writes: "An interesting posting on Bugtraq by Stephen Christie announcing the release for comment of an internet-draft "Responsible Disclosure Process" document, prepared by himself and Chris Wysopal of @stake. You can view the full paper at the IETF site."

Comments

Alan Cox / DMCA / Open Source "vendors"

[jsmyth]

OK, I've made an attempt to read the document critically. It reminded me of some of its more obvious failings though:

• Not all "vendors" can be bound by the obligations of either fixing a "flaw" or explaining why the flaw can't be fixed
• In open source projects, the documentation on "flaws" is often included in the TODO file, which counteracts a large amount of what this document is trying to acheive
• We still have the open sore of the DMCA to worry about, regarding the release of information that could be used to exploit or reverse engineer communications or data, e.g. Alan Cox's public refusal to document some of the kernel security stuff

I have to admit that it's a good general solution for presentation to and ratification by the Microsofts of this world - companies for whom marketing departments have more control over release dates than systems engineering or test departments...

...but these are the very companies that are LEAST likely to pay attention to the words of the technological minority, in favour of placating the fickle majority. Anyone else see a problem here??

The document isn't as bad as you might expect

[phr2]

It describes recommended practices for dealing with discovery of security vulnerabilities. It uses standard IETF terminology ("x SHOULD y, z MUST w") to describes actions that should be taken by five entities:

• Vendor: the producer of software in which vulnerabilities are discovered (e.g. Microsoft)
• Reporter: someone who finds a security hole (typically someone in the "security community")
• Coordinator: someone who mediates between Reporters and Vendors
• Customer: end-user of vendor products
• Security Community: the usual researchers, sysadmins, etc. who are trying to improve overall information technology security (it doesn't say whose security).

The first thing I notice is that while there are several places where it says the vendor MUST do this or that (e.g. the vendor MUST respond to vulnerability reports within 7 days), and several things the reporter SHOULD do (the reporter SHOULD provide Vendor with all known details of the issue), there's nothing the reporter MUST do. So it's not an attempt to impose mandatory policies on reporters through a standards process.

The recommendations make a reasonable attempt to protect vendors and customers (i.e. it doesn't go for the zealous instant-full-disclosure approach) without allowing reports to go ignored for too long. It basically says the vendor should get 7 days to initially respond to the report, then 30 days to fix the problem, and then can request a 30 day grace period to get the fix out to customers before the reporter releases details to the public . If the reporter goes along with this, the vendor must credit the reporter in its own public announcement of the fix.

It's kind of weird, seeing an internet draft using protocol-like terminology to describe how people and companies (rather than computers) are supposed to interact with one another. I hope this isn't supposed to be an RFC, or else that this kind of thing is normal for the IETF (I haven't read that many IETF docs). I've never seen a thing like this and it seems to turn the IETF into an even more political body than it already is. I thought the IETF was supposed to make recommendations about bits and packets, not people and companies.

Anyway, I can take issue with some of the points in the document, but at first glance there's nothing in it that I'd call outrageous. It seems like a genuine effort to find a good intermediate policy between instant full disclosure (and instant widespread exploits) and leaving stuff secret forever (letting exploits spread without the public knowing). Whether that policy is the optimal one is of course a matter of opinion and reasonable people can differ on it.

The document's authors came from several different camps (two names I recognize are Bruce Schneier's co-author Adam Shostack (presumably on the full disclosure side), and Microsoft's Scott Culp representing the Evil Empire) and it looks like they managed to arrive at a consensus. I guess that's a good sign and I hope Bruce and/or Adam will publish their own opinions of the draft soon.

What about the role of the public?

[pongo000]

This document seems to downplay the role of public disclosure, and instead inserts the coordinators as the middlemen between reporters and vendors. This is fine for Bugtraq, CERT, and all the other so-called "coordinators," but where does that leave the public? Several times, the document addresses public disclosure, but only in the vein that vendors can choose to withhold recognition or other feedback if a reporter chooses to go public with the information.

I think this document is a big win for the coordinators, but a big loser for the public.

Re:@Stake = Sellout

[flacco]

I feel that this gives the companies no motivation to fix the hole.

It also denies admins the opportunity to at least shut down or wall off the affected service until a real fix is available.

Required exceptions to non-disclosure pending fix

[Zocalo]

I'm all for vendors of software (any vendor, be it Microsoft about the latest IE exploit or ISC about a hole in BIND) to keep a show stopper under their hat while they try and fix it. Provided that there is no evidence that the Blackhat crowd knows about the problem, but there needs to be constraints - 30 days seems about right. This *has* to become null and void as soon as the problem is exploited though; at least that way the people who care about security can take steps to prevent abuse.

I've seen a site well and truly compromised because frickin' Microsoft sat on a bug long after the Blackhat's had an exploit. It only took two days before their entire DMZ was rooted and credit card details stolen, and the stupid thing was, if the site had known that there was a problem they could have worked around it and avoid the legal mess they got into and are still in.

The only saving grace is that this probably won't happen to them again; they are now an ex-customer of Microsoft's and running Apache instead. True, Apache has its own problems, but at least they give you a chance to prevent any issues arising if you care to do so.

PS. Can I interest anyone in 40 used copies of NT Server? Thought not.

Re:The draft doesn't cover sniffing in public

[MikeBabcock]

One might want to push for a seperation between responsible disclosure and responsible discovery.

For Microsoft, if you release any information during discovery you're probably labelled as malicious even if the thoughts are hypothetical or hunches.

However, its necessary to allow people to work together on the Internet in some form or else we can't benefit from each other's eyes ...