WordPress Security

Wincent Colaiuta wrote about the most recent WordPress maintenance upgrade, made some constructive criticism, some unhelpful criticism, and then came to the conclusion that no one should run WordPress, ever. Matt Mullenweg responded with some darts of his own and deflection of some of Wincent’s jabs. Wincent’s constructive criticism got passed over, which to be fair to Matt, is what tends to happen when your constructive criticism comes with a whale-sized side of FUD.

Wincent responded to Matt’s response, and this time without the FUD. This is what Wincent should have written the first time.

I’ll reprint Wincent’s constructive ideas here:

The WordPress team needs to change the way they work with respect to security. This is a very popular, public-facing web application. Instead of springing these forced security updates (“upgrade now or else”) on the masses they should do three or four things:

1. Adopt a regular, public update schedule for security updates so that people can plan and be ready for security updates. Something simple like “first Tuesday of every month”.
2. Have a core-team-only security branch which is merged into the publicly-viewable branches only just before release. More on this point below.
3. Implement a mandatory review process in which every single check-in must pass a security review by another team member; this security-specific review should be in addition to any existing review procedures they might have (emphasis on the might).
4. Appoint a security officer whose responsibilities include a coordinating regular, pro-active audits of the code base.

These are all good ideas. I’ve been on the WordPress security list since February, and it could definitely use some improved workflow. The release schedule is unpredictable, even to me as a developer. There is no system in place for tracking privately disclosed security bugs. Publicly disclosed bugs can go on the bug tracker, but where do privately disclosed bugs go? Well, in the mailboxes of the people on the security list. Proposed and final patches often go in the same place. As for security audits, there have been some, but they could stand to be more regular. And auditing of new code could definitely improve. Trust, but verify.

It doesn’t appear that Trac, our bug-tracking package, supports “hidden” tickets. Perhaps the solution we need is a security-focused Trac install, with access restricted to core developers. That’d provide us with a place to store privately disclosed vulnerabilities and their patches until we were ready to publicly disclose the vulnerabilities by releasing a final version or a release candidate with the fixes. It’d also allow us to better track reporters of vulnerabilities. In the past, these details have sometimes slipped through the cracks, and we’ve failed to properly credit reporters in the announcement post or in the commit message.

A designated “security update” day would be nice… but I’d settle for a pre-announced date.

We have a couple ideas in the works for how we can help squash SQL injection vulnerabilities, in particular. Much as we effectively squashed CSRF vulnerabilities with “nonces” (and a huge effort to implement them throughout the code), the ideas for squashing SQL injection vulnerabilities would help both from a technical standpoint, and because of the thorough code inspection that their implementation would require.

The final thing I’d like to mention that would really help mitigate the problems with WordPress security upgrades is support for upgrade notifications, or even self-updating. The WordPress Dashboard feeds are mangled mess of mostly irrelevant information. There needs to be a clear way of telling WordPress administrators that their installation is vulnerable, and pointing them in right direction for a resolution.

While I wish Wincent’s initial post had been less acerbic and hyperbolic, I do think it’s a good thing that we’re talking about this. WordPress’ incredible success has made it a big target, but in the long run, that increased scrutiny is an asset.