Creating virii and worms to hunt down other virii and worms has been repeatedly discussed (though not here, that I'm aware) and repeatedly shot down. These ideas die for good reason.

You cannot predict where your targets are. If you could, you'd just go there and root them out. Therefore, you cannot predict where your "immune system worm" will go. There's the first problem: you have to build in a certain level of unpredictability. As you mentioned, this could have a significant impact on mail servers. Now others will need to build defences against your defences? I wonder what would happen if they fight your "immune system worms" with still more worms...?

Next problem: remember the Morris Worm? It was supposed to be benign. The more things that you need your code to do, the more likely it is to have bugs. Now what we have is a piece of software with an inherently umpredictable migration pattern and that software will have bugs! Note that I didn't say "might". It will be complicated and it will have bugs. Whether or not those bugs are significant is another story. So now we have unpredictable, buggy code out there.

Next problem: you've created your buggy code to travel over the 'Net on Seek out and destroy missions. Crackers are going to have fun taking your code and modifying it to seek out and destroy what they want. Or maybe they just attach virii to your worm and sit back and watch.

Interesting idea, but too many problems. Curious, though, I heard a rumor that Microsoft was thinking about adopting this tactic to deal with Code Red. I certainly hope someone talked sense into them. Don't release worms to fight worms.

Cheers,
Ovid

Update: Here's and interesting link on the problems with creating such technologies.

Vote for paco!

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

I'd like to address these points from the other point of view.

You cannot predict where your targets are. ... Therefore, you cannot predict where your "immune system worm" will go.

This is a good thing. Any sufficiently-complicated system will be "unpredictable", in that given a surface-level snapshot of a given state and a surface-level look at the stimuli, you cannot with certainty predict the next state. All we can do is say "It is likely that the system will move in this direction, probably hitting these states along the way."

For example, we cannot predict the path a given packet will take to get from point A to point B, even in a small network. In fact, we don't want to be able to do that! We want the system to "think for itself", so to speak.

Now what we have is a piece of software with an inherently umpredictable migration pattern and that software will have bugs!

First off, you just described Windows. It's a piece of software that does way too much, we can't predict where it will be, and it has bugs. So what?

Every complex piece of software is reasonably certain to have bugs. The trick is to minimize the number and the impact of those bugs. You know the usual methods - packages, objects, testing, etc. This really is a non-objection.

Crackers are going to have fun taking your code and modifying it to seek out and destroy what they want.

This is a more complicated objection to deal with. The first, obvious, answer is to have your anti-virus make sure that any program that says it's the anti-virus passes certain criteria when checked. Things like size, checksums, etc. That would keep a lot of the silliness in check.

However, a better answer is to reformulate the idea. Instead of an anti-virus that goes around killing other virii, instead it should go around closing security holes.

Yes, I know this is an intrusion into other peoples' systems and changing stuff around, but my response to that is twofold:

1. Their systems are compromised, and thus are a threat to my systems.
2. They may not be aware that this loophole exists, and may never be aware that it was fixed.

Interesting idea, but too many problems.

That's what they said about GUI OS'es, the airplane, and the re-useable spacecraft, as well as irrigation, I suppose. I seriously hope that this isn't the answer we will give in the future. Instead of dismissing an idea, how about working it over? How about coming up with possibilities? Maybe, the idea as initially presented doesn't work very well, if at all. I know 99.999% of my ideas never work at first. It's only after they've been hashed out and tested and retested and thrown out and brought back that they become useable. E-bitch has a good idea, one I (and thousands of other programmers) have thought about for a very long time. Maybe it's time that a few of us actually do something about it, instead of giving up and saying "Interesting idea, but too many problems." Very frankly, I give props to Micro$oft for actually thinking about how to make this work. (Never thought I'd say that, huh? *grins*)

------
/me wants to be the brightest bulb in the chandelier!

Well, it was a thought at least. Thanks for the response!

thanks!
E-Bitch

Just like E-Bitch I have an hour+ drive to work, and I also think about computer behavior and patterns in relation to human behavior and patterns. I think that most of E-Bitch's idea's makes sense.

My only issue with his description of human viruses is this:
When I get sick, I dont need to run my virus scanner to get better (thank god).
Doesn't the human "virus scanner" get better? Doesn't it adapt to new viruses and not allow the viruses to re-infect the body? (Not perfectly, but the capability is there, eg. Chicken Pox 'should' only infect you once.)

If I'm way off with this, then I'll apologize in advance, but If I'm not, I think that this is a way to improve on E-Bitch's ideas.

If we started the anti-virus virus with our current knowledge of virus definitions(like the MMR shots children are given), as a starting base. Then the virus can look for infectious behavior on the host system which indicates a hostile virus. Our 'good' virus replaces the hostile virus with a copy of the good virus. This would halt any damage due to the hostile virus. System performance would be impacted(like a human body feels tired, achy, sniffly(is that a word?) and other side effects of a high white blood count). The sys admin or user would then need to kill off the extra copies of the 'good' virus until the system returned to the normal state(Chicken soup, rest and fluids in humans.)

The above process works very much like the human body, which also leads to the problems that human bodies have.

The common cold is a virus, but humans still catch one many, many times, why? The common cold is actually a large amount of viruses, so that even though the human body will probably never get the same virus twice, it can catch each different varity. The same applies to our 'good' virus. It would need to be infected with each differnet virus to defend against it, unless it were smart enough to try and stop similar viruses(see below).

To see another issue we must look at the AIDS virus. There are problems with current treatments for the AIDS virus due to the virus becoming immune to the drugs used in the treatment. Imagine a computer virus that could activly detect our 'good' virus and when discovered would spawn a copy of itself that was modified so that the 'good' virus wouldn't properly identify the hostile virus. Another posibility is a virus that hid in files on the host system, causing our 'good' virus to overwrite infected files. As the hostile virus infected more files to avoid our 'good' virus, our good virus would eventually overwrite every file it could(all files it had permission to write to).

If our 'good' virus were smart, then we could avoid many of the drawbacks mentioned above. The smarter our virus would get the larger and more resource intensive it would become, which may be more harm then more traditional methods of dealing with viruses. Since we want the our virus to be able to automatically update its own virus definitions, then it would probably already be somewhat smart(already large and system intensive). Also if our 'good' virus was this smart, then what's to stop someone from reverse engineering our virus and turning it hostile?

I think that this idea is possible, but that it would need to be very, very, VERY well planned. If the negative aspects were overcome, then the positive aspects would work very well, but if the negative aspects were not delt with, then I can see this being more harm then good.

UPDATE: So I was wrong, please see dragonchild's response to this. If I have time tonight after work, I will try to update this to reflect the correct info.

--xPhase

Your understanding of biology is somewhat flawed. The reason why humans should only get chicken pox once is that the human body creates antibodies specifically designed to deal with that version of chicken pox. That's why the smallpox vaccine (using a deactivated version of cowpox) worked, because the antibodies created to defend against cowpox also worked against smallpox.

Using that paradigm, we should create an antibody for every single virus out there. Or, rather, there should be a "factory", similar to the lymph nodes (I think that's what does this), that would create the antibodies as each virus is encountered.

Now, the problem with HIV is that its target (every virus has one or more target(s) within the body) is the very factory that creates antibodies, which is why so very few people develop an immunity to HIV. (I've heard of two, both well-documented.)

The trick here is that there isn't one monolithic antibody in the human body. There's one for each genetic virus. (Or is it that there's one for every viral action? I dunno.) I guess the trick would be is to create an antibody that would prevent buffer-overflows, for example. Then, every virus that uses that as its entry method would be stymied. (And, no, I have no idea how that would be done, but it's a possible method.)

This would mean that each antibody would be very resource-light, because it only does one thing, and does it well. (Haven't we heard that before, somwhere?)

------
/me wants to be the brightest bulb in the chandelier!

Sorry, getting nitpicky here (and well off the topic, but I thought I'd clear up some common misconceptions).

human body creates antibodies specifically designed

The antibodies are not specifically designed. They are selected because they do not react with self proteins and happen to bind to some "acceptable" surface to activate themselves. (Usually a protein on a bacteria, possibly a viral fragment.) These antibodies are generated totally at random (well, sort of at random, I'm not going to go into exactly how they are made.)

very factory that creates antibodies, which is why so very few people develop an immunity to HIV. (I've heard of two, both well-documented.)

People who are immune to HIV have a T-cell mutation that causes them to be missing the CD4R (IIRC). This keeps HIV from being able to bind to the T Cells. {One of the people who guest lectures on HIV at UCR is immune to HIV. She found this out because her blood would not support viable HIV in culture. (It's hard to get fresh blood in the lab without vampiring your labies.)}

There's one for each genetic virus. (Or is it that there's one for every viral action? I dunno.)

There actually are thousands of antibodies for each virus (maybe millions) because the antibodies do not have a specific fit with the virus. Instead, they fit (I'll ignore the physics and chemistry necessary to understand the concept of "fit") in varying degrees of wellnes. That is, there are some antibodies that totally suck at binding, some that are decent, and some that spend almost all of their time bound to the binding site...

This is main problem with adapting a analog solution to a digital problem is that when you get off by a bit in the digital world, things tend not to work at all. However, in an analog world, you can get away with an awfull lot of slop, just because things still "work" even if they aren't spot on...

I appreciate your correcting my flawed understanding, and I think that based on your new information the idea may still be valid(perhaps even more so).

Thanks,
--xPhase

Subscribing to the update is a purposful thing; it doesn't have to act like a virus. Hmm, except to get it into the hands of people who really need it!

So, we need a mass-inoculation where a copy of a good, free, virus checker is mailed to everyone. That can be smapped once, though, and doesn't need to self-propagate beyond that.

How about a sandboxed "worm interpreter" that allows anti-worms to follow the same migration path as worms, test for their target vulnerabilities, then alert the admin and a trusted third party?

It's a half-baked idea, but some kind of automation is going to have be used to account for lazy/untrained/non-existent admins, which seem to be the majority. Sooner or later, a worm like Code Red is going to get vicious, and I'd hate to lose the use of the net for any significant period of time because a bunch of poorly-maintained, infected PCs go on a rampage.

P.S. I'm thinking this system could work if offered as a service, where the customer could request various degress of response from the provider, including notifying management, send patch notices, etc.

However, I will point out that E-Bitch's comments reminded me of something I found through PM. Check out ZZamboni's home node, and his Ph.D. dissertation at Purdue. It seems to me that it's very closely related, perhaps one could claim even an implementation of your idea. And it's written in Perl.

When I first looked at his work, I thought about asking to be one of his test nodes. I decided that anything less than a few days of study (and possibly much more) would be inadequate for understanding, and I haven't had enough time to put into it, so I've never inquired. But someone a little closer to the problem might be able to show how he addresses some of these problems.

Sorry for the half-baked response. I forgot to grab the coffee on my way through the kitchen this morning ;)

Update: Replaced thesis with dissertation later the same day, as I later realized that thesis was not the right word. Also added commentary that I may not understand Zzamboni's work with only a few days study ;)

There are two main problems I see to this approach. The first, and human in nature, is that people do not like their systems being intruded on and modified. Not for evil, and not for good.

The second, and technical in nature, is that it is extremely difficult (some would say impossible) to ensure the integrity of mobile code (which is what your proposal essentially is). If your program is running on an environment that is completely out of your control, it can have no secrets, and there is no guarantee that it will execute the way you intended it to.

Speaking about the immune system, there has been very interesting work (and a Ph.D. thesis so far) done by Prof. Stephanie Forrest and her group at University of New Mexico, in building intrusion detection systems based on immunology concepts. You can find all the papers at http://www.cs.unm.edu/~immsec/

--ZZamboni

P.S. Thanks to ginseng for pointing me to this thread, and for mentioning my work. My work does not involve mobile entities, but stationary ones that monitor activity at the hosts.

As we have learned over and over human bodies adapt well. Unfortunately, we have also learned that so do viruses. The problem with your idea is not that it wouldn't work (though it would have bugs that would cause other side-effects and be a royal pain to maintain), the major problem is that crackers who write viruses can react to what we send out. They're not going to sit back and say, "oh well, there's no way to defeat that anti-virus software". They're going to get in the middle of it, take it apart, and build something that's immune. Just the way viruses want to live and thrive so they adapt.

Not that we should live in the stone age, but upping the scale of viruses because we tried to create a better anti-virus doesn't sound like a good idea. Maybe in the far future when we have quantum computers that can handle the load of vicious viruses and anti-viruses duking it out constantly such a thing would be feasible. Although then, there would be more shades of gray then 0 and 1 and we could also get a close-fit system working (in theory).

Really, it all comes down to:
Make an idiot-proof widget and someone will make a better idiot.
-or-
Make a hack-proof widget and someone will make a better hacker.

HTH,
jynx

NOTE: thanks to all above material for thoughts :)

update: re-worded quote after thought about what good words to use would be for the re-wording...