WordPress Security: Vulnerabilities in BulletProof Security .51 and Notes on Responsible Disclosure
This entry was posted in Research, WordPress Security on November 6, 2014 by Mark Maunder 7 Replies
Multiple vulnerabilities exist in BulletProof Security version .51 and earlier including an XSS, SQL injection and SSRF vulnerability. The problem has been fixed in version .51.1 and .51.2 which is the newest version. Please upgrade immediately if you are using BulletProof Security .51 or older.
Please note that this appears to be a case of responsible disclosure by researcher Pietro Oliva who reported the issue to the BugTraq mailing list yesterday after giving the developers enough time to fix the issue and release the fix to their customers – and then more importantly, giving the customers 2 weeks to upgrade before disclosure.
This is the kind of disclosure we’d like to see from all security researchers and I know other vendors feel the same way. BPS gives Pietro a shout-out in their Changelog in the version .51.1 release which is the release that contains the fix.
So the process here was:
- Pietro Oliva contacts BPS with vulnerability. Unknown date, but probably a day or two before fix was released.
- BPS releases fix on 10/22/2014.
- Pietro waits 2 weeks exactly and announces vulnerability with full disclosure on the BugTraq mailing list. This gives the vendor’s customers plenty of time to upgrade after the fix is released.
I was recently at WordCamp San Francisco and spent time with other vendor CEO’s like Tony from Sucuri and Cory from iThemes who also provide WordPress security products and services. Also chatted to several other vendors who are either in the security space or considering entering it. These are companies like us that play both roles: We are all vendors of software that may contain vulnerabilities. We are also researchers in the WordPress security and infosec space that disclose vulnerabilities. We think about disclosure and WordPress security from both sides of the table.
I also spent time chatting to a high profile vendor who had a vulnerability disclosed earlier this year in a way they were not happy about.
There is tension between the researcher who wants to get as much press as possible through the disclosure of the vulnerability and the software vendor who wants to be alerted to the existence of a vulnerability but also wants to make sure their customers have enough time to upgrade before the vulnerability is made public to hackers and the infosec (information security) community.
We regularly work with researchers ourselves and the process above that occurred in the BPS case is exactly the same process we’ve used ourselves. Waiting 2 weeks after the fix is released before full disclosure is, in my opinion the perfect compromise between disclosing while the bug is still relevant and giving customers enough time to upgrade.
But I’d like to emphasize a point here: A vulnerability researcher may get more publicity for themselves or their company by disclosing a zero day vulnerability (disclosing before the vendor is notified) or disclosing on the same day the fix is released or sooner than the 2 week window. They will lose friends in the industry and lose a lot of trust and credibility, but it’s important to note that the researcher is sacrificing a gain in notoriety by waiting two weeks.
That is why it’s our duty as vendors to do everything we can to give researchers credit and raise their profile when they follow responsible disclosure procedures. You can do this as a vendor by giving the researcher credit in the changelog and mentioning them on your blog. This helps the researcher take credit for their hard work and helps fund future research by raising their profile in the infosec business community.
When a researcher demonstrates responsible disclosure, it sometimes also leads to direct employment by the vendor themselves or their partners because a level of trust has been established.
I would encourage researchers and vendors to standardize on 2 weeks as the disclosure window for responsible disclosure and if a researcher discloses a vulnerability sooner they should either have very good justification or be shunned by the community.