Re: [Full-Disclosure] Vulnerability Disclosure Debate

From: Matthew Murphy (mattmurphy_at_kc.rr.com)
Date: 08/08/03

  • Next message: Stephen Clowater: "Fwd: Re: [Full-Disclosure] Re: Full Disclosure Awards"
    To: "Full Disclosure" <full-disclosure@lists.netsys.com>
    Date: Thu, 7 Aug 2003 19:05:34 -0500
    
    

    > Some good points.. HOWEVER, in todays world, we must balance the right
    > of users to know EVERY DETAIL about the exploits that could be used
    > against them, with the fact that the hackers generally ALREADY KNOW
    > these details.

    In some cases (MS03-007, for instance), that is correct. However, in most
    cases, you'll find that this is false. It does hold true that in cases
    where a public advisory was the first aw

    > If a company that manufactures locks does a poor job and
    > a locksmith publishes how to break into the lock, that should be
    > considered a service to all.

    Oh really? I wouldn't be rushing to thank the locksmith, I'd be thinking,
    "Oh shit, how do I keep my house from being broken into?!". This analogy is
    somewhat flawed. You see, with a lock, the primary purpose of it is
    security -- it has no other purpose. Networked applications are an
    inherently insecure technology -- they are built as matters of convenience
    or of other requirements than personal security. In any case, such a
    philosophy leaves the user with a hole exposed and no way to plug it without
    breaking accessibility somewhere.

    Now, if that same locksmith reveals the details of that problem, and offers
    an intermediary fix, then I'd be thankful. If there is a good workaround
    available, this philosophy becomes more feasible. Now, I must also stress
    that the workaround requires a solid *distribution mechanism* that will
    allow most users to know of the vulnerability, so that they can actually
    implement the fix. Unfortunately, the best avenue for this remains with
    vendors, and media. Vendors typically want to wait until they have a code
    fix so that customers don't complain, and unless it's really serious, media
    won't pay attention without a major vendor press blitz, and even with such,
    there is only one vendor that I'm aware of that can do that -- Microsoft
    (and only because of almost complete market dominance). So, without a good
    channel for notification, even the best workaround is quite useless.
    Another problem is that security-specific channels (like this list) are not
    understandable for the common user -- the types that get every mass mailing
    worm under the sun, and that we all hate to work with.

    The only other worthwhile notification channel for the majority of home
    users remains government (usually also accomplished with some media
    influence). In the case of a defective lock, a government ordered recall
    would be likely, as the entire purpose of the lock was violated. My, all
    this talk about picking locks makes me happy to have a deadbolt! :-)

    > After all, how can consumers make good
    > choices without ALL of the information? Yeah, some will misuse the
    > information.. but users have the RIGHT to know how secure (or in the
    > case of Windows insecure) the product they are using is.

    I agree that users have a right to know how secure their systems are.
    However, measures of individual vulnerabilites have historically proven poor
    as tests of actual product or vendor security. Measurements like attack
    surface (potential points of exposure when configured in least secure mode)
    are better indicators.

    > They also have
    > the right to know how DIFFICULT it is/was for an attacker to actually
    > perform the attack (this includes code samples to test the concept
    > themselves if they want - unless of course you expect every user to be a
    > coder). Keep Disclosure FULL DISCLOSURE ... lock picks should be legal
    > both in society and in cyberspace.

    Once again I agree with the idea, but not the method. Releasing exploit
    code for every vulnerability eliminates the notion of difficulty to exploit,
    as every vulnerability is just point-and-click, regardless of how difficult
    it was to actually write the exploit. Unless of course, you expect every
    user to be a coder. If a user truly wishes to be security aware, exploit
    code does not help this goal, as 99% of users cannot understand it enough to
    actually determine the technical details involved. To be security aware
    about a product, users should understand vulnerabilities in general,
    especially previous issues with that product and/or its competitors. By
    looking at the details of such, it is much easier to determine difficulty
    than by blindly rooting your entire subnet.

    _______________________________________________
    Full-Disclosure - We believe in it.
    Charter: http://lists.netsys.com/full-disclosure-charter.html


  • Next message: Stephen Clowater: "Fwd: Re: [Full-Disclosure] Re: Full Disclosure Awards"

    Relevant Pages

    • Administrivia: Response to OIS Draft on "Security Vulnerability and Response Process"
      ... vulnerability or not. ... to see what they can expect, at each Vendor, or for each Coordinator, ... and possibly a lot longer if the Finder doesn't pester ... security of users, critical infrastructures, and the Internet"...and ...
      (NT-Bugtraq)
    • 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)
    • SecurityFocus Microsoft Newsletter #165
      ... Tenable Security ... distribute, manage, and communicate vulnerability and intrusion detection ... Microsoft Internet Explorer MHTML Forced File Execution Vuln... ...
      (Focus-Microsoft)