Administrivia: Response to OIS Draft on "Security Vulnerability and Response Process"

From: Russ (Russ.Cooper_at_RC.ON.CA)
Date: 06/05/03

  • Next message: Eiji James Yoshida: "Microsoft Internet Explorer %USERPROFILE% Folder Disclosure Vulnerability"
    Date:         Thu, 5 Jun 2003 13:42:49 -0400
    To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
    
    

    If you've ever wondered why its so hard for Software companies to write
    secure code, a quick look at the "Security Vulnerability Reporting and
    Response Process" draft from the Organization for Internet Safety;

    http://www.oisafety.org/process.html

    might give you some ideas (don't go for the PDF unless you're prepared
    to wait 10 minutes for each page to be displayed after you scroll.) With
    57 things a "Finder" can/should do, and 89 things a "Vendor" could/might
    do, the attempt by Vendors to overly burden the process with minute
    detail is laughable.

    I attempted to establish the "Responsible Disclosure Forum" first back
    in May of 2001. Within that context, I promoted the adoption of certain
    rules or a code of conduct, but its emphasis was on Vendors as opposed
    to Finders. Finders, as we all know, can do anything they want. Only if
    they feel Vendors are being responsive will the desire to work with them
    increase. I proposed rewards for Finders who upheld the Responsible
    Disclosure creed, and a large select-yet-open peer organization to
    review initial reports. Full details can be seen at;

    http://www.ntbugtraq.com/RDForum.asp

    I'm amazed that something which never got any acceptance by any of the
    players in the RFC attempt, nor this process document, has so many
    similarities to both documents.

    I was never contacted for comments on this latest effort, maybe it was
    because they already knew my opinions and had incorporated them into
    their thinking going into their effort...or maybe they just don't like
    me...;-]

    That said, I thought I would offer up my comments for your perusal.

    The document is intended for companies or professional researchers (of
    which I'll include those academia researchers who's only profit is their
    degree or doctorate). Using some numbers I was once given by Elias Levy
    at SecurityFocus.com, ~51% of vulnerabilities are reported by
    individuals, not companies or professional researchers. The proposal
    offers no incentives to these individuals whatsoever, and therefore
    falls short of meeting the basic needs for any formality to this
    process.

    Its "Primary Purpose" is for Vendors, not consumers, nor the Internet,
    nor the people who discover vulnerabilities outside of corporations paid
    to do this work. Am I the only one to laugh at the irony, the
    presumption, that these Vendors are willing to publish? Not only are
    their products defective; they've sold them far and wide; people have
    come to rely upon them, but now they believe the most effective way at
    minimizing the risks they've placed you at is to encumber people who
    spend their own personal, unrewarded, time with a plethora of procedures
    and protocol for communication.

    It is certainly reasonable for Vendors to expect they will receive some
    notice, and enough details that the reasonably intelligent, and highly
    paid staff at the Vendor will be able to figure out whether there's a
    vulnerability or not.

    It is equally reasonable that anyone who discovers a way for a remote
    attacker to control thousands, if not millions, of Windows boxes
    globally be rewarded for not irresponsibly disclosing such information.
    But instead of rewards, the Vendors propose that unless the report is
    filed properly, the individual may not receive any confirmation, or
    communication.

    Its "Secondary Purpose" suggests its going to "facilitate 3rd party
    efforts to provide supplementary information and protection" and
    "facilitate long-term research into software development techniques and
    processes", but nothing I could see in the draft actually addresses
    either of these points.

    To specifics;

    1.3 Use of this Reference Process

    Its a 37 page process, and yet they expect Finders, Vendors, and
    Coordinators to "clearly note all areas where their process differs from
    this one". Ergo discoverers are going to have to pour through 37 pages
    to see what they can expect, at each Vendor, or for each Coordinator,
    and note what may be very subtle differences in any of the 146 "Process"
    steps. Ridiculous.

    Like RFCs, everyone involved will be able to claim compliance with the
    "Reference Process" because you can do any or none of it. Since there
    are no rights or obligations, it really boils down to whether or not you
    as an individual wish to do this extra work for Vendors for nothing. As
    a Vendor, there's very little you actually have to do in order to try
    and convince your customers you're participating, and the Media will be
    hard pressed to know whether you do or don't.

    1.4 Scope

    Its only for software and firmware, not hardware, networks, etc... Why??
    There's no penalties for not participating, why wouldn't this proposal
    cover all aspects of computing security...or are they working on a
    different one for hardware, networks, etc...??

    1.7 Process Maintenance

    They propose updating the requirements no less than every 2 years, which
    in practice will become 3-4 years if we go based on the software
    industries track-record for providing maintenance releases on a
    schedule. I guess "Internet-time" has been redefined.

    2.1 Participants

    Consumers and Media should be listed as participants too, but I guess
    the Vendors figure Consumers and Media full under their purview.

    2.3 Timeline

    7 days to acknowledge receipt is ridiculous if Vendor has provided "an
    easily discoverable location on their web site" for reporting such
    issues. Worse, if the Vendor doesn't respond, its incumbent upon the
    Finder to send a specially formatted email to the Vendor to "Request for
    Confirmation"...duh...for which the Vendor is given another 3 days to
    respond. So, at a minimum, it could be 7 days just for confirmation,
    more likely 10, and possibly a lot longer if the Finder doesn't pester
    the unresponsive Vendor.

    The timeline should follow the same timeline that the Vendor provides to
    its Premium customers for trouble ticket resolution, and treat the
    Finder as such, otherwise it would be easier for the Finder to report
    the flaw to the Vendor's biggest customer and let that customer pursue
    the fix.

    The 30 days to completion doesn't start until the Vendor acknowledges
    the Finder's Vulnerability Summary Report (VSR). IOWs, it may well be 40
    days (minimum) all of the time. They are, it seems, oblivious to the
    fact that its unresponsiveness and the long time to release that cause
    so many disclosures prior to fix. If a minimum of 40 days from discovery
    to fix is a good minimum to you, please stand up.

    So then there's a 30 day "grace-period" prior to more details being
    published by anyone, except if you're sharing the information with
    "people and organizations that play a critical role in advancing the
    security of users, critical infrastructures, and the Internet"...and
    they are? CNN? NYT? WSJ?

    3. Discovery Phase

    "Vendors finding security vulnerabilities in their own products is
    outside the scope of this document"...why? Is the "security of users,
    critical infrastructures, and the Internet" at less risk when the
    discovery is made internally?

    The Finder is expected to "perform some due diligence prior to
    continuing on through the vulnerability reporting process", determining
    whether the vulnerability is already known (how can they know, it may
    have been discovered internally by the Vendor!), whether there's a fix
    already available (again, how do they know?), and whether the
    vulnerability affects the "default or a reasonable configuration of the
    software". This last one is the best, the Finder is supposed to figure
    out what is reasonable for all of a Vendors customers?? If only we all
    had access to such great marketing demographics.

    3.1.3

    Actually encourages development of proof-of-concept code, great!

    4.1 Contacting the Vendor

    Non-email methods of contacts should be completely discouraged. We all
    love the black hole of a Vendor feedback form on a website, don't we.
    They provide no copy of the information for the Finder and no method of
    verifying whether the report was actually delivered, let alone read.
    Further, there is no way for the Finder to ensure their data is
    unaltered on its way to the security individual or group, nor can they
    be assured it will not be viewed by others en-route.

    4.2.6

    "If the Finder does not receive acknowledgment within seven (7) calendar
    days of sending the RFCR, the Finder may, at its discretion, take the
    steps described in the section titled "Resolving Communications
    Difficulties and Deadlocks"."

    The section referred to as "Resolving Communications Difficulties and
    Deadlocks" is actually titled; "Resolving Conflicts, Deadlocks, and
    Communications Breakdowns", so we start with a communication
    difficulty...;-]

    4.3 Public Notification of VSR

    The Vendor gets the right to notify its customers during the
    Notification phase prior to Investigation by the Vendor, but the Finder
    does not have this right, despite the fact the Finder is supposed to
    have verified their claims? This makes no sense. So much for coordinated
    simultaneous disclosure discussed further on in the document, the Vendor
    may choose to usurp you.

    5. Investigation Phase

    If Vendor is unresponsive, its up to Finder to notify Vendor that it
    will be terminating the communications. IOWs, at the end of it all the
    Vendor has a statement from Finder that they (Finder) is terminating
    communications, rather than Vendor simply being in default.

    5.4.2 Consultations During the Investigation

    GOOD! Finder is not expected to provide additional details about the
    flaw beyond the initial VSR if they choose not to or don't have the time
    to.

    5.5.2 Findings

    Finder has to provide specific step-by-step instructions on how to
    reproduce, but Vendor doesn't have to provide similar step-by-step
    procedures they attempted in their testing.

    5.5.4.2 Disproof

    "Test results showing that the behavior only occurs when the product is
    configured in a way that itself violates normal security practices and
    exposes the system to significant risk."

    This is crap. "Normal security practices" should not be considered a
    valid reason for stating that something is not a security vulnerability.
    Only if the "Normal default configuration/installation" does not expose
    the vulnerability could the Vendor argue lowering the priority. If it is
    possible for the product to be used in the fashion the Finder describes,
    it should be considered a security vulnerability. Priority is the way to
    address this, not "Disproof".

    "Analysis of the attack scenario, showing that the behavior could not be
    realistically exploited or could only be exploited in cases where the
    system was already insecure by necessity."

    Again, same as above. If a consumer chooses to use a machine insecurely,
    they do so with either no knowledge they are using it insecurely (e.g.
    typical home user), or, because they have weighed the risks associated
    with the insecure installation. If a new vulnerability occurs only when
    the system is insecurely used, this cannot be "Disproof" that the
    vulnerability is, in fact, not a vulnerability. It is another data point
    for the consumer to consider. Ergo, its still a vulnerability.

    If a vulnerability relies upon the use of another vulnerability in order
    to function, then that should be grounds for "Disproof". This has not
    been listed.

    6.1 Diagnosis

    Finder was expected to determine if a fix already exists, but Vendor is
    tasked with doing so in 6.1.1 and 6.1.2 anyway.

    6.2 Remedy Types

    "For instance, if a maintenance update were due to be released
    imminently, it might be appropriate to use it as the vehicle for fixing
    a particular security vulnerability. In contrast, if the maintenance
    update were many months from release, the same vulnerability might
    warrant a patch or a configuration change."

    This is crap. Service Packs or Maintenance Releases should never be used
    as the only vehicle for security fixes. Security fixes should always be
    made available as "patches" so that anyone using an affected product is
    not compelled to install a service pack or maintenance release as the
    only method of obtaining a security fix. Testing of security fixes
    should be left to the security issue only, not combined with 10's or
    100's of other issues which would also need to be tested prior to
    applying the security fix.

    6.4 Internationalization

    "If the affected products are available in multiple languages, the
    Vendor shall ensure that a remedy is delivered for each of the supported
    languages."

    This should either be simultaneously, or, in priority order where the
    Vendor states in advance the priority it places on each language
    version.

    6.6.4 Synchronization

    "If the Vendor chooses to release its remedy independently, it shall
    limit the information it publishes about the vulnerability, in order to
    avoid putting at risk other users who may not have a remedy available."

    How do you do this in open source efforts where all it takes is a DIFF
    to determine the changes?

    6.7 Timeframe

    30 days should start from the day the Finder submits the report to the
    Vendor, not the day the Vendor acknowledges receipt of the VSR. Why make
    the process so Vendor biased?...oh, yeah, right, you're all Vendors!!

    6.7.4

    "The Vendor may, at its discretion, publish a workaround as an interim
    remedy. However, the Vendor shall do so only if, in its judgment, the
    workaround is sufficiently non-disruptive that it is likely to be
    adopted by a significant percentage of users and publishing the
    workaround will not disclose details that would enable the vulnerability
    to be exploited."

    If the workaround has been proposed by the Finder, and not solely
    developed by the Vendor, then the Vendor should give the Finder the
    right to first publish the workaround together with some reasonable
    information about the vulnerability. Credit should not cede to the
    Vendor by virtue of the fact they cannot effect a patch in a reasonable
    amount of time.

    7.3.15 Security Advisory

    Why is it the responsibility of the Finder to include references to the
    Vendors information, but not vice-versa? Shouldn't the Vendor be
    compelled equally?

    8. Conflict Resolution and Third Parties

    Well, let's just say this whole section is somewhat laughable.

    Cheers,
    Russ - Surgeon General of TruSecure Corporation/NTBugtraq Editor

    oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
    Delivery co-sponsored by TruSecure
    oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
    FREE 14-DAY TRIAL of New Threat & Vulnerability Notification Service

    TruSecure's new IntelliShield(tm) web-based threat and vulnerability
    service isn't your typical alert service. Supported by TruSecure's vast
    intelligence resources - including the ICSA Labs - IntelliShield's early
    warning, analysis, decision support, and threat management tools provide
    organizations with unmatched intelligence to better protect critical
    information assets. Experience it for yourself - just click below to begin
    your FREE, NO OBLIGATION 14-day trial today!

    http://www.trusecure.com/offer/s0074/

    oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo


  • Next message: Eiji James Yoshida: "Microsoft Internet Explorer %USERPROFILE% Folder Disclosure Vulnerability"

    Relevant Pages

    • Re: [Full-Disclosure] Vulnerability Disclosure Debate
      ... You see, with a lock, the primary purpose of it is ... or of other requirements than personal security. ... there is only one vendor that I'm aware of that can do that -- Microsoft ... code for every vulnerability eliminates the notion of difficulty to exploit, ...
      (Full-Disclosure)
    • Re: [Full-Disclosure] Vulnerability Disclosure Debate
      ... You see, with a lock, the primary purpose of it is ... or of other requirements than personal security. ... there is only one vendor that I'm aware of that can do that -- Microsoft ... code for every vulnerability eliminates the notion of difficulty to exploit, ...
      (Full-Disclosure)
    • Re: Using 0days as part of pen-test?
      ... the client the option to determine how the vendor gets notified. ... vulnerability information you discover during ... The legal issue isn't the disclosure process, you can act as "legal entity" ... security threats until the vendor release a patch. ...
      (Pen-Test)
    • Re: Call to arms - INFORMATION ANARCHY
      ... Its one thing to prove to a Vendor they have a problem in their code. ... and its not resolved by keeping "Full Disclosure" alive. ... > the Vendor for a vulnerability without accepting responsibility for your ... > feed the feature versus security mentality of many Vendors. ...
      (NT-Bugtraq)
    • [Full-disclosure] Survey: "MIME/Content-Type-Sniffing" Issues in Image Uploads in Forum
      ... opening XSS vulnerabilities in software that allows uploads. ... IN a survey, we found myBB, fluxBB, phorum, SMF and WBB to be vulnerable to ... Vendor Reaction ... leading to a cross-site-scripting vulnerability. ...
      (Full-Disclosure)