[ISN] Re: Can we afford full disclosure of security holes?

From: InfoSec News (isnat_private)
Date: Mon Aug 13 2001 - 01:11:42 PDT

  • Next message: InfoSec News: "RE: [ISN] The Code Red hype Hall of Shame"

    Forwarded from: "Jay D. Dyson" <jdysonat_private>
    
    This is a note I posted to Bugtraq (which was rejected for unexplained
    reasons since it predated other messages prior to thread closure).
    Anyway, here's my thoughts on Mr. Smith's message.  Take it for what
    it's worth...
    
    
    ---------- Forwarded message ----------
    Date: Fri, 10 Aug 2001 12:58:59 -0700 (PDT)
    From: "Jay D. Dyson" <jdysonat_private>
    To: Bugtraq <bugtraqat_private>
    Subject: Re: Can we afford full disclosure of security holes?
    
    -----BEGIN PGP SIGNED MESSAGE-----
    
    On Fri, 10 Aug 2001, Richard M. Smith wrote:
    
    > This $20 million figure begs the question was it really necessary for
    > eEye Digital Security to release full details of the IIS buffer overflow
    > that made the Code Red I and II worms possible?  I think the answer is
    > clearly no. 
    
    	I would have to disagree.  At issue is *not* the matter of full
    disclosure, but administrative apathy.  Consider the history of automated
    intrusion agents (commonly called "worms").  When Robert Tappan Morris's
    worm hit the 'net, it exploited vulnerabilities that were long-known.  The
    only reason its impact was so great was because admins didn't patch their
    systems against these known vulnerabilities. 
    
    	The same is true for the Code Red worm.  The bug that CR exploited
    was a known issue and there were known patches and workarounds.  Yet the
    worm propagated with very little effort.  Why?  Because far too many
    parties on the 'net don't just practice security-through-obscurity...they
    *rely* on it.
    
    	If you check out lists like Security-Basics here on SecurityFocus,
    you'll find most admins aren't the least bit interested in keeping up with
    current patchlevels for services such as IIS.  Instead, they're more
    interested in altering their "Server:" response string to cloak the fact
    that they're running services that put their systems, their users and
    their data at risk.  Whether fortunately or unfortunately, automated
    intrusion agents totally ignore this obfuscation; they only look for a
    server that answers their request and attack without discretion.
    
    > Wouldn't it have been much better for eEye to give the details of the
    > buffer overflow only to Microsoft?  They could have still issued a
    > security advisory saying that they found a problem in IIS and where to
    > get the Microsoft patch.  I realized that a partial disclosure policy
    > isn't as sexy as a full disclosure policy, but I believe that less
    > revealing eEye advisory would have saved a lot companies a lot of money
    > and grief. 
    
    	This is based on the presumption that *only* eEye Digital Security
    knew about the vulnerability.  While that may or may not be accurate, such
    is not always the case.  In every sector of human endeavor, there always
    exist secrets.  In security circles, these are known as "Zero Day" 
    exploits.  Consider the situation we'd been in if eEye hadn't made the
    full details known to one and all.  Microsoft would have certainly seen no
    rush to put out a fix for a vulnerability that -- for all intents and
    purposes -- wasn't publicly known.  Thus, the patch could have been on the
    backburner for weeks or months to come.  All the while, admins would be
    operating under the false presumption that their services are secure when
    in fact they aren't.  During such time, anyone else who might have
    discovered the vulnerability and wanted to use it to their advantage would
    have had a canonical field day.
    
    	Code Red may have done $20 million in real damages, but the wisdom
    it hopefully imparted to its victims is priceless: when you receive notice
    that a service is vulnerable, take *immediate* steps to mitigate the
    threat.  Period.
    
    > Unlike the eEye advisory, the Microsoft advisory on the IIS security
    > hole shows the right balance.  It gives IIS customers enough information
    > about the buffer overflow without giving a recipe to virus writers of
    > how to exploit it. 
    
    	And Microsoft's advisory doesn't give anyone enough meaningful
    information to test security on their own networks.  Between Microsoft's
    and CERT's highly-sanitized and useless releases and the full disclosure
    of Bugtraq and eEye, I'll invariably choose the latter.
    
    	It's said that a little knowledge is a dangerous thing.  In terms
    of security, only full knowledge can truly mitigate that danger.
    
    - -Jay
    
      (    (                                                         _______
      ))   ))   .-"There's always time for a good cup of coffee."-.   >====<--.
    C|~~|C|~~| (>------ Jay D. Dyson - jdysonat_private ------<) |    = |-'
     `--' `--'  `-Speak softly and carry a thermonuclear warhead.-'  `------'
    
    -----BEGIN PGP SIGNATURE-----
    Version: 2.6.2
    Comment: See http://www.treachery.net/~jdyson/ for current keys.
    
    iQCVAwUBO3Qu9rlDRyqRQ2a9AQH/rAP+OPfoZid2aAM5odvegB3tycwJiCDVCOAx
    SyZ9qdz7iLb/dgpS+F/VrlpFqPhzNtb6gWjmbMdn2E780TA2iuJYm1OdEgc3DQZ4
    fV+Zw0tMT32fEa9Ha1sji/JzfxsI6kdzLKikQsXunu7wf9Vyi2DoxVhKe/HKPDwn
    YRzw25UkG5Y=
    =N58M
    -----END PGP SIGNATURE-----
    
    -
    ISN is currently hosted by Attrition.org
    
    To unsubscribe email majordomoat_private with 'unsubscribe isn' in the BODY
    of the mail.
    



    This archive was generated by hypermail 2b30 : Mon Aug 13 2001 - 03:15:26 PDT