Responsible Disclosure and Months of Bugs
I had promised myself that I wasn’t going to post about any of the Month of Bugs projects and that everything that needed saying had been said by people far more eloquent than I. But then Michael over at MCW Research came at it from a different angle saying:
I whole-heartedly back these projects as long as their done professionally, i.e. as long as they respect responsible disclosure.
Well Michael, then you shouldn’t be supporting any of the three major projects to date. From the PHP MoB’s FAQ:
4. Does the PHP Security Response Team know about these issues?
They got prior notification for many but not all of the bugs. Therefore some of the bugs are already fixed in the latest PHP releases and some not. Even when PHP developers get prior notice they usually endanger their users by commiting fixes to the PHP CVS tree and then they do not release new security fixed versions for several months.
So not responsible disclosure there. What about the Month of Apple Bugs?
4. Are the issues being reported to the vendor before public disclosure?
Rarely, the point is releasing them without vendor notification. Although, sometimes we may decide to pass an issue through the appropriate people. The problem with so-called ‘responsible disclosure’ is that for some people, it means keeping others on hold for insane amounts of time, even when the fix should be trivial. And the reward (automated responses and euphemism-heavy advisories) doesn’t pay off in the end. ‘Responsible disclosure’ exists when the vendor doesn’t deploy any harmful tactics against the source of the vulnerability reports, and requires confidence by all parties involved. At the moment, we don’t trust Apple on these matters due to the track of incidents and unpleasant situations surrounding their policy on product vulnerability handling.
So not only is MOAB not doing responsible disclosure, they are actively against it. Guess you’re not supporting them either.
Well what about the granddaddy of them all, the Month of Browser Bugs? This one is the trickiest because they don’t specifically call out their process anywhere obvious. However, several of the posts are tagged with dates when the issue was reported to Microsoft. Others say things like that they’ll be added to the OSVB later and contain no date when they were reported to the vendor. I can only assume that they were not.
So, which projects is it that you are supporting again?
This PHP case appears to be special. He is maintaining a special fork of PHP where the bugs are all fixed, I believe.
Or do people not think he should be able to fix bugs in his own software? (At least in the “own” sense of maintaining a distribution. Otherwise you’re also faulting Theo for dropping NetBSD 0-day.)
I stand corrected. I shot a quick post but hadn’t taken the time to do my research. Based on question #6 alone I agree with Arthur that MOPB isn’t being responsible in their disclosure techniques:
That exploit code should certainly be provided to the PHP developers to prove to them the vulnerability exists and is exploitable. But POC code should not be distributed to the public until after the vendor has had a reasonable amount of time to address the vulnerability and has failed to do so and even then it should first be released to IPS/IDS and AV vendors before its released to the public.
I’m not as concerned as Arthur is about the vendor getting a heads-up on these as long as the disclosure is responsible (ergo no public POC code). But again, it looks like MOPB doesn’t adhere to that.
Its a shame…the idea is worth while but obviously not well executed in this case.
I didn’t follow the Month of Browser Bugs too terribly close but I got a sense that it was successful in that it drew a lot of attention to the problems in browsers, which of course is the main point of the whole MOXB idea and the whole reason I find them appealing.
There has to be a way to prod vendors into action without jeopardizing Joe User.
It’s hard to get excited about exploit code when we can provide a billion dollars worth of fraud, and still the vendors won’t respond.
Look at the record: Firefox people have only in the last month or so taken the first definitive, measurable step towards an active posture against phishing, by employing someone with that aim. (And still, Firefox 3 is the planned event…)
Microsoft are just as bad. Even though they woke up earlier to the security failure of the browser … with a little prodding in the form of Bill Gates’ famous memo … their people went straight into a huddle and created a “better than before” green bar … or a track-all-your-URLs database. This puts them further back than Mozilla, as they’ll have to unwind the marketing features to get back to where Firefox is (which hasn’t left the starting gate).
The problem can be characterised as security bug people talking security bugs, and vendors talking public exposure and marketing opportunities. It’s not a debate about security, and won’t be until both sides are willing to talk about security. To be fair, the security bug people are talking about vulnerabilities, not security; even if one side starts talking about security, they’ll quickly realise they are talking to themselves.