Re: Vendor notification

From: Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] (sbradcpa_at_pacbell.net)
Date: 03/31/05

  • Next message: Barrie Dempster: "Re: Vendor notification"
    Date: Thu, 31 Mar 2005 07:07:34 -0800
    To: Barrie Dempster <barrie@reboot-robot.net>
    
    

    Actually that's my point...they DID want to know that was in the wild.
    As of Friday there were no reports of 05-002 exploits.

    They wanted to see samples of it because at this time the 98 version of
    the patch is having issues. It helps guide the message 'at this time we
    have/have not seen expoits...blah blah"

    I'm saying that if it's an brand new exploit in the wild that there
    should be notification.....like you said.. "have you seen this?" If no
    one says yes, you contact and make sure the vendor is aware.

    Susan

    Barrie Dempster wrote:

    > Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] wrote:
    > <snip>
    >
    >> I'm talking about informing about 'bad stuff in the wild' to help the
    >> vendor know that we are all protected for this stuff.
    >>
    > <snip>
    >
    >
    > If every such incident was reported to the vendor they would be flooded
    > with absolute garbage all day. How many times do we see "is this a new
    > virus?" and other such questions where the poster hasn't done any basic
    > research or verification at all.
    >
    > I think it's important to ask "do you see this too?" on the appropriate
    > forum, then when you have some verification and discussion you can pass
    > the info on to the vendor if it seems prudent. However most vendors are
    > reading the appropriate forums for thier products and become aware very
    > quickly of any possible issues. When it comes to discussing and
    > disclosing any new security problems, the most important people in the
    > equation are the *users* not the vendors. I agree though that in many
    > cases you would want direct vendor notification, but unless it's
    > something they can fix directly - ie.. patchable - then let the users
    > know first, so that they can setup IDS/IPS rules, configure firewalls or
    > monitor for traffic patterns.
    >
    > Your example was an exploit existing for an already determined
    > vulnerability, in this case I don't think the vendor needs to care about
    > it at all, the presence or lack of an exploit should have no bearing on
    > their time to patch release. If it's a security vulnerability then the
    > patch should be released as soon as reasonably possible. If the patch is
    > already released and the exploit appears, then the vendor doesn't have
    > to know or care, the user however might want to monitor this for their
    > own research/defense.
    >
    > Basically this boils down to....
    > Find it, discuss it with peers, if the vendor can fix it notify them.
    >
    >

    -- 
    An open letter to the Security Community:: 
    http://msmvps.com/bradley/archive/2004/12/12/23540.aspx
    

  • Next message: Barrie Dempster: "Re: Vendor notification"

    Relevant Pages

    • Re: How can I get my resources back?
      ... >Wild guess, is that said software has a memory leak. ... >fix the problem. ... except contact the software vendor. ...
      (microsoft.public.win2000.general)
    • RE: [Full-Disclosure] Whos to blame for malicious code?
      ... I don't blame you. ... > months after the patch is released? ... Shouldn't a vendor always assume the worst in users? ... This debate has never been about Open Source. ...
      (Full-Disclosure)
    • [Full-Disclosure] Re: its all about timing
      ... What are the penalties now for not abiding by this guideline, or any other guideline that might be out there. ... Are you expecting either party to have been even more aware of some guideline or is this again, the benchmark by which the vendor will have recourse in the future? ... Based on an informal study I've done of about 350 researcher reports ... approximately 50% of the vulnerabilities were ...
      (Full-Disclosure)
    • Re: [PATCH] kexec: force x86_64 arches to boot kdump kernels on boot cpu
      ... My feel is that if it is for legacy interrupts only it should not be a problem. ... I can reroll the patch for this. ... device from vendor AMD, since its possible that more than just nvidia chipsets ... int num, slot, func; ...
      (Linux-Kernel)
    • Re: [PATCH] kexec: force x86_64 arches to boot kdump kernels on boot cpu
      ... My feel is that if it is for legacy interrupts only it should not be a problem. ... I can reroll the patch for this. ... device from vendor AMD, since its possible that more than just nvidia chipsets ... int num, slot, func; ...
      (Linux-Kernel)