‘Month of bugs’ drives are successful

I was reading the PHP Security Blog about their month of PHP bugs project (MOPB). According to today’s post they have already been successful in convincing the PHP developers to make changes to their code.

This is what these ‘Month of X’ projects are all about; forcing vendors to recognize that secure code is not an option merely optional any longer.

A lot of people moan and groan that these projects are all about publicity or that they publish trivial vulnerabilities. So what do these nay-sayers propose we do? Sit on our thumbs and maintain the status quo? That we trust the vendor to publish secure code? I hate to say it but that’s what we were doing in the 80′s and 90′s and that’s exactly what facilitated the idea of mass-compromise through worms and the creation of botnets.

I whole-heartedly back these projects as long as their done professionally, i.e. as long as they respect responsible disclosure.

I think of these projects like consumer watchdogs. They take an application out behind the shed, beat it with a 2X4 and see how much it can take. That saves me the trouble of putting the app into production and having the bad guys beat it with a 2X4 and gaining access to the underlying OS.

Kudo’s to the PHP-Security.org team for a much-appreciated service.

For more information about this topic

  • No Related Post

And just imagine how much money in research this can save those companies. You have a lot of free security QA going on with these things.

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:

#6 Why do you provide exploit code, isn’t that irresponsible?

Exploit code is provided because on the one hand some people do not believe that a vulnerability is exploitable (maybe because their attempts failed) and on the other hand the lack of exploit code that tests for a certain vulnerability is the major reason why PHP vulnerabilities are sometimes not correctly fixed or why the same bugs are later reintroduced.

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.

  • Emergent Chaos:

    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…