Commentary: Code Red is really a vaccine

ZDNet columnist Stephan Somogyi says rather than decrying the evil of a worm like Code Red, we must see what we can do to stop it from actually being worse the next time this happens.

I was originally going to write about Wednesday's anticlimactic Macworld NY keynote (I predict more substantial announcements at Seybold SF and/or Apple Expo, and 10.1's release at the latter show).

I was also going to laud QuickTime 5 for doing such a good job of streaming (it didn't drop the stream during the entire keynote, and recovered from several video dropouts without ever losing audio), and Adobe's increasing corporate meanness (first the KIllustrator PR fiasco, which technically appears not to have been Adobe's fault, and now the arrest of Dmitry Sklyarov), which, distressingly, seems to coincide with the retirement of Adobe's founders.

However, the proliferation of the Code Red worm is just too interesting and multi-faceted to pass up.

I'd read about Code Red over the past few days, but hadn't really thought about it much until a friend of mine noticed strange HTTP traffic on his network. Sure enough, his IP addresses were on the receiving end of Code Red's attempts to find an unpatched IIS server. A quick glance through my own web server logs show 20 attempts total, all on July 19th (UTC).

Interestingly enough, it seems that instead of thanking their lucky stars that they weren't vulnerable, lots of people have been making fun of the affected IIS users. While it may indeed appear foolish to be running IIS given the constant string of exploitable vulnerabilities, I feel like we only just dodged the bullet.

Not just IIS
A stark indicator of this is that Code Red exposed problems in web servers other than IIS. Apparently several of Cisco's DSL modems' web-based configurators become discombobulated when contacted by Code Red. One BugTraq posting mentions the possibility of a causal relationship between Code Red and higher-end Cisco 7500 series routers' misbehavior, another reports the perturbation of an HP printer, and yet another the vexation of a 3Com LAN modem. These are inauspicious data points.

Ladies and gentlemen, the time has come to reward security, penalize the lack thereof, and, for the time being, apply some brakes to the unchecked proliferation of web-accessible widgets. Being able to talk to any device via HTTP is not inherently a Good Thing, and is becoming more like a Bad Thing Indeed with every passing CERT advisory.

It's abundantly clear that the developers of these lightweight web servers aren't building them with security in mind. As we become more dependent on supposedly intelligent devices, these vulnerabilities will come back to bite us manyfold. Unfortunately, customers don't vote with their wallets (or budgets, for that matter) based on products' security. Often, customers might not even have a choice about equipment, as in the case of equipment provided, or even mandated, by a service provider.

In this particular instance, the many, many admins (and users) who didn't apply the patch to their IIS servers--and ignorance is no excuse!--are without question at fault. However, when I wrote about this issue back in March, the reader response was quite clear that the problem is rather more complicated than it appears on the surface. Patches can bring undesired side-effects with them and must therefore be tested before installation. But the systems remain vulnerable during the test period. This is an untenable situation.

OS purveyors in particular need to improve their updating mechanisms by separating security-related patches from functional ones, and finding better ways to get the security patches installed, including building customer confidence that the patches work and won't break anything else. Neither Microsoft nor Apple--the soon-to-be largest volume unix vendor on this planet--have the infrastructure in place to do this.

Assuming this situation continues to deteriorate, we're rapidly approaching the point where a low-hanging legal target will find itself on the receiving end of a suit accusing it, not implausibly, of negligence.

It is be better to be proactive when it comes to security than reactive, as both Microsoft and Apple have been time and time again. Code Red could've been much worse.

Building antibodies from clue
Rather than decrying the evil of Code Red, or downplaying its severity and significance--after all, we made it through unscathed, so why worry?--we must realize how much worse it could've been, and what we can do to stop it from actually being worse the next time this happens.

A vaccine functions by introducing a weakened pathogen into an organism in order to stimulate the organism's immune system. I consider Code Red to be a vaccine, a weakened version of the real thing. It's up to the policy setters, both within software purveyors as well as their customers, to develop clue-based antibodies so that the next time we see a worm like Code Red, it has less, rather than more, effect on the Net.

ZDNet columnist Stephan Somogyi was recently, pleasantly surprised to discover the medical use of 2-octyl cyanoacrylate. He does, however, wish he'd made this particular discovery in a rather less empirical manner.