Protocol

From: Aleph One (aleph1at_private)
Date: Fri May 15 1998 - 08:33:37 PDT

  • Next message: Peter van Dijk: "Re: easy DoS in most RPC apps"

    No more than a few weeks ago I posted a message on this subject. Here we
    go again. The recommended protocol when reporting security vulnerabilities
    is:
    
      a) Contact the product's vendor or maintainer and give them a one week
    time to respond. If you don't hear from them post to the list.
    
      b) If you do hear from the vendor give them what you consider appropriate
    time to fix the vulnerability. Obviously this will depend on the
    vulnerability and product and its up to you to make an estimate. If they
    don't fix it in the alloted time post to the list.
    
    When it is advisable to post to the list without contacting the vendor:
    
      a) When you cannot find a contact within the vendor to make a report.
    
      b) When the vendor will not fix the vulnerability.
    
      c) When the product is no longer actively supported.
    
      d) When you believe the vulnerability to be actively exploited and not
    informing the community will cause more harm than good.
    
    All this being said, we rather have people report vulnerabilities to the
    list and not the vendor, whatever their reasons may be, than having them
    keep the information to themselves.
    
      What you don't know _can_ hurt you.
    
    Furthermore, any claims that the person posting the vulnerability is
    liable for any break-ins occurring thereafter are misguided. The only one
    liable is the vendor that put out the buggy software. Anything else is
    damage control by the vendor.
    
    As always when reporting a vulnerability try to be as precise and
    complete as you can. Include model numbers, software revisions, patch
    levels and any other relevant information.
    
    It is also recommended you posts details of the vulnerability even after
    the vendor has released and advisories and/or patches. It is not uncommon
    for vulnerabilities to affect different vendors and/or products. Without
    the details it is difficult to determine who else may be affected.
    
    Aleph One / aleph1at_private
    http://underground.org/
    KeyID 1024/948FD6B5
    Fingerprint EE C9 E8 AA CB AF 09 61  8C 39 EA 47 A8 6A B8 01
    



    This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 13:53:34 PDT