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.

15 thoughts on “WordPress Security

  1. I not comfortable with #1, I think it’s really a case-by-case judgment call and we shouldn’t let an arbitrary release date keep us from getting fixes out to as many people as possible, as soon as possible. Sometimes our judgment might be to wait, or roll in a few fixes into one release, but as long as you say you may do one immediately as a result of a serious problem the schedule doesn’t really have a point.

    #2 is interesting, but I don’t know that creating a separate branch of the code (or a separate bug tracker) is useful unless there was a problem which required massive code changes from several people and it couldn’t be worked on in public. That has never happened, and I think it’s highly unlikely, but if it did we could create a branch with a simple svn copy and deny public read access in the svn-access.conf file within minutes. Until then, I’d rather keep things simple and unified.

    #3 and #4 partially absolve the commiter from the responsibility of their commits. I think the buck should stop with whoever put the code in the repository, and each of us should be our own security czar. I think that’s far more powerful than putting the responsibility on a third-party.

    Our biggest weakness is with large patches and external libraries. Fortunately our user interests align with our security interests here. . Historically we’ve seen that even though a package might have been available for a while or widely used it probably still has hidden problems. (The sole exception I’d say is KSES.) Saying no to a new package or tangential functionality and sticking to basics in the core provides a more elegant user experience and also can drastically reduce the amount of code we’re responsible for securing

  2. I have to agree with matt here about not being comfortable with #1.

    I would be much more comfortable with a security policy along the lines of:

    A public defined timeline for a fix being released to cover security issues – say fix will be released in n-days from notification
    Security releases should just contain security fixes – this ensures that upgrades are simple and there are no worries for the user that something else has changed

  3. #1 vanishes if we have built-in update notification.

    #2 We just need to get tracking of privately disclosed security issues out of our inboxes. That could be as simple as a private wiki page.

    #3 and #4 should absolutely NOT absolve the commiter from responsibility. Ryan and I did a huge security sweep ~6 months ago (for the attribute_escape() introduction) and we probably discovered and eliminated half-a-dozen XSS holes. If we were only auditing new code, we never would have caught those.

  4. I’m really glad you picked up on Wincent’s post(s) and were able to draw the constructive bits out. I agree that the first post lacked tact – possibly he didn’t realize that you and the rest of the WP team are generally receptive to feedback, and it doesn’t require fireworks to get your attention!

    I agree that a fixed monthly schedule for security updates is a bad idea. It just seems to set you up for 29 days of “possibly needing an emergency update” every month.

    What I’d really like to see is a strict distinction between security patches and release updates. In my opinion, users should never have to take bug fixes and/or enhancements in order to get security fixes. In particular, I note that WordPress frequently releases something (like 2.2, I believe) where a number of changes have occurred, and it’s also a required security update. This puts users who have a good reason for not updating (some bug or change in behavior they discover) in a tough position, because they have to knowingly put off accepting the security fixes.

    Apple’s model of security updates that are independent of OS releases seems like a good path to follow. In a way I think this would also improve the impression of sensitivity to security. If WordPress issues updates that “just happen to fix security issues” it sort of makes it look like they are graduallly fixing security bugs, along with everything else. This may be true, but if dedicated security updates have their own release cycles, then it makes it look like WordPress is exhausting the list of known security bugs as soon as possible and releasing patches as soon as possible.

  5. Note: I realize it’s complicated to issue security patches on a moving target (i.e. over all 2.x installations). So the idea of independent security patches is not exactly a trivial solution. But … think about the spirit of the idea at least 🙂 (Which I’m sure you have before)

  6. A fixed schedule for security releases? What, are you Microsoft?
    As soon as a fix is available- it should be available- Apple does a great job of this. But, an auto-update for security issues would be awesome- ala Firefox.
    I remember there being a battle between Spam Karma’s Dr. Dave and the WP dev team- he thinks everything should have auto-updates. I, for one, think that not having plug-in update notification is a major pain. I just had to go through a whole bunch of sites to check on all the plugins for a bunch of sites- pain in the rear.
    Most important though- is- I’m not sure that the reporting systems for bugs are working- I’ve encountered a whole bunch of problems with the 2.2.1 update- it seems to make the WYSIWG tool bar of TinyMCE disappear. Since new installs work on the server- and only the updates seem to be broken- it seems to be in the update script.
    It seems this has been a problem for some time- and nothing has been done. In the meantime- I’m stuck. If you had had auto update- everyone would be updating close to the same time- and older versions to newer versions wouldn’t be so many different version combos- and it would be easier to track what and when is causing the problems (simplifying everyones life).
    So- please- consider auto-update capability- soon.

  7. I don’t think notification solves the problem, but it takes us to 50% where we’re currently at 10%. WP is a platform, and eventually we’re going to end up with an update system like the other big platforms: Windows, Mac OS X, and Firefox.

  8. I think the big problem with an update schedule is that so many of us rely on the “one button easy install” from our host provider that even if we all knew when an update was coming, we’d still be waiting for our host provider to update the one-button install. A scheduled update release sounds like a good idea but probably just best left ad hoc: release an update when one is available.

    As for the rest of the ideas…again, they sound good on paper but this is free open source software. Keeping that point in mind, is there even enough people dedicated to the project to actually do the security review?

Comments are closed.