Re: [Full-Disclosure] Re: Re: <to various comments>EEYE: Microsoft ASN.1 ...

From: Gregory A. Gilliss (ggilliss_at_netpublishing.com)
Date: 02/12/04

  • Next message: Tim Yamin: "[ GLSA 200402-03 ] Monkeyd Denial of Service vulnerability" 
    To: full-disclosure@lists.netsys.com
Date: Thu, 12 Feb 2004 07:59:38 -0800

    I do not work for eEye, although I have a favorable impression of the work
    that I see them produce.

    My personal prejudice is that I subscribe to the school of "security by
    embarrassment". Vendors (and examples of this are legion) fix holes in
    their code much more quickly when the hole is widely publicized, and
    when the exploit code, regardless of its author, is widely available.
    This scenario places the requisite pressure on the vendors to force them
    to commit resources that they would not otherwise commit to discovering
    and repairing the software flaws that they foist upon the community in
    the name of time-to-market and greater profitability.

    I disagree with this perspective. The goal of security research is
    understanding. If we work for someone and have not the time/permission/
    resources/fill-in-the-blank necessary to understand, that is one thing.
    However to withhold the information for the sake of censorship/proxied
    responsibility/corporate bondage is another. If a US company cannot
    release full details of a vulnerability because the lawyers will swoop
    down from on high, what value does the research accomplish? If "polls
    show that admins want the details", all the better. If admins don't have
    the time/permission/etc to delve into the details in order to understand,
    I assert that that is indicative of a deeper problem with our work and
    our culture. Being overwhelmed is not the same as being restrained.

    The Rule of Law exists to proscribe what acts civilization permits
    and prohibits, and the consequences for transgression. FD exists to allow
    people to share, educate, and discuss security vulnerabilities and
    exploits. Reading this post, I suspect that someone is confusing the
    two. Agreed, we are no longer in the period of time when someone can
    trespass on your computer with impunity. However I do not believe that
    the responsibility for enforcing that social edict resides with either
    this list or the vendors or the security researchers.

    I'm not asking, but it appears evident that eEye has a business partner
    agreement with M$ that restricts their ability to release their research
    in a "timely manner". Same thing that happened to securityfocus when
    Symantec bought them. The rules have changed. I acknowledge the situation.
    However I tolerate it; I do not care for it one bit.

    G

    On or about 2004.02.12 00:56:59 +0000, Paul Tinsley (pdt@jackhammer.org) said:

    <<SNIP>>

    > >Question: "Why release all of the details"
    > >
    > This statement is not an accurate paraphrase, I didn't say why release
    > them all. I said why release them all on day 0 of the patch release.
    >
    > >Answer: Polls show this is what administrators what. This is one reason
    > >we do this. Another reason we do this is simple, we use the details
    > >ourselves. We use the details to create signatures for our vulnerability
    > >assessment tool and firewall. Security administrators then download
    > >these signatures and use them to check for patches or to protect systems
    > >which can not yet be patched.
    > >
    > Administrators don't need this crap to fix their boxes, they simply need
    > the exploit vectors, the possible mitigation steps, and the potential
    > severity of the vulnerability. No sysadmin should have time, nor care
    > about the call made to localalloc, the decoder functions it effects,
    > etc... The pieces that are needed to make a threat assessment and
    > develop a mitigation strategy, IMHO, are all in your bulletin, and
    > contained in these sections: Systems Affected, Services Affected,
    > Software Affected, Description, Severity. From that it's pretty obvious
    > how bad this one can be, knowing that we can't make people stop using
    > Outlook in a corporate environment, or stop using Internet Explorer to
    > go to several popular sites, or any of the other numerous 3rd party apps
    > that are affected by this. The strategy is simple, patch, patch, patch.
    >
    > That is something that takes time in a large enterprise where you have
    > to worry about the effects it will have on day to day business. You
    > can't just flip a switch and deploy vendor patches the day they come
    > out, I think we all know that Microsoft patches do have bugs from time
    > to time and knowing how these will affect your "officially supported"
    > corporate applications is important. Reducing the safe margin of time
    > that one has to do that IS a problem in my eyes.

    <<SNIP>> 

    -- 
Gregory A. Gilliss, CISSP                              E-mail: greg@gilliss.com
Computer Security                             WWW: http://www.gilliss.com/greg/
PGP Key fingerprint 2F 0B 70 AE 5F 8E 71 7A 2D 86 52 BA B7 83 D9 B4 14 0E 8C A3
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
  • Next message: Tim Yamin: "[ GLSA 200402-03 ] Monkeyd Denial of Service vulnerability"

    Relevant Pages

    • Re: Its not that simple... [Was: Re: [Full-disclosure] Disney Down?]
      ... PnP is not a show stopper when it comes to patch compatibility testing ... "Successful exploitation of this vulnerability could be leveraged to ... "If it had been International Paper or some company like ... > to take security matters more seriously. ...
      (Full-Disclosure)
    • Re: Download.ject - commentary - LONG
      ... > patch recently released by Microsoft. ... > vulnerability in question, but instead is just a partial workaround. ... > Granted these are known security best practices related to Internet ... > a new default browser to users and hope that it will be safe enough. ...
      (microsoft.public.win2000.security)
    • Re: NT4 patch for MS00-084??
      ... there is no such patch to be found on the technet security ... > "Microsoft has released a patch that eliminates a security ... > vulnerability in Microsoft® Indexing Services for Windows 2000. ...
      (microsoft.public.security)
    • RE: Releasing patches is bad for security
      ... The new patch model for longhorn will not require reboots. ... functionality over security. ... Current patches are getting smaller as with large enterprises bandwidth can ... > MS posted a patch and some 300ish days later the worm hit. ...
      (Incidents)
    • Microsoft Security Bulletin MS01-044
      ... Subject: Microsoft Security Bulletin MS01-044 ... 15 August 2001 Cumulative Patch for IIS ... - A denial of service vulnerability that could enable an attacker ...
      (Bugtraq)