Re: Complicated Disclosure Scenario

["Giurgiu Sergiu" <sgiurgiu () terra tim webquote com>]

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" <dmuz () slartibartfast angrypacket com>
To: <vuln-dev () securityfocus com>
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
> dmuz () angrypacket com
> AngryPacket Security