Home page logo
/

fulldisclosure logo Full Disclosure mailing list archives

Re: To disclose or not to disclose
From: Simon Smith <simon () snosoft com>
Date: Sat, 27 Sep 2008 13:25:03 -0400

Great replies guys!
        
        So lets take this a step further. Lets suppose (again just theory) that
the security company did notify the software vendor and did tell the
vendor where the security issues were in their technology, how to
exploit the issues, provided a proof of concept, and provided clear and
actionable methods for remediation. Lets then say that the software
vendor flat out, point blank, rejected that information and refused to
implement any fixes.

        Just to make this more interesting, lets say that this all happened
over one year ago. Lets also say that the customer who was being tested
by the security company and that is using the vulnerable software has
yet to address the vulnerability in their own network too.

        Is it the ethical duity of the security company to release an advisory?
Does that advisory put the customer at risk? It is clearly unethical to
do nothing and to leave everyone else at risk. How to proceed?

AaRoNg11 wrote:


On Sat, Sep 27, 2008 at 9:13 AM, AaRoNg11 <aarong11 () gmail com
<mailto:aarong11 () gmail com>> wrote:

    Hey, this is a situation that occurs quite frequently within the
    security industry. (Bad) Vendors often refuse to fix bugs or ignore
    them completely until it's too late.

    You should ideally assess each situation on a case by case basis.
    Ideally, the first step should be to notify the vendor giving them
    as much technical information about the bug as possible. You should
    also document the severity of the bug, and give the vendor some
    examples of what a malicious user would be able to do.

    If the vendor has not responded within 5 weeks, the second step
    should be to create an extremely generic public advisory. This
    advisory should explain what the bug allows a malicious user to do,
    while not detailing the technical aspects. By doing this, you are
    letting the industry know that the software is vulnerable, and it
    would be a good idea to start looking at possible alternatives. It
    is at this point that you should set a deadline for your public
    disclosure of the full advisory. This will put pressure on the
    vendor to get a patch out ASAP.

    A few days before the deadline, you should try to release a fix for
    the affected product yourself. Obviously this is only possible with
    open source software. Most people that use mission critical software
    (such as hospitals etc) will be signed up to at least one security
    mailing list. By doing this, you give them a chance to patch the bug
    before the script kiddies get in. While it may be possible to
    recreate the exploit from the patched code, it is unlikely that
    anybody will be able to rush anything out in the few days before the
    public advisory.


    On Sat, Sep 27, 2008 at 4:39 AM, Simon Smith <simon () snosoft com
    <mailto:simon () snosoft com>> wrote:

        Greetings,
               I have a theoretical question of ethics for other security
        professionals that participate in this list. This is not an actual
        situation, but it is a potentially realistic situation that I'm
        interested in exploring and finding an acceptable solution to.

               Supposed a penetration testing company delivers a service
        to a
        customer. That customer uses a technology that was created by a
        third
        party to host a critical component of their infrastructure. The
        penetration testing company identifies several critical flaws in the
        technology and notifies the customer, and the vendor.

               One year passes and the vendor had done nothing to fix
        the issue. The
        customer is still vulnerable and they have done nothing to
        change their
        level of risk and exposure. In fact, lets say that the vendor
        flat out
        refuses to do anything about the issue even though they have been
        notified of the problem. Lets also assume that this issue affects
        thousands of customers in the financial and medical industry and
        puts
        them at dire risk.

               What should the security company do?

        1-) Create a formal advisory, contact the vendor and notify them
        of the
        intent to release the advisory in a period of "n" days? If the
        vendor
        refuses to fix the issue does the security company still release the
        advisory in "n" days? Is that protecting the customer or putting the
        customer at risk? Or does it even change the risk level as their
        risk
        still exists.

        2-) Does the security company collect a list of users of the
        technology
        and notify those users one by one? The process might be very time
        consuming but by doing that the security company might not
        increase the
        risk faced by the users of the technology, will they?

        3-) Does the security company release a low level advisory that
        notifies
        users of the technology to contact the vendor in order to gain
        access to
        the technical details about the issue?

        4-) Does the security company do something else? If so, what is the
        appropriate course of action?

        5-) Does the security company do nothing?

        I'm very interested to hear what people thin the "responsible"
        action
        would be here. It appears that this is a challenge that will at some
        level create risk for the customer. Is it impossible to do this
        without
        creating an unacceptable level of risk?

        Looking forward to real responses (and troll responses too...
        especially
        n3td3v).

        --

        - simon

        ----------------------
        http://www.snosoft.com

        _______________________________________________
        Full-Disclosure - We believe in it.
        Charter: http://lists.grok.org.uk/full-disclosure-charter.html
        Hosted and sponsored by Secunia - http://secunia.com/




    -- 
    Aaron Goulden




-- 
Aaron Goulden


-- 

- simon

----------------------
http://www.snosoft.com

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]