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
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 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) Glideunderground.com!
Alternatively, post 'em right here for everyone to see!