To many software makers and security consultants, flaw finder David Aitel is irresponsible.
The 20-something founder of vulnerability assessment company Immunity hunts down security problems in widely used software products. But unlike an increasing number of researchers, he does not share his findings with the makers of the programs he examines.
Last week, Immunity published an advisory highlighting four security holes in Apple Computer's Mac OS X -- vulnerabilities that the company had known about for seven months but had kept to itself and its customers.
"I don't believe that anyone has an obligation to do quality control for another company," Aitel said. "If you find out some information, we believe you should be able to use that information as you wish."
Despite efforts from Microsoft and other companies to direct how and when security alerts are sent out, independent researchers like Aitel are sticking to their own vision of flaw disclosure.
For them, software companies have become too comfortable in dealing with vulnerabilities -- a situation that has resulted in longer times between the discovery of security holes and the release of patches.
At the heart of the issue is the software industry push for "responsible" disclosure, which calls on researchers to delay the announcement of security holes so that manufacturers have time to patch them. That way, people who use flawed products are protected from attack, the argument goes. But the approach also has benefits for software makers, a security expert pointed out.
"As long as the public doesn't know the flaws are there, why spend the money to fix them quickly?" said Bruce Schneier, chief technology officer at Counterpane Internet Security, a network monitoring company. "Only full disclosure keeps the vendors honest."
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.