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

Good plan

[cigarky]

Its fair that there has been some disagreement between parties, but the current state allows corporations to brand anyone who discloses information responsibly (after appropriately informing the company of a vunerability) as a blackhat hacker and the corporation as a wounded party. They don't care to mention that their vunerability has resulted in countless manhours of sys admin time to correct the fault, deal with the Nimda/Code Red of the week and apply patches - and the corporations often maintain that they should be allowed to keep the information secret from responsible sys admins well after script kiddies are trading the exploit.

Having a standard document will allow mature parties to avoid being branded crackers if they can follow a published disclosure protocol.

Has anyone tried this angle?

[fist_187]

a day or 2 ago, i started thinking about the DMCA and how those who support it defend it...

usually, they say something like "its to prevent hackers from learning about and exploiting the weaknesses before we have time to fix them" or some similar reason. fair enough, this is valid; i can see how this would be a good thing for preventing software piracy and that sort of thing.

But, when it comes to security and vulnerability to attack, don't I have a right to know? Did I waive that right in an EULA? I'm pretty sure that if this happened with any other kind of product, the government would swoop down and set things right.

Think about it. What if ford had kept the firestone recall under wraps (this "vulnerability" can "crash" the "application" and we don't want hackers/competitiors to exploit it). Yeah- good plan... But I'm the one riding in it! This situation sounds pretty ridiculous when its a "real world" product and not software.

Has anyone else come to this conclusion or know how consumer protection got written out of the DMCA? I'm scratching my head here.

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??

Anything new?

[Proaxiom]

I've been going through it, and I can't seem to find any points on which this differs from the existing full disclosure model that most of the security community already follows.

There are, of course, people who discover vulnerabilities and immediately publish all the details without notifying the vendor, but an RFC is hardly going to stop.

All the same, guidelines are nice. I'm a little skeptical of vendors sticking to the suggestions. To many SHOULDs and MAYs.

To recap, the proposed RFC suggests 7 stages in fixing a vulnerability:
1. Latent flaw. The flaw exists undiscovered.
2. Discovery. Somebody finds the flaw (the 'Reporter').
3. Notification. The Reporter notifies the Vendor.
4. Validation. The vendor verifies the flaw.
5. Resolution. The vendor fixes the flaw.
6. Release. The vendor publishes the flaw.
7. Follow-up. Analysis of the resolution.

What a nice world this would be.

It usually works like that right up until step 5. Here's what really happens:
5. Denial. The vendor denies the flaw really exists, setting his best PR guys on the job.
6. Demonstration. The Reporter creates exploit code to prove to the vendor that not only does it exist, but it is serious and should be fixed.
7. Diversion. The Vendor changes the subject by publicly attacking the Reporter for creating the demonstration, labeling it a "Hacker Tool".
8. Publication. Third party bug tracking systems and security entities make knowledge of the vulnerability widespread to try to scare the Vendor's customers.
9. Fix. The Vendor repairs the vulnerability, while still denying that it has any real significance.
10. Release. The Vendor shuffles the release into a service pack or update, and puts it on his web site.

Re:Anything new?

[jsmyth]

5. Denial. The vendor denies the flaw really exists, setting his best PR guys on the job.
6. Demonstration. The Reporter creates exploit code to prove to the vendor that not only does it exist, but it is serious and should be fixed.

7. Vendor hires a DMCA lawyer to sue the pants off the reporter for exploiting vendor's product
8. Government incarcerates random employee of reporter's organisation who just happens to be in the country at the time.
9. Vendor retracts suit.
10. Government continues to incarcerate random employee, sticking tongue out at the rest of the world in the process.

I give up.

Process is Vendor biased

[edA-qa]

This process seems to be heavily biased towards the vendor and does not seem to offer very much to the community at large. A vendor not interested in exposing vulnerabilities could easily exploit this process.

Simply setting up the recommended email address and generating an auto-reply (or the equivalent with form letters and an assistant) to all reports would acknowledge all claims. This auto-reply could immediately include a request for extension. Delay the auto-reply from 4-7 days, put snapshots of similar keyword searches from the internal knowledgebase, and you have a suitable claim for an extension.

Any disclosure of the flaw before the extension and the vendor can quite happily say that they are following the process and the reporter is not. Meanwhile the vendor themself has no reason, what-so-ever to follow the remaining sections of the process, then can simply allow all periods to lapse and proceed on their own accord. This allows the reporter to be labelled in bad faith, whereas the vendor can artificially appear to act in good faith.

Not following this best practice would furthermore not generate any additional bad publicity for the offending company. Vendors operating in bad faith will already have a negative image. Vendors operating in good faith will have an extra overhead that they may not be able to support if they follow this process.

It additionally appears vendor biased because it does not offer any benefit to the security community, or the user community at large. Prevention of exploits does not appear as a goal of this process. Nor does protection from exploitation of flaws. Unless of course we make the unreasonable assumption that exploits do no appear until over 30 days past the point of /reported/ discovery.

Re:@Stake = Sellout

[Raleel]

Apparently you did not read the draft (which I just did)

(from the draft)
3.6.2 Reporter Responsibilities

1) The Reporter SHOULD recognize that it may be difficult for a
Vendor to resolve a vulnerability within 30 days if (1) the problem
is related to insecure design, (2) the Vendor has a diverse set of
hardware, operating systems, and/or product versions to support, or
(3) the Vendor is not skilled in security.

2) The Reporter SHOULD grant time extensions to the Vendor if the
Vendor is acting in good faith to resolve the vulnerability.

3) If the Vendor is unresponsive or uncooperative, or a dispute
arises, then the Reporter SHOULD work with a Coordinator to identify
the best available resolution for the vulnerability.

and

3.7.1 Vendor Responsibilities

1) The Vendor SHOULD work with the Reporter and involved Coordinators
to arrange a date after which the vulnerability information may be
released.

2) The Vendor MAY ask the Reporter and Coordinator to allow a "Grace
Period" up to 30 days, during which the Reporter and Coordinator do
not release details of the vulnerability that could make it easier
for hackers to create exploit programs.

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.