1. Hiatus
2. RIP, Satoru Iwata
3. Let there be Robot Battles
4. Regarding pixel art!
5. 16-bit Star Wars
6. Goodbye, Spock.
7. James Randi Retires
8. More Star Wars on GOG
9. gives you DOS Games
10. Ralph Baer, RIP.
1. Quickie: Impressions June 2014
2. Quickie: Penny Arcade Episode 3
3. Quickie: The Amazing Spider-Man
4. Quickie: Transformers: Fall of Cybertron
5. Quickie: Prototype 2
6. Quickie: Microsoft Kinect
7. Quickie: X-Men Destiny
8. Spider-Man: Edge of Time
9. Quickie: Transformers Dark of the Moon
10. Quickie: Borderlands GOTY
1. Musings 45: Penny Arcade and The Gripping Hand
2. Movie Review: Pacific Rim
3. Movie Review: Wreck-It Ralph
4. Glide Wrapper Repository
5. Movie Review: Winnie The Pooh
6. Musings 44: PC Gaming? Maybe it's on Life Support
7. Video Games Live 2009
8. Movie Review: District 9
9. Musings: Stardock, DRM, and Gamers' Rights
10. Musings: How DRM Hurts PC Gaming
Main Menu

X-bit labs
The Tech Zone
Twin Galaxies


 Log in Problems?
 New User? Sign Up!

Rant: There Is No Such Thing As A Good Virus!
Author: Michael Ahlf 
Date: July 28th 2004
In MSN's Slate magazine this week, Paul Boutin offers up what he considers to be a novel approach to fighting the ravages of computer viruses.

His proposal seems simple on the surface; create a "virus" that, instead of carrying a destructive payload, carries a constructive one, plugging the security hole it got in through.

Unfortunately, his proposal is logically unworkable. It's been proposed virtually every time a new worm gets into the wild and wreaks havoc, too, most notably by loudmouths on sites like Slashdot who either think they know more than they know, or just aren't thinking their proposal through all the way.

It's a fallacy, plain and simple. It's one of those urban legends that the Mythbusters take on every week. If let out into the wild, a "good" virus is either going to be relatively ineffective, or like Nachi it's going to be more destructive than the worm it's designed to counter.

What I'm not going to get into is the possibility of such a worm opening up more security holes - patching a system badly, opening a new security hole, or things like that. Many worms and kiddie scripts today do in fact close their original point of entry behind them, choosing instead to open proxy servers or backdoor services on the new host machine. I'm also not going to get into the moral implications of breaking into someone's computer in order to fix it; similar to breaking into someone's house in order to fix a leaky pipe or faulty smoke detector, your motives may be good, but the person is still going to feel violated. I'm not even going to argue over what happens if someone takes this virus and changes it later, swapping out our beneficial secondary payload for something more destructive.

I'm analyzing this purely from the standpoint of a theoretical, perfect, "beneficial worm." It has no downsides to the user's computer, manages to sit on the system without using any resources, times itself out relatively quickly, and so on. For the moment I'm setting aside the moral dilemma of whether or not it's okay to break into someone else's machine in order to fix it, and whether or not this is "more" okay than the virus writer's breaking into the machine with nefarious intentions. We're just going to look at the logistical possibilities here.

It's still either ineffective, or disastrous, and therefore irresponsible. Why? Because the exact behavior that made the original worm so destructive is what is required to fight it.

Further, in ALL of these events, if a virus writer simply codes their worm to close its own security hole but open up another backdoor, our worm now has to either exploit that new backdoor, or get to machines first in order to secure them. This in itself causes our counter-worm to have to execute multiple attacks on any system it may be trying to patch.

Case #1: Wait, then Respond

The slowest method a counter-worm could use to seek out infected systems is to wait until it attempts to break into the host machine. It sits on the system, using no resources, until it senses the pattern of an attempted break-in. At that point, it'll compromise the infected system, patch it, remove the worm, and install itself so as to wait for the next infected system to try to break in.

Unfortunately, we've got a problem. Many worms don't just break into one system at a time; they scan IP ranges, domain ranges, or just start pinging random IPs hoping to find a machine to get into. Inevitably with this system, someone's going to have multiple copies of our counter-worm trying to get in.

What happens then? Multiple possibilities. The multiple copies of our worm, if there's enough, could act as a DoS attack. This is especially likely if our hapless, unaware user on the infected machine is using dialup - five or six probes from the machine on dialup result in five or six high-speed machines slamming it to get in and patch. The faster our target worm is programmed to spread, too, the more likely this scenario is.

Alternatively, copies of our counter-worm might overwrite or corrupt patches left by others, or corrupt each other as they fight to install themselves. Sensitive programming might help here, but it's still a real concern. Again, this is more likely the faster our target is programmed to move.

The second, and worse problem with this method is its slowness. Most of these worms do the most damage in their first few hours in the wild; once they're on machines, it's a scramble by IT workers and home users to get infected machines cleaned off, but the damage - downtime and loss of productivity - has already been done.

If the virus has only a few machines compromised, our "good" worm is just going to sit and wait. As the virus propagates, the likelihood of its encountering our counter-worm grows higher, but so too does the damage the virus has already done.

By the time our respond-only method has patched all the systems it needs to fix, the worm we're targeting may have been in the wild for weeks, and the damage has already been done. At the most, we've slightly shortened its lifespan. At the worst, since our counter-worm won't be as ideal as I mentioned above, we run the risk of causing more trouble.

Case #2: Slower than the target Worm

If we want to go faster, we have to start probing systems and breaking into them ourselves, installing the patches and possibly removing the worm we're countering. At this point we have only three speed choices; we can move slower than the original worm, at the same speed, or we can move faster, so as to try to overtake it.

If we move slower, we'll patch some systems. We'll cause SOME network traffic slowdown, obviously, because we're using bandwidth to do it; granted, all systems normally have some free overhead, so we can theoretically slow down enough that we're not actually affecting other users of the networks we've infiltrated.

Of course, this isn't very helpful. First of all, we've already given the virus something of a head-start; by the time our counter-worm is coded, there is already going to be a worm in the wild exploiting the backdoor we're patching.

Second, even if we get our counter-worm out at the same time as the virus, it's moving faster than we are. It'll infect systems faster than we patch them. Like the previous method, by the time we get done with patching everyone, we've allowed the virus room to breathe, grow, and infect. The best we've done, again, is shorten its lifespan somewhat.

And then there's the problem of encountering multiple counter-worms. To be effective, our counter-worm has to stay on the system. It has to remain for at least a few weeks past the time it's expected to achieve its objective worldwide; otherwise, modem users, users on vacation, or other machines coming onto the network could just reinfect the entire world after our little counter-worm shuts itself off.

If we get a few - three or four even - of our counter-worms on every machine, all of a sudden that's a LOT of network traffic. We're causing system slowdowns not with one counter-worm, but with the cumulative traffic caused by thousands of systems all infected by multiple counter-worms.

This is a problem.

Case #3: Same speed propagation

Our second possibility, if we're being active with our counter-worm, is to move at the same speed as the worm we're countering. The problems with this are obvious; we're replacing the worm's traffic with our own, virtually bit for bit on the initial probes to other computers.

Yes, we're assuming our own worm is 100% benign to the host computer; the other worm may be carrying a more destructive payload.

In terms of damage to networks and machines being unable to contact other machines we're still no better than the worm we're countering. This is a problem. Even if we do manage to patch all the vulnerable machines and eliminate every instance of our target on the planet, network traffic won't go back to normal until our worm expires on its own.

Case #4: Faster than the target Worm

With this last one, very little might need to be said. We've already got an excellent case study of what happens when a "beneficial" worm moves faster than its target.

The object? Nachi. Last August, an author decided to try to execute our loud, ill-advised friends' advice and coded a counter-worm to combat Blaster worm variants. The Nachi worm moved fast, much faster than any previous variant of Blaster. It invaded machines, removed the files associated with Blaster, and then tried to download and run the patches from Microsoft for the MS03-026 vulnerability, closing the door behind it.

The problem? Quite simply, it did its job too well. It got onto work networks, cable modem and dsl networks, University networks, and nearly completely shut them down with all the ICMP traffic it threw. It DID fulfill its primary goal; within a few days, Blaster variants other than Nachi were almost nowhere to be found. The problem was, Nachi was still looking for them, still trying to get into any unpatched machines it could find. Ultimately, the Nachi worm proved to be far more damaging than the Blaster variants it was trying to counter - and it didn't get onto nearly as many machines as it might have, thanks to alert (and somewhat sleep-deprived by that point) sysadmins and IT workers who were running around, catching and properly patching every machine they could find.

The Result?

The point of this article is to try to explain to some users out there: "counter-worms" ARE STILL WORMS. They are still viruses. Their payload may be "less destructive" than what they're countering, but they're still either destructive towards network traffic, or less than effective at countering the viruses that they are trying to deal with.

Look back on our four examples. These cover all possible speeds of delivering our counter-worm. Every proponent of counter-worm theory states that their ideal version uses far less bandwidth than the worm they're trying to eradicate, but look at the results! True, it's purely an intellectual exercise, but I submit that the findings are correct; if you're not moving faster than the worm - and thus using more bandwidth, since you're exploiting the same backdoor it does - you're not going to catch up to it in time to eradicate it. It's like the cops engaging in a high-speed chase while limiting their own engines to a top speed of 35 mph; the crooks will get away every time.

If, by contrast, you are moving faster than it does, you've already created something that's worse than the original worm.

Again, this leaves aside all the ethical considerations, which have been discussed ad nauseum on other sites: is it ethically okay to crack another's system in order to fix it, without their permission? Some say yes, others say no. The Windows Update feature, obviously, functions on user permissions: the same users who in one breath claim that Microsoft ought to force all users to download patches the moment they are available, are usually the ones scared in the next breath that Microsoft will be shoving DRM down their throats in the latest downloadable patch.

Just please, keep this in mind the next time you hear someone talk about a "good" virus, and maybe we can work on REAL solutions instead of chasing this particular wild goose yet again.

Got Comments? Send 'em to Michael (at)!
Alternatively, post 'em right here for everyone to see!

Rant: There Is No Such Thing As A Good Virus

Added:  Wednesday, July 28, 2004
Reviewer:  Michael Ahlf


[ Back to Articles index ]

Home :: Share Your Story
Site contents copyright Glide Underground.
Want to syndicate our news? Hook in to our RSS Feed.