Re: Complicated Disclosure Scenario

["Ryan Permeh" <ryan () eEye com>]

in this situation, pick an established doisclosure policy (rfpolicy, russ
cooper's nt bugtraq disclosure policy, or one of the other hundreds
published), and map your scenario to that.  RFPolicy has had good acceptence
with the community, and is designed to deal with situations like this, so i
lean towards that.

basically, if they refuse to acknowledge the bug, and the bug exists in a
lot of people's installed software, then there is a high potential for it
being exploited in the wild, and it may have already been discovered and
exploited by the blackhat community.  If you know of a work around, even if
it is "firewall x port", post that as well.  Just because you can't exploit
this now for whatever reason doesn't mean that some college kid with nothing
but time can't.  Even if it causes a denial of service, that is a security
related problem and requires immediate attention by the vendor.  If you get
less than this, warn them of your release timetable, and alert them to the
fact that you will be releasing all of your research to the community for
further development.  and stick by this.  you, as the bug discoverer, have
rights in this situation as well.

Good luck.

Signed,
Ryan Permeh
eEye Digital Security Team
http://www.eEye.com/Retina -Network Security Scanner
http://www.eEye.com/Iris -Network Traffic Analyzer
http://www.eEye.com/SecureIIS -Stop Known and Unknown IIS Vulnerabilities

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