Re: [HERT] Advisory #002 Buffer overflow in lsof

From: Fred W. Noltie Jr. (criterion-consultingat_private)
Date: Fri Feb 19 1999 - 13:25:58 PST

  • Next message: Sitzkrieg Redundus: "Frontpage extensions under Apache 1.3.4"

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1
    
    
    
    # -----Original Message-----
    # From: Bugtraq List [mailto:BUGTRAQat_private]On Behalf Of
    # routeat_private
    # Sent: Thursday, February 18, 1999 6:46 PM
    # To: BUGTRAQat_private
    # Subject: Re: [HERT] Advisory #002 Buffer overflow in lsof
    #
    #
    # [Gene Spafford wrote]
    # |
    # | People who publish bugs/exploits that are not being actively
    exploited
    # | *before* giving the vendor a chance to fix the flaws are clearly
    # | grandstanding.  They're part of the problem -- not the solution.
    # |
    #
    #     Who is to say the vulnerability in question was NOT being
    exploited
    #     prior to release?  Odds are it was.  Bugtraq is a full-diclosure
    list.
    #     The `problem` as you succinctly put it is in *non-disclosure*.
    While
    #     it is still questionable whether or not the original posters
    # found the bug
    #     themselves (the advisory lacked any technical detail) calling
    # them part of
    #     the problem is a misfire of your disdain (attacking them on
    # the content
    #     of the advisory --or lack thereof-- is a much better call).
    # The problem,
    #     in this case, would be the malevolent individual(s) breaking
    into your
    #     machine exploiting this bug (before or after it was disclosed).
    #
    #     Don't shoot the messenger.
    
    
    I have to disagree with this. The "messenger" _fails_ if he announces
    the problem to the crackers of the world before giving the vendor a
    chance to prepare a fix. The "messenger" has then shown that he is
    less interested in getting security problems solved than he is in
    revealing them. I don't think this says much about our "messenger"'s
    goodwill.
    
    We may not know if a hole was being exploited before an announcement
    of it, but we certainly know that crackers will have much more success
    with it if the vendor isn't given a chance to fix it first.
    
    Of course the bad code is the real problem, but failing to act in the
    best interest of the _users_ (you know, the folks who suffer when a
    hole is announced without giving a vendor a chance to fix it) is a
    problem too.
    
    Giving the vendor an opportunity to fix a problem before announcing it
    is _not_ in conflict with the idea of full disclosure.
    
    I'm not saying you have to wait 6 months for action by a vendor, but
    failing to give them a chance is hardly The Right Thing To Do.
    -----BEGIN PGP SIGNATURE-----
    Version: PGPfreeware 6.0 for non-commercial use <http://www.pgp.com>
    
    iQA/AwUBNs3W4D6xU7QBzFqYEQJTlQCbB5JVyEHE5/lEAPP0FUsvTjiT9wkAn2sb
    tSPuikaFQBjQtmmWbAUxCAM0
    =wK/j
    -----END PGP SIGNATURE-----
    



    This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:36:37 PDT