Slashdot Mirror
When Is It Right To Go Public With Security Flaws?
nk497 writes "When it comes to security flaws, who should be warned first: users or software vendors? The debate has flared up again, after Google researcher Tavis Ormandy published a flaw in Windows Support. As previously noted on Slashdot, Google has since promised to back researchers that give vendors at least 60-days to sort out a solution to reported flaws, while Microsoft has responded by renaming responsible disclosure as 'coordinated vulnerability disclosure.' Microsoft is set to announce something related to community-based defense at Black Hat, but it's not likely to be a bug bounty, as the firm has again said it won't pay for vulnerabilities. So what other methods for managing disclosures could the security industry develop, that balance vendors need for time to develop a solution and researchers' needs to work together and publish?"
When it makes microsoft look bad so we can trash them on slashdot?
... and posted them elsewhere. So here's a quick copy paste and what my thoughts are.
======================
Procedure :
Step 1) notify manufacturer of flaw
Step 2) Wait an appropriate time for response. This depends on the product. OS could be as much as months depending on how deep the flaw is. Web-browsers probably 2-3 weeks.
Corollary 2a) If manufacturer responds and says its a will-not-fix you have some decisions, see 3a.
Step 3) If no response, make an announcement of doing a proof of concept exhibition with a very vague description. People asking for details say it was probably as vague as possible. The company has already been contacted, so they know the issue or can contact you from the announcement. Schedule it with enough time for the company to release a fix.
Corollary 3a) How critical is the flaw. If marked as will-not-fix and its very detrimental you might have to sit on it.
Step 4) Do exhibit. With luck flaw has been fixed and last slide is about how well manufacturer did.
Step 5) ...Profit!!!! (While this is the obligatory joke post, Check out E-Eye security to see how it's happened before)
===============
WRT to 3a: You'd be surprised how often this is done. There are two long-standing issues against a certain software that, while being uncommon and not often thought of attack vectors, are less than trivial to exploit and gain full access. Manufacturer has, in fact, responded with a "works as designed, will not fix." People in the information securities industry have found the flaws so detrimental that they've imposed a self-embargo about openly discussing it. Without manufacturer buy-in, a fix just can't come in time if that particular information was released and the effect would be significantly widespread. The only thing releasing the information would do is cause a massive Zero Day event that would only harm consumers or leave them without the services of the software for several months. With no evidence that the exploit is being used in the wild, save for handful of anecdotal reports, the issue has become a bi-annual prodding of the manufacturer.
Code softly but carry a big magnet.
I discovered a large DoS within VMware 3.5-4.0 last march. I opened up a support case on it to at least find a workaround. The engineer closed the ticket after an hour or 2 as "unsupported OS".
The DoS reboots ESX/ESXI out from under the VM when you power the VM on.
This leads to serious issues, and the closed the ticket quick. No further investigation. This is a perfect example of releasing details and source to force the company to fix the issue.
"as the firm has again said it won't pay for vulnerabilities"
Don't you think that one way or another... all these companies pay for their vulnerabilities?
-a. coward
Time after time it's been proven that the safest security is the security that is shrouded in the most mystery. Why can't anyone hack Windows 7? Because it's new and no one knows how it works. People like Ormandy are a bane to the community because they steal code from Microsoft (there is no other way they could know about these flaws) and then once they stolen it, they release it for virus writers to hurt the common man. They are a public enemy and I'd suspect he has contacts inside Microsoft (if you're reading this Steve Ballmer, I suggest you begin purging those who doubt you and those closest to you).
I cannot believe Google would show support to someone who is most obviously a criminal aiding and abetting other criminals.
Nobody wants their source code shown to malware writers for obvious reasons so let Microsoft have its privacy. Why do individuals get privacy rights but not Microsoft? Did you ever stop to think about that? No, you didn't, because you were too busy helping the bad guys.
You should never reveal a security flaw. It's called common sense about saftey and protecting everyone around you.
"Who should be warned first: users or software vendors?"
Tell both. But if you announce something, please doc how you did it and don't brush off the vendor. (Email from users and press can get pretty thick after you announce something - if you're ethical and really want to fix the problem all that noise should be lo pri...)
I agree with MS on this, deadline always isn't feasible. They have to test on many different levels before they could release the update. Google just used Ormandy to have some positive PR on themselves. Frankly, from my point of view, Google screwed this one up and Ormandy or any other researcher cannot hold companies at gun point to release fix asap. If he had given them 60 day disclosure and even after that, if MS had not provided any response then releasing the bug details would make sense. The way Ormandy and Google acted on this was cheap.
You may be a republican, but you are clearly not a conservative, conservatives call it being a spoiled brat.
The truth is that all men having power ought to be mistrusted. James Madison
to threaten the guys who find vulnerabilities with jail time or fees. I uncovered a major security flaw in a piece of software (allowed an attacker to spawn a shell as root with extreme ease) and also found a way to circumvent the DRM and what happened.... I got stiffed. Instead of FIXING the problem (which is still intact to this day) the company attempted to sue for copyright infringement, among a few other "charges". Luckily, I had a great lawyer and I had documented EVERYTHING from 0 to 60. I was lucky.
This makes me sick. One minute, corporations are talking about providing "rewards" for unearthing flaws/vulnerabilities and then the next, they are trying to sue for every penny. If it wasn't for us, their systems wouldn't last a week without some script kiddie coming along and bringing the whole thing to it's knees.
It's interesting that the talks center around the responsibility of the researcher and the vendor, but often little attention is paid to the responsibility of the user. Are they as liable? For example, if a manufacturer sells a door lock with flaws but the user keeps the windows (ha) open and someone on the street shouts, "Dude, you're using a Schock Pax H23 and it can be opened with a loud scream!" who is responsible?
As primarily a Linux user, I used to think that the tools just didn't exist on Windows to see what the system is doing. On my Linux box, I can do a "netstat -tlnw" or an "iptables -L" or "fuser -n tcp xxx" and get lots of information. Using that I can disable services, lock them off with TCP Wrappers or IPTABLES, or even sandbox them very easily.
When it was necessary to use a Windows XP system in a relatively hostile network, I was worried. Then I started poking around. Netstat is available on Windows and does the same thing. There's a process listing. There's even a grep workalike ('find' of all things). With those tools it's possible to get a good picture of what's happening on the system.
The gist of this post is that though I enjoy the expanding marketshare of Linux, I am worried that it brings hordes of users that do not make the effort to know their systems. Should they? I think so. It's similar to carrying a firearm. It's great to be able to do so, but you must be responsible about it when you do carry.
Never, ever a responsibility. You didn't write the bug, you didn't miss it in testing, you didn't release it. You owe the developer nothing.
The only ethical consideration should be your sole judgement about the best method to get a fix in the hands of vulnerable users.
You don't like that, Microsoft? Then do you own vulnerability testing and don't release software with vulnerabilities: the problem goes away overnight. Until then, sit down, shut up, grow up, and quit your bitching about being caught with your pants down.
If you were blocking sigs, you wouldn't have to read this.
Once you suspect a security flaw, flare a public mailing list with developers on it. Ask them for help tracking down the issue, until you as a group determine if you've discovered a hole and get a proof of concept running, all in public discussion.
Support my political activism on Patreon.
No one is bright enough to find a security whole that couldn't have been discovered elsewhere before. So it's pretty likely the flaw is either known to the vendor who might not have had seen the need for fixing this, or it is known to an attacker, who already uses the flaw and just didn't appear (yet) on the radar of any researcher or the vendor. As it might be possible that you yourself are monitored by anybody else, your finding might be in the open that way. So it makes no sense in keeping the public uninformed.
cb
WRT WRT 3a: So the industry and the manufacturer are basically patting each other on the back, happy in the knowledge that if no-one from the club talks about the problem, it's impossible to discover otherwise? It's going to be slightly icky to say "we told you so" when this is discovered independently and causes "a massive Zero Day event that would only harm consumers or leave them without the services of the software for several months." (Note that I used "when this is discovered", not "if". As you may be aware, if something could be done, it's only a matter of time until somebody does it)
When it makes microsoft look bad so we can trash them on slashdot?
How about giving the vendor time to issue a patch if said vendor has earned the goodwill of the community or at least not earned the ill will of the community? Abuse of monopoly as found in various courts of law? Immediately go public. Vendor lock-in practices? Immediately go public. Silly patent lawsuits over ideas that are not really original? Immediately go public. Public statements about how they now take security very seriously and it is a top priority for them and then no substantial improvement? Immediately go public. Using their power and influence to bribe standards committees? Immediately go public. Deceptive marketing practices? Immediately go public. Building strict DRM as an integral and non-removal component of the OS? Immediately go public. This list is not exhaustive and would apply to all vendors.
Found a vendor that does not engage in these practices? Work with them. Give them time to develop a patch. Help them fix the flaw, if you are so inclined and have the skill. Note that there is no such urge to make them look bad when they don't use all the plotting and planning and manipulation and control, and decide to make thier money by producing good products that people want to buy. Crazy concept, I know. For those companies, it would be wrong to immediately go public in order to make them look bad. Microsoft is not one of those companies.
And if you say "but what about the users who suffer exploits" I have an easy answer. You mean the users who reward abusive companies with their money and continue to fund more of the same? You mean those users? Heaven forbid if doing business with abusive companies might not be entirely free of negative repercussions for them...
This is standard operating procedure and responsible disclosure as far as I can tell.
The problem is that the company is likely to file an injunction to stop the presentation and possibly file blackmail charges against you.
You need to amend the above procedure with anonymous notification and demonstration in order to protect the safety of those following responsible disclosure.
I like especially how this ignores the human angle and assumes that all involved parties are even able to shut up for years (well, I don't know, maybe they receive... err... gratitude to shut up).
There are two long-standing issues against a certain software that, while being uncommon and not often thought of attack vectors, are less than trivial to exploit and gain full access.
The problem with this approach is that if a hole exists, you can script/code something that can automatically take the necessary steps to exploit it. I remember years ago a problem existed with the startup of a certain service. At one point when it bound itself to a port, it was vulnerable to a DoS attack. The window was just a second or so and then the software would lock itself down. Unfortunately, if the machine was rebooted or otherwise knocked off the network (say by flooding the switch with bogus arp packets) you could hold open that port for as long as you wanted. Then you'd have another machine connect on that port and use the exploit to crash the service, get a root session with the same userid, and then wreak merry havoc (or maybe overwrite a few files). All of this could be scripted.
Software gets more and more complex. If a user is running a particular filesharing client it's possible to view names of files that are not explicitly shared by exploiting an issue with, of all things, a popular virus scanning program. The name and size of these files will tell you what versions of software are installed. These can then be sent up to the Internet (luckily enough because the filesharing client is allowed through the firewall) and collected in a database. Some months later and a new exploit is found and there's already a list of vulnerable machines all ready to be farmed. And because the farm is targeted to those machines, it's far less likely to be detected.
All software is crap. Windows, MacOSX, Linux.. All crap. So many holes, so many unpatched systems. It's all security theatre.
You need to notify CERT, and then they have the ability to apply more pressure on the manufacturer, as they simultaneously publish a very vague notice to the community of a flaw being worked on. If CERT is involved you have a much higher probability of not being ignored or told "will-not-fix" because it is already public knowledge that there is an exploit that needs fixing. Its in the record. The official "report cards" for the vendors then have the clock start ticking the minute you report the flaw, and the vendor can not deny that they were notified and/or aware of the problem. In other words, they can't sweep it under the rug very easily, and you have done the best you can do without causing mass pandemonium.
So, your "people in the information security" are basically helping the vendor selling faulty software while withholding crucial information from users of said software at the same time? If the issues you mention are indeed "less than trivial" you help the vendor to cheat people into thinking that they are safe with the software.
"People in the information security" have the job of making the IT environment safer. You must force the vendor to fix these holes even if it takes a vulnerability disclosure and a lot of bad publicity for the vendor. The vendor's job is to make good software. If the job is being done poorly the vendor deserves all the losses it will get. As for users of the software -- how do you know this vulnerability isn't used right now? It is not a widespread issue but maybe it is used to target particular users? Such behavior screws up informed users who care about security at the cost that clueless masses will be temporary safer for the time being.
It is a good idea IMO to stop being short-sighted. In the long term such a disclosure will do more good than current sitting on the issue.
Do not give bad guys the possibility to learn about a flaw earlier than the users who are affected. If you don't publish the flaw, there is a certain possibility that it will be sold at black markets and kept secret to be able to use against customers. You can see that full disclosure groups are targets of commercial crackers. Full disclosure is like destroying business of criminals.
A customer should always be aware of a flaw and know how to protect himself against it.
There is no need for exploit code. You should publish it BEFORE having a PoC to warn as early as possible (but this is pretty rare, because having a PoC is usually the first indication that a flaw exists). It would also help to give as much information as possible how to protect against attacks (fixes/patches, what to avoid, what to disable, how to minimize the risk).
The problem with "responsible disclosure" is being allowed to do it. Reporting a bug to a vendor might get you a "fix" response (best case), might get you ignored (average case), or might get you hit with a Gag Order lawsuit (worst case). Disclosing the bug after the worst case can get you arrested and even if you manage to avoid jail, you have spent a lot of money in defending yourself. This is the reason behind the full disclosure movement, to prevent vendors from gagging researchers who discovered bugs (security by obscurity), and allow Administrators to work around bugs by disabling the service(s), firewalling, sandboxing, etc. It's been said many times, but is worth repeating, that just because the bug hasn't been put on bugtrac, doesn't mean the black hats don't know about it. It's also worth noting that bugs that have been in existance for years, were only addressed once they were disclosed to the community.
Whenever you damn well please unless you are contractually obligated to do otherwise.
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
It's probably worse than that. GP didn't give us much to go on about the nature of the attack, but generally a flaw described in such severe terms either (1) offers a foot in the door for the attacker to go after other systems on the network, or (2) exposes sensitive information. By contrast with flaws that allow DoS (for example), it isn't typically obvious when a flaw of that type is exploited.
So the question isn't "how do you know someone won't discover the flaw? what will you do when you notice it being exploited?" The question is "how do you know someone hasn't discovered the flaw? would you notice if it's already been exploited?"
If the flaw is that severe and the vendor won't budge, silence is not an appropriate response. I question whether GP has the close ties to the security community that he insinuates.
Never said it was an easy position. Not one of them likes the situation they are in, but no one has been able to come up with a good solution.
To be fair I think as wide spread, detremental, and unknown as these two problems are it's very unlikely that there are more than a handful of such cases in software out there today and it's only done in the most extreme of situations. At least, that's my sincere hope.
As for it being used right now. To be honest we don't know that it isn't. But generally, it's a widely enough software that I'd expect people there to be press despite the company getting a lot of passes in the press.
Code softly but carry a big magnet.
Companies are always a threat. Disclose anonymously to the company, wait, then disclose to public without warning.
There is no reason to offer your neck to your enemies. There is no reason to want recognition from them.
Remember basic security, tell no one who you are, and don't go attention-whoring after you release.
"This post is an artistic work of fiction and falsehood. Only a fool would take anything posted here as fact."
As others already mentioned, first see what the people who released the software react.
On how long you need to wait depends greatly on their response and the security risk involved. If you found it, someone else might have found it as well.
If you find a security loophole in ssh, and people do not react, I would say a week after notifying the ssh people with a proof of concept and there was not response.
Importand security risks generally take 2-3 days. The reason for this is that way all distro's can get the patch out at the same moment, reducing the vurlnerability of all.
If the makers answer, it will depend on how they react and again the security risk.
Don't fight for your country, if your country does not fight for you.
I sure hope they were NOT paid;
it would make them part of an
conspiracy to cover up flaws.
And, when someone uses that flaw
would make them and the Companies
they work for possibly liable to
large amount of damages and
possible jail time.
IANAL, but like to play one on the web.
Tim S.
if i ever run across a vulnerability in any closed source software i will submit that information anonymously to prevent the authorities from treating me as if i was a criminal or terrorist, the only exception to that rule would be if i found a vulnerability in something licensed under the GNU/GPL then i will simply submit a bug report through the regular channels or email the author of the software directly.
Politics is Treachery, Religion is Brainwashing
As long as the vendors get a grace period or as in some cases forever as a timeframe the incentive to fix the real issue wont go away.
The discussion about full disclosure/responsible disclosure is a side issue to the real questions. Why dont the vendors do proper testing before releasing software? Why do they refrain from fixing bugs they fully know about? Why should researchers take any responsibility for the vendors customers when its obvious the vendors wont think twice about security or Q & A?
Its not like there is any shortage of tools for finding security holes today. Its apparent many of the biggest vendors wont even bother testing their stuff with simple fuzzers.
The reason vendors wont mind releasing bad crap is that they get away with it. If helping the users is the goal information is power. When people start to see just how crappy some products are they can make an informed decision. Then and only then will people start shopping for better alternatives / demand better security.
Right now most people have swallowed the propaganda that todays systems have the best security money can buy when in reality we are not much better of than before. As security has risen from abysmal to crappy so have the hackers. The problem is that the hackers, the real ones, are miles ahead of the security community and the vendors.
HTTP/1.1 400
"they will have to get off their fat asses or they will be sent back to their basement in shame."
What drivel! I'd never leave Mumsy's sweet, sweet basement in the first place.
"This post is an artistic work of fiction and falsehood. Only a fool would take anything posted here as fact."
lets see, time to patch any major portion of GNU/linux, probably less than 2 weeks. thats from bug report to update in distros repos. If OSS can do it with free labor in 2 weeks, paid for devs should be able to do it in less, say half, 1 week. I know my apple keyboard wasn't fully supported when i bought it, less than a week later there was a patch applied to mainline stable kernels that corrected the issue. and that was just for some of the FN keys not working as advertised. So a month max sounds good. I would note that without things progressing in a month i feel bound to release this info so that admins may take steps to mitigate the issue.
All of the above was encrypted with a Quad ROT-13 method. Unauthorized decryption is in violation of the DMCA.
I wish I had Mod points for you.
Why is it so hard to only have politicians for a few years, then have them go away?
>Remember basic security, tell no one who you are, and don't go attention-whoring after you release.
You've identified the real issue, but this is often ignored. The problem isn't the disclosure itself. The problem is that so many people with such disclosures to make, seem to want credit/attention for their efforts, but also want to be free of the risks associated with seeking that attention. Anonymous channels exist. Release information via one of those, and then if somebody is upset about it, they can do as my Uncle Bill always said: "Complain in one hand ... and see which one fills up first."
-fb Everything not expressly forbidden is now mandatory.
Stop being pansy and just release the flaw on Wikileaks or some similar site.
If everyone didn't give a crap about the company with the flaw in the first place, and took a open-source viewpoint of releasing exploits, maybe they would be fixed a bit quicker when MS (or other Vendor) sees that they are patching 3 critical flaws a week, but people are releasing 25 a month.
maybe these "shitty" software companies will start to realize that they need to spend more money on fixing flaws than putting cash into the marketing slush fund.
In most cases you warn the vendor first, providing complete details including exploit code so they have no excuse for not being able to duplicate the problem. If the vendor won't acknowledge your report within a reasonable time (say 7 days), will not commit to a timeline for having either a fix, a workaround or a mitigation strategy for users within a reasonable time (say 14 days from acknowledgement, with the deadline being 30-90 days out depending on severity) or fails to meet the deadline, then you disclose to users including full details, exploit code (so the problem can be independently verified without having to rely on your word that it exists) and a recommended mitigation strategy. Demanding payment for the report is never appropriate unless the vendor has publicly committed to a "bug bounty" and your demand is what they've publicly committed to.
There'd be occasional exceptions to the above. If for instance the vulnerability is theoretical and you can't create actual exploit code for it, demanding the vendor fix it is inappropriate (by the same token, though, it's far less of a problem to discuss the problem in public if it truly can't be feasibly exploited). The deadline should be more flexible for less severe vulnerabilities. If the vendor has a track record of responding inappropriately to reports (eg. by threatening legal action against the researcher), immediate anonymous disclosure may be a better approach.
The No Code Publish approach seems reasonable to me: Publish flaw to everyone - including CERT, Vendors but include no code or exploit for anything publicly readable. Give the vendor your exploit code an a deadline after which you will publish the exploit. If no fix appears by the deadline then you publish.
Huh? If there's a severe vulnerability and the manufacturer refuses to fix it, you should release it immediately. Then at least those affected can mitigate their vulnerability. Otherwise, the black hats have free reign.
Give me Classic Slashdot or give me death!
>Whenever you damn well please unless you are contractually obligated to do otherwise.
And "contractually obligated" necessarily involves an exchange of valuable consideration (e.g., they give you money in return for your agreement to keep your mouth shut). In general, software EULAs are not contracts for exactly this reason.
-fb Everything not expressly forbidden is now mandatory.
That list applies to Microsoft, obviously, but it also, in part, applies to Apple. Especially the parts abiyt "silly patent lawsuits" and "building strict DRM as an integral and non-removable component of the OS."
Overall, Apple plays nice, however, so I wouldn't be as quick to punish them as you, I guess.
My blog
I love all the people posting as if they ever discovered an exploit, or will ever discover one. Here's my advice: if you discover the exploit, you're enough of a pro that your instincts on how to deal with it are a lot more informed than the advice you're getting.
I found a ring 0 exploit in a popular operating system, whereby any unprivileged user-mode process could get ring 0 access. It's been about a month since I told the developer, and they haven't said when a fix would be coming.
It's a ring 0 exploit, but actually turning it into a a root exploit is annoyingly complex due to the design of this operating system. There is nothing computer-theoretic stopping it, just complexity regarding the way page tables work. The exploit gives ring 0 in your control very easily, but the process of getting user-mode root from ring 0 like this is difficult.
"Screw Sun, cross-platform will never work. Let's move on and steal the Java language." - Visual J++ Product Manager
This is very true. Whistleblowers have some protection but it is still dangerous to be one, and especially dangerous to be a very public one.
Check out my world simulator thingy.
If you're really a whitehat, tell the vendor first. This will keep the exploit away from blackhats while the vendor fixes the hole. Security through obscurity works, up until the time it doesn't. So if the vendor does not fix the hole quickly, and you suspect the blackhats are about to discover it, then you need to inform the people who are vulnerable to it. If possible without broadcasting it to the blackhats and script-kiddies. Yes, that's rarely possible, but if it's possible it's the right thing to do first. The only reason to broadcast a hole is that you know the blackhats are using it and it affects people you can not contact any other way.
Any other protocol leaves you open to questions of character and intent. Either you're an attention whore or you're a blackhat looking to cause trouble.
I'm hopeful this post will get the shit modded out of it, preferably as "-1 Redundant".
Giving the vendor an opportunity to apply a fix is all good and dandy, but any researcher must remember this:
Real blackhats don't wait around for a patch before they go on the prowl for systems to exploit. And they don't announce their discoveries in public.
Vendors are not only racing the "egotistic researcher" looking to score points by pulling their pants down, but also against the crackers looking to not only pull their pants down, but rape them in the ass.
No matter who is on what side of the security debate, the clock is always ticking.
Let FOX News know and tell them that it will open up millions of computers to potential identity theft scams, destroy the integrity of national security, and could cause you to be impotent.
Then see how fast it gets fixed.
"Be polite, be professional, but have a plan to kill everybody you meet." General James Mattis
Microsoft should not be the ones that set the writing to law when it comes to any security issue. They have an extremely poor reputation as it is. What Microsoft defines should have little weight in the community where these issues are discovered and discussed. Over the years those that have uncovered these security issues have been well restrained. They seem significantly better equipped to deal with how and when they should be disclosed. If not for them, discovered issues would likely never be disclosed to the public, and the public would not be exerting enough pressure to get them fixed (let alone prioritized).
You can lead a man with reason but you can't make him think.
Publish details about the bug as soon as you find it; publish an exploit as soon as possible. If every discoverer of security flaws did this, software devs would learn very quickly to have second thoughts about releasing unchecked code. I say that as a software dev.
Seriously, you think you're smarter than everyone else? That you're the only one who discovered a flaw? Puh-lease. The Chinese government alone is probably throwing more manpower at finding flaws in US software than there are developers in the US. By releasing the info, you're doing the world a favor. If the vendor doesn't fix it, the customers will move to something better. End of problem.
Nathan's blog
It easily applies to Microsoft. I doubt though he was making the combined list the requirement.
You can lead a man with reason but you can't make him think.
Microsoft should not be the ones that set the writing to law when it comes to any security issue. They have an extremely poor reputation as it is. What Microsoft defines should have little weight in the community where these issues are discovered and discussed. Over the years those that have uncovered these security issues have been well restrained. They seem significantly better equipped to deal with how and when they should be disclosed. If not for them, discovered issues would likely never be disclosed to the public, and the public would not be exerting enough pressure to get them fixed (let alone prioritized).
Agreed, it would be called a "conflict of interests" since their efforts in such regards would solely be to protect their interests, and not their locked in users to any extent not required to maintain their monopoly.
But, that has never stopped companies from buying laws in the past... sadly. :-(
StarTrekPhase2 - The Five Year Mission Continues!
Do we have to have this pointless conversation again and again and again here. Blah blah release blah blah white hate blah blah vendor blah.
Please explain to me what "right" is in the context of your assertion and I'll then try to answer your question. Otherwise it's really impossible.
Quote: The only thing releasing the information would do is cause a massive Zero Day event that would only harm consumers or leave them without the services of the software for several months.
---
So you prefer the alternate option, where you sit on it and only the black hats have access to the zero day event that would harm consumers and leave them without services of the software for several months.
I see the wide difference.
You would prefer you kept your exploits open and vulnerable, so no one can protect themselves against you.
I can only assume you are the attacker, as aiding anyone in protecting themselves is counter to your goals as you stated.
"no evidence that the exploit is being used in the wild" is simply a fancy way of saying "The exploit is clearly in the wild, as despite my beliefs on this matter, there really are people out there smarter than I who have noticed this before"
SO thanks for making the world a more vulnerable place!
Contact vendor and a reputable third party, such as CERT, simultaneously.
Give vendor a -very- small window (at -most- a week or so) to respond, with (1) contact information; (2) an assigned issue identifier (at least one while triaging), and (3) a specific time frame till a follow-up response, not to exceed N days (your choice; 14, 30, 60, 90, etc.). This response does not need to be a full triage and verification, just a real response of "we assigned this to John Doe to research as issue number 54321-unverified", rather than an automated "Thank you for your email..." BS response.
If the vendor blows off responding to this, contact one time requesting the information within a short time frame, informing the vendor of your intent to go public if they do not respond. If they fail to respond, release the information on the exploit, along with any known workarounds.
If the vendor responds with contact, information, etc., give them a time frame of N days (your choice) for analysis and wait for follow up until the time frame of N days specified earlier. If they fail to respond, see above. Again, this does not need to be the fix, just "we confirmed the issue and have determined this is a priority X issue. We are assigning it to Richard Roe to be addressed in a patch/scheduled update/major service pack/next version of product"
After the vendor has performed this initial assessment, give them a fixed, fairly aggressive period to respond with a fix, patch, or workaround, and hold them to the date as above. It's up to you to decide how long to give the vendor before you release the information. If their estimate is too long or inadequate (next version of the product, 18 months from now; will require all new hardware and tens of thousands of dollars), then give them a shorter time frame for a patch or workaround, and inform them that you will hold them to it.
Then hold them to it.
My biases: I believe vendors almost always take much too long. The goal is not to give them a comfortable time frame to respond or fix the issue, but -enough- time. If it's comfortable, it's too long.
Security flaws are unacceptable. If the vendor can't fix it, they must provide a workaround. If they can't provide a workaround, people need to be informed so they can stop using the vulnerable product or feature.
A lot of times you can just disable the feature rather than the entire product.
But people can't do that if they don't know it's broken.
Short answer? When no one else is willing to buy it from you.
'The tyrant will always find pretext for his tyranny.' - Aesop's Fables
a week should do it, specially if there is an easy way to avoid being vulnerable
Let me just start with a wikipedia entry, on Kerchoff's principle: http://en.wikipedia.org/wiki/Kerckhoffs'_principle
If you get the point of Kerchoff's principle, you understand why *if* all things are equal *then* open source code is inherently better than closed source code because public disclosure finds the flaws in the source code faster so they can be fixed faster.
If you want to force a *proprietary* vendor to *immediately* fix a vulnerability, you have to disclose it to the public first, as the vendor will have to scramble to fix the vulnerability or risk losing angry customers.
Talking to the vendor first results at best in delay and/or inaction by the vendor, and at worst threats of lawsuits and criminal prosecution by the vendor should you disclose the vulnerability to the public.
It's like that video by that law professor, the one that advises you not to talk to police. Here's the url: http://video.google.com/videoplay?docid=-4097602514885833865#
In the case of an open source vendor, the code is open to anyone to inspect, and hence is easier to fix. This is why for example Mozilla and Google offers bounties to anyone for finding bugs. They are *actively* encouraging people to find flaws so they can be patched. This is why open source code is better.
shenanigans
Who do we warn first? The potential victims, or the marketing department that need to spin the whole thing as "not our fault"?
Why are we even discussing this?
If your neighbors' brakes are failing, who do you tell first? Your neighbor or Ford?
If you notice your neighbors' locks can be defeated by pushing the door, who do you tell first? Your neighbor or the store that sold the locks?
If it was IRL, you would tell the victim first, and probably wouldn't even worry about the manufacturer getting bad press for selling a defective product. If they lose business for selling a defective product, that's just the market working.
But when it comes to computers, which store peoples irreplaceable digital information (including non-backed up family photos), bank and credit card information and other things needed for identity theft, suddenly there's this idea that we need to protect the manufacturer of the defective product, rather than the victims.
I don't understand why there is even a discussion. Of course we should warn the victims first.
Also, the whole "give the manufacturer time to fix the flaw" is a sham. It's based on the faulty assumption that nobody else found the flaw yet. Sure, if you can prove you are the smartest person on the planet, but for everyone else, the safe assumption is that someone else already found it. Long ago. Either that someone told the manufacturer, and they swept it under the rug (business as usual), or he's a black hat, and the vulnerability is actively being used. Or both.
Taking the safe route, and assuming that the bad guys are already using the vulnerability, would those who argue that we should give the manufacturer time to get their marketing departments working still prefer to alert the manufacturer rather than the victims being actively exploited?
What it sounds like to me is that MS thinks that you owe them. They're doing you a favor by fixing any problems that you find (and if it takes them 6 months, well darn it it's because they were busy patching another Windows activation exploit and that is certainly more important). Were I to find a security flaw with Windows, I would probably release it for all the world to see... without notifying MS. They have paid employees to find and fix these problems, guess they don't need my help.