Fun to Play: WordPress 3.0 Multisite SQL Injection Vulnerability Regression?

One reason why the MU Fork was re-introduced into the WordPress main trunk was that security updates did creep in very slow or not at all. Development went pretty low in the end of the fork. That left it open for attacks that had been fixed months away in the wordpress-single-site-variant main trunk .

Well, most of the MU code has been re-introduced into the wordpress project w/o a review on all known security issues, right? Just in case you didn’t get it, that’s probably the first question you should ask yourself if you’re pro-actively looking for vulnerabilities in wordpress 3.0.

As an insider prior and after release, we made jokes here and there on re-introducing older flaws back to current like going back in time development wise. In public, when asked for, I was communicating to users to not upgrade to 3.0 if they don’t need to. Or in short: Upgrade to wordpress 3.0 only if you run an existing MU site. Just follow the lead: That’s the way wordpress.com did. And you better bet that this was ca. 99.9% of the projects motivation for the 3.0 release when those badly implemented menus or the new theme are considered as some leftover sweets and cheese.

So as some might know I already made security reports on the wordpress codebase and did even provide working patches. But what I have learned by doing so over the last years is that it’s not always fun to provide patches in the wordpress project. And not always productive to say at least. But there should be fun while playing! So the idea of a little game/competition came into my mind.

So instead of me now re-analyzing if a two-and-a-half-year old SQL injection vulnerability has been re-introduced into wordpress 3.0 multisite or not, I just leave some link (Credits: Abel Cheung) here and give the possibility to pick that up for others on a closer look. All I can say is that it might be exploitable but I just do not know nor do I have a POC. And yes, it’s communicated into the project, so this info is already publicly available in the moment my post get’s published.

The WordPress 3.0 Multisite Vulenrability Regression Hunt

The games rules: Don’t jump the gun until you can provide a working POC. Send the information via my contact form containing all needed information:

1. Title, Date and Link to the original Report (either WP MU or WP)
2. Information about your current finding, the report and the proof of concept.
3. The nickname of you or your team that should be used in the summary.

Any single person or a group of persons can take part. Players/Groups should announce that they want to take part by sending a short info prior making their first report. E.g. they can just register and then make reports later. That’s to better handle the game.

For each vulnerability reported first, the reporting player/group will get one point minimum. There can be more than one point per report, the number of points is based on the fact of date when the original exploit was reported first. The maximum number of points will be given to the oldest documented vulnerability that has been re-introduced. The number of points will be divided by two for the second oldest one and so on until the most recent one will have one point.

New Exploits are not accepted.

This game runs as long as WordPress Development is on hold (currently something like the first week in september 2010) plus 4 weeks.

The decision is final.

Winning Players/Teams will be announced after finishing the raffle. Teams are allowed to provide patches to the WP project while the game is running w/o influencing their score if they had already reported the issue via the contact form. If not they might risk to loose points to other players, e.g. if another team is re-using publicly available information to make a report first, they will get the points.

WordPress Security Related: The short memory of WordPress.org security (by hakre; 16 Feb 2010)