Vulnerability Development mailing list archives

RE: Complicated Disclosure Scenario


From: NP-GEE-CLOUGH AARON <NP-GEE-CLOUGH_AARON () SUBCONTRACTOR prc com>
Date: Thu, 17 Jan 2002 09:51:35 -0500

I would contact someone like the vuln-help folks at security focus, CERT,
etc.  Not that I'm trying to shill for them, but this seems like an ideal
situation where a respected, independent group (which is what they are
supposed to be) can step in and club the vendor until they get a clue.  If
the vendor still doesn't respond, then I think you should release an
advisory.

Yeah, people are going to be pissed if the vendor doesn't have a fix.  But,
I think contacting a neutral third party (or more than one) in an attempt to
get the vendor to recognize the problem will show that you are being
responsible about the vulnerability.  If the vendor chooses to continue to
ignore the situation, let them face the media.

Aaron

-----Original Message-----
From: Josha Bronson [mailto:dmuz () slartibartfast angrypacket com]
Sent: Wednesday, January 16, 2002 10:01 PM
To: vuln-dev () securityfocus com
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


Current thread: