Re: Complicated Disclosure Scenario

From: Giurgiu Sergiu (sgiurgiuat_private)
Date: Thu Jan 17 2002 - 04:31:30 PST

  • Next message: Ryan Permeh: "Re: Complicated Disclosure Scenario"

    Well ,
    my opinion is that you should make your discovery public. Arguments:
    1. You already informed the vendor.
    2. The vendor seemes to ignore you.
    3. Those who can (afforde) can stop using that product.
    4. Maybe somebody else can discover a way to protect yourself (disable some
    settings, etc.)
    5. As you said, it's inevitable that somebody else would discover the bug
    (maybe he/she did already), and use it to do harm.
    6. Anybody can defend better when they know the vulnerability.
    7........ and maybe more others reasons.
    
    
    
    
    ----- Original Message -----
    From: "Josha Bronson" <dmuzat_private>
    To: <vuln-devat_private>
    Sent: Thursday, January 17, 2002 05:01
    Subject: Complicated Disclosure Scenario
    
    
    > Greetings fellow security folk,
    >
    > I would like to gather some opinions on a not so theoretical disclosure
    > scenario. Please for the sake of focused discussion keep your replies
    > related to the specific scenario that I am proposing and not alternate
    > opinions on disclosure in general.
    >
    > The situation is thus. I have discovered a bug in a major software
    > vendors application. Initially the bug presented itself as a way to
    > crash the application, i.e. a DoS condition. Upon further research I
    > determined that I was able to overwrite some return addresses by
    > formating the overflow in a specific way. As we all know this means that
    > there is the possibility that this could allow code to be executed on
    > the remote system.
    >
    > At this point I contacted the vendor to alert them to the existence of
    > this problem. After exchanging multiple emails, in which I tediously
    > outlined the DoS condition and *potential* exploit situation I was told
    > that they would wait until I determined if code could be exploited
    > before they began creating an advisory or even working on a patch.
    >
    > I informed this vendor, who is by no means short on resources, that I
    > might not be able to successfully make that determination due to
    > constraints on my time (after all I do this for fun) and ability, as
    > this problem exists on an architecture that I have very little
    > experience with.
    >
    > I encouraged the vendor to begin their own investigation. They ignored
    > this, and again stated that they would await my results.
    >
    > This is the problem as it sits. If I reach out to "the community" for
    > additional assistance with researching this bug I might as well just send
    > out an advisory. If I release an advisory the vendor will most likely
    > not have a patch ready, they will feel violated and the user base will
    > be left open to exploitation with no fix. If I do nothing, the problem
    > persists and nothing gets accomplished, and maybe someone with not so
    > good intentions discovers the same bug and uses it to do harm.
    >
    > So, what would you do?
    >
    > --
    > Josha Bronson
    > dmuzat_private
    > AngryPacket Security
    



    This archive was generated by hypermail 2b30 : Thu Jan 17 2002 - 10:52:07 PST