The backdooring of WordPress

The backdooring of WordPress

All of this is written without any special knowledge, contributions by the WordPress maintainers would be welcome...

1. There was no way for this backdoor to propagate into later versions of WordPress because it was simply inserted into a tarball, the Subversion server with version history in it was unaffected and of course new versions are extracted from that server, not by merging patches with old tarballs.

2. At least one major web host offered the affected WordPress version as a "one click install" feature of their product, this affected hundreds and maybe thousands of their customers. It would be nice to be able to point them at a verification procedure that could have saved them this disaster, but for WordPress no such verification procedure existed.

3. This re-asserts the importance of signed packages for ordinary users, and of trust management for Free Software projects. This is a hard problem. Red Hat can afford to buy specialised hardware and assign an engineer to modify the software for signing RPMs, but small community projects may not have anywhere better than a Sourceforge account or a web server to keep their private GnuPG signing key, and that's almost worse than nothing.

4. It's easy to speculate that "user level access" was obtained by the cracker simply telling the project that he wanted to help in some way. Any volunteer project is vulnerable to untrustworthy people. The project leaders might even have thought (mistakenly) that giving someone user privileges on their web server was /less/ dangerous than giving them SVN commit privileges.

5. I don't see any explanation for how "user level access" escalated to the ability to replace the existing WordPress downloaded. Does this mean that the "user" in question was the webmaster account? If not did the cracker use a known userspace vulnerability to escalate themselves to root? Or were the affected files carelessly left with open write permissions?