I encountered an old acquaintance today. Tip of the hat to Peter Radatti for pointing me towards an article by John Breeden II that proposes a very familiar idea: the Good Virus. (One that also often pops up in the form of the Good Worm, such as the various hues of Code that were proposed
I encountered an old acquaintance today. Tip of the hat to Peter Radatti for pointing me towards an article by John Breeden II that proposes a very familiar idea: the Good Virus. (One that also often pops up in the form of the Good Worm, such as the various hues of Code that were proposed as ways of mitigating the impact of the infamous Code Red.)
Dr. Fred Cohen, who even now casts a long shadow over the anti-malware scene, suggested there "could be … useful applications of viruses" in his "Short Course on Computer Viruses" and "It's Alive!", while the even more influential Dr. Vesselin Bontchev covered more or less all the objections when he asked "Are 'Good' Viruses Still a Bad Idea?", though he made a strong case for automatic AV updating as a viral model. Pretty much how we do it nowadays, too. So is Mr. Breeden on the right track? Well let's look at his idea:
This as-yet unnamed program (I might call it White Knight) would be a self-replicating stealth virus that would only affect computers without virus protection.
Well, the idea of protecting users who aren't protecting themselves might have merit, though you could certainly argue that not having an AV program is not always the same thing as being unprotected (certainly I can see whitelisters, Linux fans and the like making such a claim). But why does it have to be a stealth virus? I guess Breeden is assuming that not having protection is an active decision, not a passive absence of action, which is no doubt true in some cases, but then presupposes White Knight's right to insist that all machines should be protected. Ethically, that is an interesting debate: since the owner of an unprotected but connected machine risks the well-being not only of his own system, but of others, there is an argument that he should be forced to protect his machine (with or without his knowledge). I don't say it's an unequivocally correct argument, but it's certainly a defensible position.
Legally, it's another matter. Of course, legislation to counter malicious action/software can vary immensely from country to country, and even from region to region within a single country. However, it's usual for such legislation to outlaw unauthorized access and/or unauthorized modification, so installation by stealth would, in many jurisdictions, fall at the first hurdle.
In fact, what's being proposed isn't actually full stealth, to use a venerable classification system. Whereas most malware stealth mechanisms are designed to hide from security programs, White Knight wouldn't be intended to hide from AV: Breeden actually suggests that AV companies could be given the code "so that they could protect against it." However, that doesn't meet the legal objection. And in fact, it could be said to compromise the effectiveness of the idea: just as recognizing the EICAR test file doesn't tell you that AV is fully functional, correctly configured and fully updated, nor would recognizing White Knight.
So what would White Knight do? Apparently, it would "protect the registry, the root directory and the memory from other viruses….[and]…common attacks like stack overflows." Well, that sounds like a good idea in principle, but I'm afraid it's very difficult to implement that sort of protection in such a way that it will work safely on any system. And while "standard heuristics-based" security software may indeed do some or or all of this, it usually does a great many other things. Such programs are designed, implemented and maintained by teams because it's too big a job for one guy to do in his spare time any more.
It's true that some of the biggest names in AV research did get into the field by writing their own software to begin with, but those days are gone: the problem is just too big now. And I don't think any of them tried to do it with self-replicating goodware: there are just too many practical problems.
And rather than reinvent the wheel here, I'll summarize some of Bontchev's objections to the "anti-virus virus", though I'll modify his terminology slightly to suit the specifics of this proposal:
- Once the virus is released, the author can't control it.
- Security software that doesn't use program-specific detection (a signature, if you like) won't be able to discriminate between the 'good' virus and 'real' viral malware.
- The third objection is specific to a parasitic virus, and may not be applicable in this case. Mr. Breeden doesn't really discuss his replication mechanism.
- In the event of problems with the code, there is no guaranteed method for locating/removing/fixing all instances of the virus. [I'd say, in fact, that this follows from objection 1.]
- It's liable to cause compatibility issues.
- Even if it functions purely generically, it can't function as effectively by stealth as it would under the control of the user.
- It would be unauthorized. Yes, it's possible to ask permission to "come aboard" and make modifications (some malware has actually done this), but the initial request is unauthorized and potentially disruptive. And that, in any case, is not the stealth proposal in the Breeden article.
- Any modification of copyrighted programs is also a legal violation, quite distinct from the user's authorization.
- Potential for misuse by modification so as to carry a malicious payload.
- It adds weight to the claims of authors of real malware when they claim to be doing something beneficial. In an age of fake antivirus, this is even more pertinent than it was at the time the paper was written.
There's a lot more to the work of Cohen and Bontchev than this, and I recommend heartily that anyone with even a passing interest in the topic should check them out: it's astonishing how the principles they outlined still hold true in the very different threatscape of 2011.
As for White Knight, well, I hate to pour cold water on a well-intended suggestion, but a better name might be Red Queen. While the objections in Dr. Bontchev's paper are not all insurmountable, implementation would take an awful lot of running in order to stay in the same place.
David Harley CITP FBCS CISSP
ESET Senior Research Fellow