Hey, If I was you (and this is just me...) Forward your vuln-dev letter to them, informing them of your dilemma; they may read it as a threat - but it is in fact the reality of things. Personally, if a company chooses to ignore a problem rather than fixing it, then they display an immaturity that must be corrected. This correction may hurt them and their customers, perhaps financially, but the next time someone says "Hey I found XXX in application YYY," they sure as hell are going to pay more attention to it. Who says growing up is easy. Now if you don't report this problem, someone else could find an exploit (if they haven't already) and *not* report it all and start exploiting machines anyways. The customer still loses and the company must deal with the problem after the fact - much worse than before the fact. The company may not like the fact that their product poses a security vulnerability, perhaps this is the first time this situation has arisen; however, any mature company expecting to do business, especially with networked applications, will readily treat these situations with the priority they deserve. I say give them one last chance or else post the advisory; furthermore, (while I'm thinking of it) perhaps you are speaking to the wrong person. Ideally you shouldn't have to do this, but try involving someone else if possible either by e-mail or phone. Anyways that's my 2 cents. Good Luck. Nick ----- Original Message ----- From: "Josha Bronson" <dmuzat_private> To: <vuln-devat_private> Sent: Wednesday, January 16, 2002 21: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 - 11:08:08 PST