Slashdot Mirror


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."

2 of 114 comments (clear)

  1. Anything new? by Proaxiom · · Score: 5, Insightful
    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.

  2. Required exceptions to non-disclosure pending fix by Zocalo · · Score: 5, Interesting
    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.

    --
    UNIX? They're not even circumcised! Savages!