User: Password:
Subscribe / Log in / New account

Leading items

The backdooring of WordPress

WordPress is, according to its web site, "a state-of-the-art semantic personal publishing platform with a focus on aesthetics, web standards, and usability." In other words, it is yet another weblog platform written in PHP. Like many such platforms, it has a fairly long history of security issues. Even so, the code samples featured in this ifsecure advisory are on the extreme side. One example:

    function get_theme_mcommand($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:

It was determined that a cracker had gained user-level access to one of the servers that powers, and had used that access to modify the download file.

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.

Comments (5 posted)

Who's writing 2.6.21 and related issues

Our article Who wrote 2.6.20?, which appeared two weeks ago, generated a strong response. There is, it seems, a lot of interest in where this code is coming from, but nobody had gotten around to doing the crunching to figure it out. That article calls for a followup in a few ways.

First, those who saw the article early on may want to take another look, as some of the tables have been changed. There was only one serious mistake to fix - one developer's affiliation was incorrectly guessed by the code - but further information has also helped to shrink the "unknown" column somewhat. The original tables can be found from the article (for whatever historical reasons may exist), but the tables in the article itself are the current ones.

The 2.6.21 cycle has moved far enough along as of this writing (the 2.6.21-rc3 prepatch is due any time) that it's worth taking a look at the statistics for the just over 4,000 changesets which have been merged. There are some familiar names here, but some new ones as well. The reflect the different nature of this development cycle, 2.6.21 will have fewer changes in the virtualization area, for example, but it has some significant core changes (like the clockevents and dynamic tick work). A somewhat different set of developers had work ready to merge this time around, and the results show that.

Anyway, the developers with the most work merged this time around are:

Most active 2.6.21 developers
By changesets  By lines changed
Eric W. Biederman1042.5%   Adrian Bunk240976.1%
Ralf Baechle771.9%   Divy Le Ray182554.6%
Adrian Bunk711.7%   Ben Dooks175104.4%
Bob Moore661.6%   Andrew Victor138773.5%
Andrew Morton541.3%   Ralf Baechle99052.5%
Takashi Iwai541.3%   YOSHIFUJI Hideaki95052.4%
Robert P. J. Day531.3%   Steve Wise94182.4%
Jeff Dike521.3%   Jeff Garzik70141.8%
Jiri Slaby511.2%   Vitaly Bordug63871.6%
Ben Dooks501.2%   Thomas Gleixner60781.5%
Tejun Heo481.2%   Bob Moore60551.5%
Al Viro481.2%   Ishizaki Kou59121.5%
David Brownell471.1%   Richard Purdie59091.5%
YOSHIFUJI Hideaki441.1%   Liam Girdwood57731.5%
Mike Isely431.1%   Frank Mandarino52841.3%
Thomas Gleixner380.9%   Jay Cliburn51821.3%
Randy Dunlap380.9%   Tejun Heo51201.3%
Stephen Hemminger360.9%   Kumar Gala50441.3%
Alan Cox350.9%   Martin Schwidefsky47291.2%
Michael Krufky320.8%   Olof Johansson46591.2%

On the side of removing code, the list of names remains about the same:

Developers with the most lines removed
Adrian Bunk2372012.8%
Jeff Garzik68083.7%
Paul Mundt24421.3%
Bob Moore15260.8%
Len Brown12440.7%
Alexey Starikovskiy9870.5%
Jiri Slaby9540.5%
Kenji Kaneshige6610.4%
Eric Sandeen6090.3%
Tim Schmielau5470.3%

Adrian Bunk continues to remove code from the kernel at an amazing rate. Also about the same is the table of signoffs:

Developers with the most signoffs (total 8614)
Andrew Morton100011.6%
Linus Torvalds86510.0%
Jeff Garzik3464.0%
Jaroslav Kysela2242.6%
Greg Kroah-Hartman2242.6%
David Miller2082.4%
Mauro Carvalho Chehab2062.4%
Len Brown2022.3%
Takashi Iwai1872.2%
Ralf Baechle1561.8%
Russell King1531.8%
Paul Mackerras1511.8%
James Bottomley1141.3%
Eric W. Biederman1051.2%
Adrian Bunk991.1%
Andi Kleen941.1%
Alexey Starikovskiy821.0%
Kyle McMartin790.9%
David Brownell780.9%
Ingo Molnar680.8%

The list of developers contributing code to a given kernel release can change over time, but the people through whom those patches pass - the subsystem maintainers - remain about the same. These developers form the infrastructure which does the work of getting reviewed code into the mainline kernel.

Here's the by-employer tables for 2.6.21-rc:

Top contributors by employer
By changesets   By lines changed
(Unknown)110827.1%   (Unknown)8543621.5%
(None)3809.3%   (None)5231213.2%
Red Hat3047.4%   IBM281867.1%
Intel2806.8%   Intel207785.2%
IBM2596.3%   Red Hat190074.8%
Novell2586.3%   Novell187024.7%
Linux Foundation1593.9%   Chelsio183614.6%
Linux Networx1042.5%   Simtec175454.4%
(Consultant)1002.4%   SANPeople139493.5%
Oracle892.2%   MIPS Technologies126463.2%
MIPS Technologies771.9%   Open Grid Computing94422.4%
Google611.5%   MontaVista88612.2%
MontaVista551.3%   Toshiba74621.9%
SGI541.3%   Wolfson Microelectronics73791.9%
Simtec501.2%   Sony70611.8%
Nokia411.0%   Freescale69931.8%
TimeSys380.9%   TimeSys61841.6%
Sony360.9%   Endrelia54211.4%
HP350.9%   Nokia47901.2%
Toshiba340.8%   Renesas Technology47401.2%

Many of the names are the same, but Red Hat does not dominate to quite the same extent as in 2.6.20. The percentage of patches contributed by developers known to be working on their own time has increased slightly.

Finally, some commenters on the original article requested the release of the code used to generate the numbers. Your editor has some qualms about doing so. The biggest among them is not that the code is an embarrassing hack with, presumably, at least one bug still in it. Neither is it the fact that the code could be seen as a competitive tool for LWN; frankly, there's nothing that complicated there.

The biggest worry is related to the attention these numbers drew, and the fact that a couple of developers have mailed in to note that they have received job offers as a result of appearing in the LWN lists. In addition, a few employers have contacted us to be sure that their "account" is credited with the work of all of their employees. The numbers your editor has generated are approximations, but some people clearly see them as being important.

The editors at LWN have an interest in covering the free software community while minimizing the changes that such coverage might cause - most of the time, at least. It seems plausible that, if the "top 20 contributors list" is seen as a desirable place to appear - with positive career benefits - developers might change their behavior as a result. It would be a shame to start seeing kernel patches aimed mainly at increasing a developer's count of lines changed. Such patches, one assumes, would not fare well in the review process, but it would be better if the situation did not come up at all.

The issue of the mapping between developers and their employers is also worth some consideration. Some of that information was obtained directly from the developers with a promise not to disclose it further; that promise must be kept. Beyond that, developers tend to change employers over time, and the code is not currently smart enough to deal with that. This shortcoming is not a problem when looking at a single release cycle, but it clearly would be an issue for multi-year analysis. The code could be improved, but it's not at all clear that the maintenance and distribution of a database of kernel developers' work histories is something LWN wants to get into. There are serious privacy issues to consider.

Despite these worries, the code is being released. In the end, it's not as if somebody else would have all that much trouble reproducing it. Some of the employer information has been taken out in response to the concerns outlined above, though. A tarball of the initial release can be found here; your editor is looking forward to the flood of patches which will improve the system.

Comments (15 posted)

Page editor: Jonathan Corbet
Next page: Security>>

Copyright © 2007, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds