RE: Complicated Disclosure Scenario

[Parity <parity () ghettohackers net>]

        Instead of going public, how about getting a hand from someone who can 
help you fully understand the bug and its ramifications?

        One problem vendors have to deal with is that only about 5% of 
vulnerabilities reported to them are for real -- the rest are pranks, 
misunderstandings, or people with creative definitions of what security ought 
to be.  For every Weld Pond or Rain Forest Puppy who provides detailed, 
verifiable reports, there's another 19 Steve Gibsons telling anyone who'll 
listen that support for raw sockets is a vulnerability.

        I'm sure someone here on vuln-dev would be willing to help you explore 
the technical issue in a private forum.  If it turns out to be for real, then 
you can notify the vendor and expect them to respond to your updated report in 
a timely manner.  (Though I would consider the date of notification to be when 
you serve them the updated report, and not the day when you first contacted 
them with only preliminary data.)

        On the other hand, shame on this vendor for not following up on the 
DoS aspect of this bug.  If you've demonstrated to the vendor that you've got 
a DoS attack attack, then you wouldn't be too out-of-line in publishing it as 
such.

        pty

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