"The general consensus in the developer community is that one would like to help the open source projects than to torpedo them," said Laura Koetzle, vice president and research director of Forrester Research and the author of the report. "Whereas the temptation with a large faceless company is to disclose early and hurt them."
The dispute over disclosure goes to the heart of an old question: Is it responsible to give details of a threat, if the warning puts even more people in danger?
Those concerns drove a discussion on the mailing list for the kernel of Linux last week. A suggestion that a contact point be created to focus on security issues in the kernel, or core of the open source operating system, immediately blossomed into a debate about whether that list should be private or public.
In addition, the debate centred on the question of whether the vendor-centric security list, Vendor-Sec, takes too much time to fix important flaws.
"It should be very clear that no entity... can require silence or ask anything more than 'Let's find the right solution,'" Linus Torvalds, the original creator of Linux, said in the discussion. "Otherwise, it just becomes politics."
In general, though, the open source world, which has to deal with public development models, has largely learned to embrace security researchers.
"If we get a report from the outside, it is up to the one who finds the vulnerability to decide what happens to it," said Roman Drahtmueller, head of security for SuSE Linux, Novell's version of the operating system.
Microsoft, however, would rather work in secrecy with flaw finders to help prepare a fix. With the public spotlight on its security glitches and with hundreds of millions of users relying on its products, the software giant is very systematic in its approach to patching.
"It is best for customers, because we have a chance to provide updates before a large segment of the black hat community gets to make use of the vulnerability," said Microsoft's Kean.
Flaw finders who do not play by the rules don't get credit in Microsoft's security bulletins and are rebuked in press releases, among other sanctions.
"Microsoft is concerned that this new vulnerability in [product name] was not disclosed responsibly to Microsoft, potentially putting computer users at risk," the software maker has typically written in emailed statements about vulnerability disclosures.
Despite the efforts of Microsoft and others, many researchers still don't feel that the companies take their findings seriously. While some security software sellers have lauded Apple for its response to vulnerability discoveries, an independent researcher gave the company a thumb's down.
"It's really been like pulling teeth dealing with them over the years," said the researcher, who asked not to be identified. "I know a lot of folks that have found vulnerabilities in their stuff that pretty much refuse to deal with them."
Even if security researchers play ball with software makers and hold off on making vulnerabilities public, that might only engender a false sense of security, said flaw finder Aitel. He said that a small, but significant, number of malicious programmers could discover such security holes independently and abuse them.
"We don't feel that we are finding things that are unknown to everyone else," he said. "I am not special because I can run a debugger. Others can find -- and use -- these flaws."
Talkback
I'm afraid my take on the whole disclosure uproar is that, while disclosure may increase my risk, lack of disclosure increases it more. The security flaw will exist whether it's disclosed or not, and the track record over the last 20 years quite frankly shows that the bad guys will find the flaws and exploit them whether they're disclosed or not. If the flaws are disclosed it speeds up the exploits, but at the same time it permits me to take action such as restricting access to the vulnerable points or even removing vulnerable services entirely until the problem's fixed. I can't take that kind of protective action unless I know there's a problem.
The vendors certainly don't like disclosure, it makes them look bad to have security flaws in their products announced to the world. I'm sorry, though, I rate the security of my own systems somewhat higher than the vendor's reputation. And to be honest, if the vendors actually addressed the problems in a timely fashion there wouldn't be an issue with disclosure. The current public disclosure is a reaction to vendors refusing to even acknowledge problems, let alone fix them, when vulnerabilities were reported only to them and not publicly disclosed. Public disclosure, even with it's short-term risks, seems to be the only way to get vendors to actually fix the problems as opposed to denying they exist and leaving everyone exposed and vulnerable. If the vendors don't like public disclosure, perhaps they should start treating security problems as problems that need fixed as soon as reported and not as PR issues that need to be spun or made invisible.
In my view it's OK to give the vendors some time to come up with a solution or at least a workaround because, at least in theory, the vendor should be able to give the best solution. Say 20 working days (4 weeks) but no more. After that the flaw, also the already fixed and falsely reported ones, should be made public for the following reasons:
- it allows others to help find a cure or workaround
- it puts pressure on the vendors to at least provide a workaround if they can't meet the deadline (rather then just postponing it until they can finally fix the flaw completely)
- it puts pressure on the flaw finders to only report solid cases or otherwise risk getting named and shamed (vice versa, a vendor that resorts to name calling or flat out denial will undergo the same)
- it puts pressure on the vendors to sell only "responsible" software or otherwise suffer the consequences
- making flaws public under strict rules will make it more difficult for vendors to allow themselves to be guided by other motivations (commercial, PR, etc)
- making flaws public under strict rules will allow for some sort of quality measurement
One exception. Should an exploit of the flaw be found 'in the wild' then the flaw should be made public at once. Because then the pressure is on to find a fix or workaround with as much resources as possible.
Another thing. I don't think that anyone would expect perfect software since that doesn't exist. Flaws will always be part of our lifes because otherwise we wouldn't need so many insurance companies to name just one example. But history has shown us that the most dangerous flaws are still the ones we're not aware of. That's why there must be pressure on the vendors to fix flaws in a timely manner. Which will also help the vendors to ensure that they're prepared to deal with flaws in a timely manner (why allocate time, money and resources to fix flaws in a timely manner if you can find a way to deal with flaws when you want to?).
Here are a few key points:
1st: The guys who write the software should know it better than those who wish to exploit it. Therefore, even if a flaw is released publicly, the software creators should be able to release a patch for before anyone can exploit it. From there on out, it's up to the users to ensure they are up to date.
2nd: An unreported flaw always tends to be an un-patched flaw. How many flaws have we heard about that were first reported to, say Microsoft, then later released into the public domain. Only after the flaw was made public was the vendor willing to admit to the flaw and make a patch for it.
3rd: People who exploit flaws, don't tell anyone about it. That would be counter-productive to their efforts. So if security researchers discover a flaw, it's entirely possible that that particular flaw is already being targeted by virus writers and hackers. If it is only reported to the vendor and not the public, the vendor will surely take their time patching, by which time those wishing to exploit it could have already done the damage.
4th: If a flaw is made public, a virus writer is less likely to want to exploit it since they know a patch will soon be released and their virus would become less damaging.
5th: Publicly reporting flaws shows the public just how many holes their are in their $/£00000 software and helps them to make an informed purchasing decision when they decide to upgrade or migrate. This will cause software writers to write better code and reduce the cost of the software.
In conclusion, making this information public speeds up the process of patching these flaws. It also helps force vendors to create higher quality software. It helps purchasers to make more informed choices and alerts users about possible exploits before the exploit is exploited.
Mitsubishi Motors in Japan hid critical information regarding flaws in high-selling vehicles. They are now no longer, having sold out partly as a result of this behaviour. There is no effective mechanism to ensure that flawed software is rectified, except the mechanism of public disclosure. Surely corporations which earn billions, and which have billions in the bank, have no excuse for not issuing rectifications within hours, not months. Good luck to Mr Autel. eEye Digital's initiative has failed - six months and still no fix? When I visit my hospital and see the software they use, I worry.
Let's face the issue head on! When a company knows of a security flaw in its software and fails to patch it whenever it is discovered, they are acting irresponsibly.
Senario - I discover a flaw and report it to the vendor. Vendor may acknowledge, disregard, or claim need for further research, then sit back and see if the flaw is exploited. The Vendor will select which consumer gets notified and probably use non-disclosure policies to prevent further publication. Then when a non customer (security flaw hunter) posts the flaw, they cry foul, while at the same time knowingly leave many users of their product open to attack.
My thoughts are it is best for all, that these flaws be publicized because just as security researchers find these shortfalls, so can malicious "crackers"; you can bet that the underground communications systems will expose them to a segment of people who will exploit the security flaw.