Linux worm overrated, 2005-11-09
The latest and greatest Linux worm isn't the most elegant or fastest spreading worm, or even one that's difficult to stop, but it still offers a warning for Web developers and administrators everywhere.
I can't say that it's the most elegant worm ever, it's certainly not the fastest spreading, and I suspect that it is one of the easier ones for the Internet-Powers-That-Be to stop spreading completely -- turn off the IP address that the worm is downloading its code from. Sure, we end up with a cycle where the author moves to another IP and re-releases the worm. But eventually even the most stubborn virus author will get bored with that game.
What's with all the reporting about this worm? Is it just the novelty of a bi-annual Linux worm compared to the systems coming out of Redmond? Or is there more here than meets the eye? I think there is a warning buried here, and maybe we should pay a little attention to it.
In a previous column, I pointed out that Marcus Ranum had some useful advice for these situations. In his opinion piece about the six dumbest ideas in security (I agree with him in case you couldn't tell), he points out that if you ONLY allow URLs that are of a known good structure, you can limit the attack profile immensely. Seems like that would have been good advice here. Different strategies could have accomplished this, running a modified proxy or web accelerator in front of the website is one, but an administrator of a machine could also use mod-security to do some of the work.
I saw some columnists implying that this was a flaw in a Web server, or that this was a flaw in PHP itself, but it's not. The reality is, this was a flaw in a web component that was written in PHP, and the worm itself was a Linux binary. If you decided to run AWStats and not watch for updates, or if you have a PHP application installed that demanded a version of the XML-RPC library and your Linux distribution of choice didn't tell you there was a patch, then you might still be vulnerable. If you weren't running Linux, you might not have been vulnerable to the worm, but you may still have been vulnerable to a one-off attack. Heck, if you were running PHP on Windows, you might still have been vulnerable to exploitation. But once again, the worm wouldn't run.
This is another lesson in how important it is to have a really good idea of what is running on your servers. If you are going to be a Web developer, it's not good enough to simply hack together something that works. Unfortunately, with increasing interactivity demands (AJAX, anyone?) and the decreasing patience of Web users, coupled with more companies wanting to throw the kitchen sink into their Web servers, the complexity of these applications is growing. With this complexity is the chance that an otherwise good admin will not realize they are running a vulnerable library, or something that was installed once and never uninstalled may have been found by an opportunistic attacker.
The XML-RPC vulnerability nags at me whenever I think about it. We have moved to an era where many applications try to ensure that they have the most up to date version available, or at least a security patch isn't available.
For example, Mozilla checks for updates, Microsoft is expanding their auto-update functionality to check on a wider variety of MS software, and SuSE, RedHat and other Linux distributions also have update monitoring tools. Perhaps a good administrator will write a cron job to check for updates to PHP software libraries and applications. What about the RUBY package management system, or Perl, or a simple CGI application.
The expectation from users and administrators is for the update monitoring to be taken care of somehow "automagically." In the era of Web applications, who is supposed to auto-update the Web application? Is this the job of the administrator? What about the libraries that the Web application uses? Should PHP as a language make sure that its libraries are up-to-date? Should PEAR be able to flag packages with a security problem and treat them differently than a regular update? Maybe OpenBSD should write a Web Application. Secure By Default, indeed.
This isn't just an open-source problem, or a Linux problem, or even just a *nix problem. But perhaps open-source Linux is where this problem is the most visible, and it's where the fix should come from first. So, while this Linux worm and its derivatives aren't anything to get too excited about, I am wondering if maybe it's a warning shot across the bow for what's to come.
