Slashdot Mirror
Why Responsible Vulnerability Disclosure Is Painful and Inefficient
A recent rant up at Attrition.org highlights problems with the responsible disclosure of security issues. While some vendors are happy to do their own research and patch reported problems, others drag their feet and make unreasonable demands on a researcher's time and effort, making anonymous public disclosure an ever-more-tempting option. Quoting:
"After a couple hours of poking, I found a huge unauthenticated confidentiality hole. Once the euphoria wore off, I realized I had a big problem on my hands. I had to tell my employer's app owners and we had to assess risk and make a decision on what to do about it. After some quick meetings with stakeholders, we decided to severely limit access to the thing while we worked with the vendor. The vendor refused to acknowledge it was a security issue. Odd, considering most everyone who sees the issue unmistakably agrees that it is not acceptable. Now I'm forced to play hardball, yet nobody wants to fully-disclose and destroy relations with this vendor, whose software is somewhat relied on. Meanwhile, I know there are hundreds of institutions, small and large, using this software who have no idea that it has flawed security and who would probably not find the risk acceptable. What can I do? Nothing. Oh well, sucks to be them. ... I've had a vendor tell me to put a webapp firewall in front of their software. Did they offer to pay for it? No. That would be like Toyota telling its customers to buy ejector seats (unsubsidized ejector seats, that is) to resolve the accelerator problem in their vehicles. I've had other vendors demand I spend time helping them understand the issue, basically consulting for free for them. Have you ever knocked on a neighbor's door to tell them they left their headlights on? Did they then require you to cook them dinner? Exactly..."
that there is an exploit that allows a user to bump their post up to first.
What can you morally do otherwise but blow the whistle?
If you keep playing ball with these people, they will continue to act in the fashion that they do. Nothing will change. They are basically getting away with it.
Give them some pain now and let this be a lesson both to them and to others.
Digital Equipment Corporation (DEC) used to thoroughly investigate all bugs in their operating systems like RSX. Microsoft wanted you to pay them so much per hour to review suspected bugs. Needless to say, DEC got our full cooperation and we didn't bother reporting anything to Microsoft.
FTA:
I've even been accused of being a spy for a company's competition (true... ask Jericho)...
ME: "Hi, you left your headlights on."
NEIGHBOR: "WHO SENT YOU? DID MY EX-WIFE SEND YOU? ARE YOU SLEEPING WITH HER?"
WTF? Seriously?
---
Compare how companies badly deal with vuln disclosure compared to how game companies deal with cheats and exploits. Well, MOST game companies...
To the net. Current dominant dog eat dog capitalist corporate culture makes corporations suppress and hush hush stuff rather than sparing the effort to fix.
Read radical news here
Leak a working exploit anonymously. If a vendor isn't concerned with the security of their users, let them pay the price.
Use hushmail and full disclosure mailinglist to report stuff like this.
There's no sense wasting time, do it anonymously, use tor.
Also while you do it, be sure to post personal information about other full disclosure users so that your email is removed from the official archives.
None of those problems listed seem to be with responsible disclosure. It's your job to responsibly disclose. And you should protect their secret for a while. After that, it's not really your problem if they won't or can't act.
I agree there are also issues here with relying on code that you now know has security issues. But those aren't anything to do with responsible disclosure either. If you posted it to the internet you'd still have issues relying on them. Same as if you didn't tell anyone.
Look at it this way, when you tell a vendor what's wrong and try to help them fix it, you're really doing it to help yourself. Your doing it because you believe it will be less work than changing your entire system to not rely on their code.
As an aside, I don't get a big rush when I find a problem in someone else's code. Maybe I'm just old and jaded now, but I'm just trying to get everything to work well, finding that someone else didn't do their job doesn't usually make my situation any better (as you indicate here), so I don't relish it.
http://lkml.org/lkml/2005/8/20/95
IMO, RD is supposed to entail a good-faith effort to notify the vendor and delay public disclosure for a reasonable amount of time (i.e. not dragging their feet) while they push a patch. If you notify the vendor, preferably including a test case, and they refuse to acknowledge that it is a security issue or suggest ridiculous fixes, that's the end of your RD duties. Ethically speaking, you are in the clear. RD requires you to give them a chance to fix the problem before publicizing it, nothing more.
Now, vendor/rube relations are another matter entirely that are distinct from your duty of responsible disclosure. I don't envy being in the situation where you fear their wrath for disclosure but want to do the right thing.
No. That would be like Toyota telling its customers to buy ejector seats (unsubsidized ejector seats, that is) to resolve the accelerator problem in their vehicles.
Where can I sign the petition to make that happen?? O_O
Qxe4
Or perhaps this is some kind of steganographic secret message you are passing onto one of your field agents?
Your response has nothing at all to do with the situation here.
http://lkml.org/lkml/2005/8/20/95
"I've had other vendors demand I spend time helping them understand the issue, basically consulting for free for them. Have you ever knocked on a neighbor's door to tell them they left their headlights on? Did they then require you to cook them dinner? Exactly..."
You say it happens, they can't reproduce it. Thus, you have to help them understand what it is you're doing. It's not unusual for people to think they've found a bug when they in fact have not.
I'm betting this is software being used in an educational or other not-for-profit environment. If so, one thing you have going for you is that employees in that sector actually talk to people from other institutions. If disclosing your work-around wouldn't just give away the entire problem, I'd actually publish what you did to protect the application. That way, your peers can decide if they want to do it and get a head start. It puts the vendor on notice that someone is going to notice this problem eventually.
If your workaround gives away the entire problem, that's more difficult. Assuming education / not-for-profit, I'd start by talking (verbally) to peers at schools using the application, and see if you can get some traction that way. A group of pissed-off customers might be more effective. Your CIO may be participating in regional or national organizations, and may be able to talk to his or her peers about the issue as well.
If you just release it on your own in an "in-your-face" way without your bosses signing on, they could decide to take it out on you if the vendor gets pissed or tries to go after you for violating some gag clause in the licensing agreement (some have them) or damaging their business. They shouldn't, but I can think of a couple of really stupid, obnoxious vendors that might.
RMS, SAS whatever vendor your working with understand all these programs are filled to the brim with security holes that never go mentioned or patched. EVER. and never will.
As a company your only method security is to 100% limit who has access to 3'rd party vendor programs that contain your data.
Just pretend (its not really pretending is it?) that you are sharing admin user access to every single user of your system and work from there...
Send you information to the press and ask for anonymity. Watch them jump to solve your problem. Try dgoodin@theregister.com.
US CERT, or your local version. They can wield the clue-bat on your behalf.
Unfortunately, the vendor could take it out on the company.
"Oh, our software maintenance fees have increased by 100% (for you only)"
No, since their company was so dependent on Vendors software, they couldn't realistically do that without paying the consequences later.
Two suggestions:
1/ find some kind of fix, then post the exploit anonymously
2/ report the bug to a third party who will then approach the vendor with a "fix in x days or else we post to the world" proposal. This way, the original party can avoid the potential backlash from Vendor
The vendor refused to acknowledge it was a security issue.
Then it's either a feature or a regular old non-security-related bug, and I don't see the problem with announcing it to everybody. Right?
-- 77IM
Student: Is it true that the foundation of the universe is paradox?
Master: Well, yes and no.
If the vendor's software is defective and fails to acknowledge (and thus fix) the vulnerability, then sue them. The legal system is not just for scumbags who try to get rich through frivolous lawsuits. It's actually meant to help people in your situation. Discovery may even give you an opportunity to warn other users of the software without breaking the law yourself.
Sue them, take them to court where bad publicity, will scare the hell out them into settling.
As long as they view it as a technical issue, they are not interested. If they view it as a sales/marketing nightmare they will come to the table in a hurry. As for further cooperation, they will suck it up because other customers will see how they react as to how they will treat the company.
Like spousal abuse, as long as a bad working relationship can be hidden they will get away with it other individuals/companies. They only way to address the issue is to make their dirty laundry public.
I had this kind of problem about 15 years ago. It was a real pain. My problem was that I wasn't able to publish my findings as the vendor made pretty clear he'd sue me over that. So I reviewed my requirements on software and found a solution I haven't heard of before - Open Source. Since then I use Open Source and though it has some minor drawbacks I don't regret this step.
cb
The shareholder meeting. Simply note that you reported bug # XXXX some months ago, and it has not been acted on. You wouldn't mention it except that it's a security vulnerability that, if disclosed, would tank the share price for the company. So in that light, when will this vulnerability be addressed? Let everyone else take it from there.
-- Two men say they're Jesus. One of them must be wrong. - Dire Straits
If the vendor does not respond...
1) Do not install update, notify all that it does not pass the QA requirements. (Think SOX)
2) Send vendor a bill for services rendered.
3) Get on vendor's forum and post the issue.
4) File a breach of contract suit with the vendor.
5) Find new vendor.
And WHY do not have good firewall installed first? That is your responsibility.
If your company sold them security software with a bug, your company should first fix the bug and then give them a patch for it (free of charge).
Not tell them that it's bugged and ask them to pay you to fix it. If they don't want to accept the patched version, that's their problem, but most of your other customers will.
And we all know what it really is.
Protect your system as good as you can, firewalls, backups, whatever, or just rely on your own obscurity, and publish!
Act surprised, act I-told-you-so, be outraged with whatever happens, and then - in few days - install a patch.
http://opencm3.net, http://www.nongnu.org/gm2/
Frankly the web app firewall idea is the most appropriate solution to this entire category of problem for your organization. You should want one, and this is just one more datapoint as to why.
Secondly, if they won't fix the problem (and I don't mean won't do it quickly, I mean won't do it at all) then I'm sure someone else will discover it and anonymously disclose it. ...Cough... Right? ...Cough...
At this point, I wouldn't do anything. If this security vulnerability becomes public from an anonymous source, the vendor will blame you. That is the issue with disclosing it to the vendor, once you have done so, your choices are bend to their will if they won't play ball, or ruin the relationship. I would recommend working towards getting rid of the vendor, as they are leaving your system insecure and not willing to fix the issue. Until that point, suck it up.
If they think this is not a security issue, then nothing stops you into going public.
This is how responsible vulnerability disclosure rules are, and will be.
...anonymously.
It's only a matter of time before the black hats find it, so by publicizing it and forcing it in the vendor's face they'll see it for what it is.
I don't know what kind of terms are written in your contract with these people (or how big your company is compared to the software company), but maybe your company can sue them for failing to properly maintain their software. Right now, find other companies that use this software and tell their administrators about the vulnerability and let the pressure build on the software company. Give them a little more time to either get their shit together or blow you off and then threaten lawsuit. It would be irresponsible of you for the sake of your own security to publicly disclose the vulnerability, so you should be doing all you possibly can to not have to do that.
Simple answer:
Responsible Disclosure should be limited to vendors that publicly pledge (or, preferably, contractually agree to via their licensing terms) to Responsibly Fix issues that are disclosed to them. If a company doesn't abide by their own Responsibly Fix policy, it should be disclosed so that others realize that it's null and void.
Help save the critically endangered Blue Iguana
I like the analogy with the neighbour's headlights, but it's kind of missing the point. Why do you *care* whether your neighbour leaves his headlights on? By all means be helpful and let him know, but it's no skin off your nose if he's going to be an idiot about it and his car won't start in the morning.
Which brings us back to the original situation. Why do you care? It's because you have *chosen* to make a mission-critical service depend on a piece of software which you cannot just fix for yourself, so you're beholden to a third party for fixes. A third party who, in your case as in many similar cases, is too incompetent and/or unwilling to help you.
Getting into that situation in the first place does not strike me as being particularly responsible.
Well, I think it works like this. If vendors as a group want to encourage more "responsible disclosure", they need to operate in such a way that they take potential vulnerabilities seriously, and I don't just mean in a "we're taking this very seriously" kind of way, but more of a "we have a dedicated, knowledgable staff member/team to look into situations like this" sort of thing. If they decide it's not an issue after all, then any responsibility you have to the vendor is over regarding that issue. If they're not willing to even consider it as an issue after you've made a good faith effort to let them know how much of a problem you think it is, any responsibility you have to the vendor is over regarding that issue.
In short, a gentleman's agreement only works if both parties are gentlemen.
It's hard getting the attention of some vendors. I see vulnerabilities in a slightly different context - hacked web sites hosting phishing pages. We distribute a list of major domains being exploited by active phishing scams. This is obtained by processing PhishTank data, and we do this because we want to reduce the collateral damage from a tough blacklist system. At any given time, there are about 30 to 80 domains on the list.
Some sites get themselves off the list quickly. By now, most of the better free hosting services and short-URL services are automatically checking PhishTank and the APWG blacklist to see when they've been hit. Today, if you run a service where anybody can put up a page that could be used for phishing (i.e. it's not full of your own headers and banners), you need automation to deal with attacks. I've been in contact with the abuse guy at "t35.com", which is a free hosting service. They've recently been hit by a flood of phishing attacks, with several hundred new reports in PhishTank per day. The attacks were coming in faster than the abuse guy could clean them out. They're now gaining on the problem, but haven't squashed it yet. Take-away lesson: automate this.
The ones near the top of the list have been there for a while. Note the dates, which are the date that the oldest phishing report still online and active appeared in PhishTank. Some just need help. Typically, these are small organizations like churches and nonprofits that have had a break-in and were partially taken over by a phishing site. I send them the Anti-Phishing Working Group's "What To Do if your Site Has Been Hacked". Sometimes I give them a phone call. They deserve sympathy.
Then there are the hard cases. These are sites with no visible contact address, or a clueless abuse department. At the moment, Google Sites and Google Spreadsheets are being used for phishing. Google is new to the free hosting business, and the phishers have discovered some tricks that Google can't yet handle. While Google puts a "report abuse" link on their site pages, it's possible to set up a file for downloading on Google Sites, and an HTML page can be served that way, without Google's abuse checking. There's also an exploit of Google Spreadsheets. That one is an example of Habbo Hotel phishing. We've reported these to Google several times, but they haven't been fixed yet.
We've been seeing a new type of attack recently - a phishing operation breaks into a shared hosting server and plants phishing pages on multiple domains on a single server. One of these hit one of the mysterious "*.websitewelcome.com" servers, which has "cloaked domain registration" and no useful default web page. These seem to be associated with "ThePlanet.com", but whether ThePlanet operates them, is providing wholesale hosting, is providing colocation, or is just the upstream connectivity provider is not clear.
Hiding the contact information of a hosting provider is legally unwise. The hosting provider may lose the "safe harbor" protection of the the DMCA. The "safe harbor" provision for "Information Residing on Systems or Networks At Direction of Users" only applies if "the service provider has designated an agent to receive notifications of claimed infringement... by making available through its service, including on its website in a location accessible to the public, and by providing to the Copyright Office, substantially the following information: the name, address, phone number, and electronic mail address of the agent." So when the RIAA or the MPAA come calling, a likely event for a hosting service, they get
That analogy. Stop it.
The problem is that if you do the responsible thing, the vendor ignores it, and it gets posted to bugtraq, it can be pretty bad for you. Doesn't matter if it was you who posted there or not, or if it was morally right to post it.
You have to make the choice beforehand: either go via the vendor or go via bugtraq, you can't do one and then switch to the other.
Finally! A year of moderation! Ready for 2019?
This is not a programming problem any more. Much as we all hate lawyers, this is one case where they are useful. VERY useful. You put him on notice, it's not your problem any more. He puts the vendors lawyer on ACTUAL notice (which has a specific legal meaning). He might even need to tell the other lawyer that he's going to have to report this issue in the next required SEC filing. IMO, if you already have the thing deployed, which it seems may be the case from your post, your FIRST stop should have been the attorney.
As long as having a good working relationship with a vendor that you and your company knows is incompetent and unethical is more important than your security and the principle of doing things right, then you get what you deserve.
You know what the exploit is. But what makes you think you are the only one? What makes you think no unethical hackers know about and won't find out about it for the life of this exploit (which seems from the vendor attitude that it could be very long)?
You (your company) needs to take steps to protect yourself, now, immediately. Do whatever it takes to make the exploit unusable from within your network and from outside. Send the bill to the vendor ... on your law firm's letterhead. Mention the names of several sleazebag debt collectors for extra points. If you are afraid of ruining your relationship for that, then, again, you deserve what you get.
I also suggest updating your resume and your LinkedIn profile, and keep an idea on the Indeed listings.
now we need to go OSS in diesel cars
James Bond: Ejector seat? You're joking!
Q: I never joke about my work, 007.
You can disclose it anonymously through wikileaks.. They could make a category for it. You could try at least.
Allowing you to work car analogies into everything since 2010.
First off, there are very few software packages of any size that are sold with terms and conditions that would allow anyone to sue the vendor for any reason. The only path I could possibly see is an agreement that bugs will be fixed - but this vendor is disclaiming that this is a bug. So even that probably isn't going to get you anywhere. Suing is almost certainly not an option unless you have money to burn.
There are far too few details in the posting to explain how this software is used and what its function is. It could be something that is on an internal web site and the exposure is from potentially unqualified employees accessing internal information. It could also be a public web site that allows people in Eastern Europe to get enough medical information on celebrities to blackmail them. Who knows?
If the vendor is saying it isn't a bug it is doubtful many other customers are going to immediately see that it is a problem. They might after a while - again, depending on how this software is used. So going to other custromers isn't likely to be very useful short term.
Certainly this is a the result of buying packaged software rather than writing everything yourself. You give up a certain amount of control. Open source isn't a solution, because if you aren't familiar with the code it could take a very long time to learn enough about it to do anything like fixing it. I'm sure you could pay a consultant to learn the package and fix it, but then you could also just pay a consultant to write you a system the way you wanted in the first place.
This is the age of the packaged software solution. It started around 1985 or so and continues to this day. Absolutely, a side effect of this is that you need to be on good working terms with your vendor(s) and your vendor(s) need to be competent. I haven't seen anything that says the vendor is incompetent, just that they disagree about the severity of the problem so far.
Sure, as a programmer I would like to think that every single company should be employing programmers and custom-writing all their own stuff. Just like 1975. Except that isn't the way things turned out. Too bad, fewer programmers employed. But it is how things work today and nobody is going back.
The sad thing is that by doing the right thing and attempting to report this responsibly, the articles author has now set himself up to be scapegoated. If the exploit is leaked now, whether he does it or not, the vendor will blame him for it and focus as much on destroying his career as on fixing the problem. This is the reason many security professionals decided long ago *not* to report these things "responsibly" but simply to leak them anonymously in every case. Doing this forces the vendor to deal with the vulnerability without making the reporter vulnerable.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
I have no information about this instance, but the public face of the company you are speaking to is not always knowledgeable or intelligent. I work for a software company, and I have seen instances where a customer reports an issue and has it waved away without consultation by the first-contact support employee, usually under hand-waving like "no-one else is seeing this problem", or "I haven't been able to reproduce it". In most of these cases, an experienced person has not been consulted, and there has been no further investigation on our side.
Yes, the support people are part of the company, which makes the response the company's responsibility, but at the end of the day it comes down to flawed human beings assuming they know more than they do. We try to take steps to prevent it, but it's hard to anticipate and recover from without manually inspecting each support incident after the fact - a step we just don't have the time or money to take.
When confronted with one problem, some think "I'll use recursion". Now they are confronted with one problem.
the reason companies don't like people disclosing their security holes is not only do they have to release a fix, they also have to slip in a new hole and make sure most of their botnet successfully migrates to it. since there is a gradual uptake of patches and people tend to drag their feet installing a given patch botnet performance can be severely impacted reducing the marketability of it's services.
why not get these guys to help you. Maybe the vendor will take them seriously.
that the vendor is attempting to use their leverage as an important part of your business to your disadvantage; what they have failed to realize, however, is that the existence of this security hole is YOUR leverage. Public disclosure of the exploit and their position as relayed to you would be a PR nightmare. It would destroy many current and potential business relationships. Do not view this as the 'nuclear' option; rather, it is an exercise of your rights as a consumer: namely, to let it be known that they are a bad vendor that is unwilling to fix significant problems with their product. Much in the same way that Toyota is expected to fix their accelerator problem free of charge , you should have the same expectation. A lock company that sells broken locks will go out of business in an awful hurry.
This is a good example of how cultural differences would influence the handling of the disclosure:
Japanese security engineer: Spend a couple of all-nighters until a reliable hack protects his own company's system, then do nothing as the vendor of the buggy app might loose face if confronted
Italian security engineer: flirt an hour with the receptionist at the vendor, until she gives him the extension number of the programmer responsible for the product. Then curse at the poor sod, who curses back, but then fixes it immediately and sends the patch in an email to a few dozen people he knows at important customers.
German security engineer: Write a 100 page report on the bug and how to fix it within two days. Then have this report signed off by each of his bosses up to CEO, which takes a couple of months. Once report reaches vendor, Patch is prepared, tested and sent out in a week.
American security engineer: Short stock of vendor, then call own legal department and tell them to sue the pants off the vendor. Don't fix the hole, but buy insurance coverage in case own customers find out.
I've read through this and have one question that may determine whether there is a concern or not.
1) Is the software designed to be deployed 'inside' the company firewall?
If the answer is yes then don't put it in the DMZ and report security concerns.
Also, if the competition already knows about this, wouldn't they be likely to expose this?
The only reason I posted this (anonymous, forgot my password) is that I work for a software vendor and for political reasons (not technical ones) certain companies will place software that is designed for internal use on the internet. We highly recommend against this and really there is no purpose of exposing it in such a way.
I am not suggesting that each company purchase a firewall, but place the software behind the existing firewall.
Too many things about this discussion make be believe the sw in question was designed for internal use.
"Have you ever knocked on a neighbor's door to tell them they left their headlights on? Did they then require you to cook them dinner? Exactly..."
And after dinner, did they then require you to take them to a movie, a concert, some clubs and a night of passionate...
Excuse me, I'm just going to go check all the car headlights in my street. Be right back.
You are not a brain: http://books.google.com/books?id=2oV61CeDx-YC
What your problem is is not Reasonable Disclosure it is more vendor relationships, which will almost always involve playing a bit of political posturing. While there is never a one size fits all solution, I could suggest a few things that might be a good idea. First I would asses the risk that this company in particular poses to your overall operations, this does include things like chance of reprisal for disclosing this. I know this is a daunting task, but you need some kind of metric of how much sticking with them will cost you, both in the short and long term. Once you know your risk you can figure out how to play this game. If there is little risk to your operation, I would suggest a full public disclosure. Yes this might be dangerous but it is a very surefire way of getting resolution, it may not be to your liking but something will get done. There might be only moderate risk, that would probably have anonymous disclosure. If you have given the developers a chance to correct and patch (about a month) this is a perfectly fine course of action. It will help limiting reprisal while still giving you some protection. Finally, there may just be too much risk that disclosure might harm you. My suggestion with no knowledge of particulars would be find alternatives and compare the risk with disclosing vs cost of switching to a new system. The latter will almost always be more expensive in the short term, but over the life cycle of the product it might cheaper to switch sooner then later
If you feel like making an exploit public, go right ahead. Just make sure you send your patch along with it.
What? No patch? It's a java servlet app, not an ELF binary. Unzip the .war, decompile the classes with jad, and fix the damn thing yourself.
*I've* lost patience with the attention whoring from wannabe security researchers.
Tell the vendor that if the bug is not fixed within 2 months, you will notify any customers of theirs that you are aware of about the issue (and ask them to forward accordingly) such that they can protect themselves from the coming storm, and shortly after announce the vuln. publicly, with a Proof of Concept exploit. Even if you are unwilling to follow through with your threat (read: a pussy), the threat may well be quite effective.
As somebody else pointed out ... the least you owe to your employer is to (attempt to) lock down your own system before you tell the world where the hole is.
Free Software: Like love, it grows best when given away.
If a vendor blows you off with a problem this time, then you know that that's a stupid path to take next time. An anonymous report ((preferrably to other users, rather than to the public at large -- which is more likely to include black-hats)) is a bit less of a political problem if they don't know that you already know about it.
Free Software: Like love, it grows best when given away.
So let me get this straight... some guy at attrition.org has a hard time and posts a rant, and this is news? His anecdote is evidence of a general problem with vulnerability disclosure?
... is to notify the vendor, and give them X weeks of grace time before you publicize the vulnerability (with or without exploit.)
It's really that simple. You owe nobody. But to be responsible is not to release 0-day into the wild for installed software, because you're screwing the innocents unnecessarily by giving recipes to script-kiddies before the vendor can react responsibly.
Come to think of it, this procedure has been hashed out a fucking dozen times on Bugtraq and other security mailing lists before. Why are people even wasting their fucking time arguing about it now? The argument is OVER ALREADY.
* Leak it anonymously after 3-6 months. The people at the vendor who ignored it will be fucked. You'll have a great negotiating position if you told the vendor about the exploit, they ignored it, and the exploit is now in the wild, and your systems are vulnerable. You'll need to find a period when you can either take the systems down, or internally secure/protect against the exploit in some way.
* Hire a security consultant/contractor with the terms that they'll look into it, and that they can expose it after 6 months. Tell the vendor that a consultant/contractor knows about the exploit, and has an NDA that expires in 6 months. The time bomb will make them fix it.
* Ignore it. You've got hundreds of unknown open exploits in your system anyways.
Their bad software is not your problem.
The vendor will have to spend money and PR time trying to implement a fix and will not do so until forced to. That is the bottom line. Yeah I agree you have to be creative to force them to acknowledge the problem but if the issue is real and can be verified by a third party then personally I'd give them an opportunity to fix it and then if they refused I'd make it public somehow in an effort to force a fix. If it is that important....then it is that important right?
Honestly why do you care so much? You did your duty by reporting it to the vendor. If they don't want to fix it, that's their problem. Just CYA by emailing whoever in your co is using it that there's a problem and these folks don't want to fix it so that when it all goes to hell, you can say I warned you, don't blame me.
If you really care that much, write an article and submit it to a publication disclosing your communications, the identity of the vendor, and the product but lacking enough info to exploit the bug
Also next time disclose it anonymously to the web right away so it actually gets fixed :)
If you feel like making an exploit public, go right ahead. Just make sure you send your patch along with it. What? No patch? It's a java servlet app, not an ELF binary. Unzip the .war, decompile the classes with jad, and fix the damn thing yourself.
I've lost patience with the attention whoring from wannabe security researchers.