Vesselin Bontchev

← All papers

Anti-Virus Spamming and the Virus Naming Mess

[Bontchev04b] Virus Bull., June, 2004, pp. 9–11 (Part 1) and July, 2004, pp. 13–15 (Part 2).

1 Introduction

The recent Mydoom disaster (and the recent Sobig.F disaster, and the recent Klez.H disaster, and the recent Swen disaster, and the recent Bagle disaster, and the recent Netsky disaster – well, I’m sure you’re getting my drift) caused significant indignation among the computer users. Some of them, more outspoken than others, even published articles on this subject ([1], [2]), in which they expressed their discontent.

Interestingly enough, the users didn’t seem to have much of a problem with the fact that we, the anti-virus people, were essentially incapable of stopping, let alone preventing, the global pandemics caused by these viruses. Apparently, by now the users have become accustomed to the fact that known-virus scanners are able to detect only known viruses (and can do that reasonably well only if kept up-to-date). They are essentially useless against new viruses and, as such, are the weakest kind of anti-virus defense. Still, it is somewhat astonishing to the author of these lines that the users would rather resign to using an extremely weak line of defense instead of bothering to acquire the somewhat higher level of knowledge and expertise, needed to use more advanced kinds of anti-virus products – ones based on integrity checking, behavior blocking, heuristic analysis, and so on.

No, the indignation expressed in the articles mentioned above was aimed mainly towards two different problems. Namely, that (a) the various e-mail scanners tended to flood their mailboxes with unsolicited warnings that they had sent a virus (which they had not) and (b) that the anti-virus industry seems incapable of getting its collective act together and agreeing on a common name for the virus their products report.

While some of the arguments expressed on these two subjects in the articles mentioned above do not lack a certain merit, it seems that the users are (as usual) misunderstanding the issue, not realizing what the real problem is and, in general, missing the point.

In this short article we shall try to address these two issues in detail.

2 Anti-virus Spamming

The problem here is caused by the fact that many mass-mailing viruses nowadays spoof the contents of the envelope sender, as well as the From: header of the e-mail messages they use to distribute themselves. When a large pandemic caused by a mass-mailer occurs, it is annoying enough that people receive a large number of virus-containing e-mail messages, many of them seemingly coming from people they know. Some of these apparent senders might not even be infected – the virus has snatched their e-mail address from some infected machine and is using it in a fake From: field of the e-mail messages it is sending.

In addition, however, the mailboxes of the users are also overflown with scores other irrelevant messages related to the virus. Many of them seemingly come from e-mail scanning products, which are eager to notify the apparent sender of the virus-containing message that he or she has just sent a virus. As explained above, this apparent sender is not necessarily the real one and it tends to be really annoying if somebody keeps accusing you for spreading viruses – especially when you know perfectly well that you aren’t.

It is certainly true that some anti-virus products for e-mail scanning are guilty of such kind of spamming. This is usually the result of the fact that, in their default configuration, these products send such warnings to the apparent sender of the virus-containing messages – and most users don’t bother to use such products in anything but their default configuration. It is also true that at least in some cases the bad decision of designing the product to behave like that has been made for marketing reasons. In other words, its producers know perfectly well that a large number of people will get these “warnings”, that some of these people are not infected – but they consider that this is a form of wide advertising that might be beneficial for their product.

The big picture, however, is a bit more complex.

First of all, definitely not all anti-virus products behave in such an irresponsible manner. For instance, the e-mail scanning product produced by the company that the author of this article works for, is controlled by, among other things, a special configuration file. This file contains the names of the viruses, for which the scanner is allowed to send a warning to the apparent sender, if it finds this virus in an e-mail message. By default (i.e., if the name of the virus found in the e-mail message is not found in this configuration file), no such warning is sent. Furthermore, we never put in this file names of viruses that are known to spoof the sender of the e-mail messages they use to distribute themselves. Our company stands very much for responsible behavior in this aspect, as can be witnessed by the two open letters published by the company’s owner ([3], [4]). Nevertheless, as we shall explain in a moment, the users can get e-mail warnings apparently coming from our scanner, even when they haven’t sent any viruses whatsoever from their machines – although it is not our fault.

Second, the “irrelevant” virus-related messages mentioned above do not include only warnings from virus scanners. A large percentage of them is caused by messages, which have bounced. The bouncing can occur either because the contents of the envelope recipient of the message sent by the virus is invalid (i.e., that e-mail address no longer exists), or because the mailbox of the recipient is full (with other copies of the virus, warnings from e-mail scanners, and other such stuff). In both cases, while these messages are clearly annoying to the user who receives them (and in many cases they are even dangerous, because they contain a full copy of the message that was bounced, together with the virus in it), they are clearly not the fault of any anti-virus software and there is nothing the anti-virus producers could do, in order to prevent them.

But let us return to the promised explanation of why, even though our product is designed in a “responsible” manner, the users can still get annoying virus warnings apparently coming from it. Essentially, there are two main reasons.

First of all, there are many Open Source e-mail filters out there which can be configured to use almost any command-line-driven anti-virus product to scan the e-mail. In particular, they can be configured to use our scanner – in fact, this is the main way the various *nix versions of our product are used. Among other things, these e-mail filtering products can be (and often are) configured to send e-mail warnings to the apparent sender of a message in which the scanner they use has detected a virus. The e-mail filtering products often use some kind of report from the scanner in the warnings they send. So, from the point of view of the recipient of the warning, it seems as if the warning has been sent by our scanner – while, in fact, our scanner is perfectly innocent and the thing to blame is the bad design of the e-mail filtering product that is using it.

What is needed, in order to solve this problem, is some kind of standard (RFC?) that specifies how e-mail filters should react, what kind of notices they should send to the apparent sender, how to format these notices in order to make it perfectly clear who and why is sending them, and so on.

The second cause for unwanted virus-related warnings lies in the way the e-mail (SMTP) servers are designed. In particular, if, for some reason, the SMTP server decides that it cannot accept the message sent to it, the specification of how such servers are to be designed ([6]) requires that the server sends back at least a partial copy of the original message, together with some note that indicates why the message was rejected.

At the time when this specification was designed, there were no sender-spoofing e-mail-borne viruses. At that time, the only reasons why a message would be rejected were perfectly legitimate errors – invalid e-mail address, full disk quotas, and so on. In such cases it makes perfect sense to send back the complete message with all the headers it has accumulated – so that its sender can (a) know that the message was not received and (b) try to determine why it hasn’t been received and (c) how far it has reached (the latter two – by examining the headers).

Nowadays, however, things are, shall we say, a bit more complicated. To begin with, the apparent sender is not necessarily the one from which the message has originated – e.g., because a sender-spoofing mass-mailing virus has spoofed the contents of the envelope sender. In addition, there are many new reasons why the SMTP server might have deemed the message as unacceptable. For instance, it could contain an attachment with extension, which the recipient has decided to block (because files with such extensions often carry various forms of malware). Or it could have Subject: and/or body contents which identify it as being sent by a known virus. In such cases the SMTP server usually sends back a short notice, indicating that the message contained some unacceptable contents and has been refused. But the person receiving this notice is usually not responsible for sending it – and, worse, he or she receives the whole original message (together with the virus, which makes it not only annoying and big but also dangerous).

Clearly, in such cases the anti-virus producers are not to blame for the problem. What is needed, in order to solve it, is a change to the SMTP server specification, allowing it to silently drop messages that conform to particular conditions – without the nowadays obligatory bounce and without any notifications of the apparent sender.

Alternatively, the specification of e-mail must be changed, so that the sender is always authenticated in a way which is both unambiguous and impossible to spoof. This way the warnings will be send to the actual senders only – i.e., only to the users who are really infected. However, this requires a significant effort and will be incompatible with many existing systems, so I do not expect to see it implemented any time soon.

3 The Virus Naming Mess

The other problem that the users seem to have each time there is an explosion of a new mass-mailing virus, is that the anti-virus industry is seemingly incapable of coming up with and agreeing on a single, common name for it. In fact, the author of one of the quoted articles ([2]) even waxed nostalgic over the good old days when “simple names like ‘Jerusalem’, ‘Michelangelo’ and ‘Stoned’ were accepted and used by all anti-virus vendors and their products”. Most users perceive as the main cause for this problem the apparent lack of standard in virus naming. As usual, they are wrong.

First of all, as one who has worked in this field for almost 16 years already, the author of this article can assure you that these “good old days” are nothing but a figment of the imagination of the author of the referenced article. “Accepted and used by all”?! Gimme a break! For instance, the “Jerusalem” virus was also known as “Friday the 13th”, “Black Friday”, “Israeli”, “Haifa”, “PLO”, “1813”, “Russian”, “Arab Star”, “Black Box”, “Black Window”, “Hebrew University” and under many more other, more obscure names. The “Stoned” virus was also called “Marijuana”, “New Zealand”, “Hawaii”, “San Diego”, and so on.

Dr. Alan Solomon, a leading anti-virus researcher at the time, had a rather funny experience with this. A concerned customer called him from Spain. You see, she was using several different virus scanners and they had found several different viruses on her machine – “Spanish”, “Telecom”, “Telefonica”, “Campana” and a few others. Then she had used one of the scanners to remove one of these viruses - and suddenly all the other scanners had stopped detecting anything! So, she was concerned that these “other viruses” had detected that she had “killed” their friend and were now “hiding”. The truth, of course, was that all these names were simply different aliases for one and the same virus and when that virus had been removed, all scanners had stopped detecting any additional viruses on that user’s machine.

The above story is from the mid-90s. As you can see, the virus naming confusion is far from anything new. In fact, the situation has much improved since. Nowadays we rarely have more than 2-3 different names for the same virus - and these usually only for the “urgent”, explosive spreaders, when there is no time to play the naming synchronization game.

Second, a de facto standard for naming virus does exist – has, in fact, existed since 1991!. The author of this article should know, for he was one of those who developed it. It is called the CARO Virus Naming Scheme. While it is not an official standard (CARO is not a standard-setting body), it is the approach which is currently the most widely used one among the anti-virus products. And while there have been recent criticisms of this naming scheme, including on the pages of “Virus Bulletin” (and mostly by people who clearly do not understand properly all the issues involved), it is still the best thing that has been created for this purpose. But promoting a particular virus naming standard or criticizing its critics is not the point of this article. Its point is to explain that the current virus naming mess would exist no matter how good a virus naming scheme is developed. The rest of this article will try to explain why this is so.

3.1 Glut

In the “good old days” (i.e., until the mid-90s) when there were “only” a couple of thousand known viruses, the anti-virus researchers responsible for maintaining the CARO Virus Naming Scheme used to get together at anti-virus conferences, examine how each one of these viruses was called by the main anti-virus products, and agree on what should be the “proper” name for it. Sadly, nowadays, when there are probably more than a hundred thousand known viruses (and when nobody can tell you the exact number of known viruses with a margin of error smaller than ten thousand), this is no longer humanly possible.

While tools like VGrep (for cross-referencing virus names across the different anti-virus products; see [7]) are a significant improvement to what we had in the old days, the glut of new viruses has nevertheless succeeded to overwhelm our capabilities. Therefore, it is simply unrealistic to expect that a standard agreement can be reached among the anti-virus producers over the name of every single virus in existence.

A somewhat useful idea would be to reach such an agreement at least on the names of the viruses known to be in-the-wild. Sadly, no one really knows which are these viruses, either. As argued in [5], the so-called WildList is actually nothing of the sort. Worse, its maintainers have consistently failed to stick to the currently existing de facto virus naming standard – i.e., to use the proper CARO names for the viruses listed in it – despite the various advice they have received in this aspect.

3.2 Importance Unknown

When a new virus appears, it is usually impossible to predict whether it will spread successfully or not. Certainly, a virus which spreads by e-mail bursts is more likely to become widespread than a non-memory-resident COM-file-only infector. However, there are scores of known mass-mailing viruses that never succeeded spreading. For every mass-mailing worm that sweeps the world, there are scores that never see the light of the day outside our specialized virus collections. Therefore, when a new virus appears, it is impossible to decide correctly and immediately whether it would be one of those everybody will be talking about (and, therefore, worthy of an agreement for a standard name for it) – or whether it will disappear in the virus collections among hundreds of thousands of other obscure viruses, the names of which nobody remembers or cares about.

A solution to this problem would be to agree on a single standard name for every new virus. Unfortunately, as explained in the previous section, this is no longer humanly possible. Alternatively, we could postpone this agreement until we know for sure that the virus is in-the-wild. Unfortunately, there is no reliable source of such information, either, as again mentioned in the previous section. Furthermore, as it will become clear in the next sections, it is often unacceptable to postpone such an agreement (and the implied name change).

Of course, the reader should not be left with the impression that the situation is totally hopeless and the anti-virus people are too stupid to do anything whatsoever about it. The truth is that we are doing something about it. There are specialized forums (e.g., AVED, VCircle, VTech, etc.) where we report the new viruses which, in our estimation, are likely to become “problematic” (i.e., widespread). We use these forums to send each other samples of these viruses, to discuss what their names should be, and so on. The point is, that way too often this is not sufficient to solve the naming mess.

3.3 Rush to Publish

When a new mass-mailing virus appears, it often spreads explosively. Gone are the days when computer viruses needed months to spread from one country to another. In fact, gone are the days of the Melissa virus, when they needed just a couple of days to spread all over the world. Nowadays, viruses often need just hours (and, in some rare occasions, even minutes!) to spread like wildfire from South Korea to the USA and back.

When such a virus appears, we, the anti-virus producers are under extreme pressure. We have very little time before the support phones start “smoking” with calls from all over the world – both from people infected with the virus and from people who are just concerned about it and want to ask us whether we detect it and, if not, when we’re going to start detecting it. In this short time, we have to:

  1. Figure out how to detect the virus. This can be problematic, if the virus uses extreme levels of polymorphism, entry point obfuscation, or just weird tricks like spreading itself in password-protected archives or not residing in files at all (e.g., CodeRed).

  2. Replicate the virus. This is often a non-trivial and time-consuming task. Viruses which have no problems spreading in the wild are often capricious and refuse to replicate in a controlled laboratory environment.

  3. Figure out how to remove the virus. This is often much more difficult (although usually less urgent) than merely detecting it, especially when it involves precarious modifications to the Registry and some of the system DLLs. Sometimes a detailed analysis of the virus is required, in order to figure out how to perform this task properly.

  4. Publish an update of our scanner that can handle the new virus properly. Sometimes publishing a detection-only update is good enough and proper identification and removal can be made available later.

  5. Analyze the virus. Often this is a rather non-trivial task. Gone are the days of small, elegant viruses written in assembly language which were fun to analyze. Nowadays the “problematic” viruses tend to consist of tens of kilobytes of some compiled obscure high-level language (often additionally compressed with some sort of executable file compressor).

  6. Publish a description of the virus on our Web site and sometimes send an alert to our users.

  7. Send a sample of the virus to other anti-virus researchers. In the case of an explosively spreading virus is might be even unnecessary – because, by the time we get around to actually doing it, the other anti-virus companies have already received a sample. Thousands of them, as a matter of fact.

Many of these things (detecting the virus, describing the virus, etc.) require that we pick some name for the virus. In the rush to perform all these things (remember – the virus is already spreading fast all over the world and the phones are smoking!), we are forced to pick quickly some acceptable name for the virus. We simply cannot afford the time to discuss the issue with other anti-virus producers, to agree on a common name, and so on. Such niceties take days; we have but minutes.

Of course, we are doing some things to alleviate this problem. The CARO Virus Naming scheme gives us a set of guidelines about how to pick the name for a new virus (and especially how not to name it). We have an informal agreement that the first researcher who sends a new virus to the rest of us under some acceptable name (i.e., a name which does not violate the naming guidelines and which properly classifies the virus in the right family) has “priority” – i.e., the other producers have to accept “his” name and use it in their products. We run a set of scanners, in order to see whether there is a majority (or at least a high percentage) of products that already report the virus under some common name – or that recognize it as a variant of a known virus family.

However, in many cases, our best efforts simply fail. With explosively spreading viruses we sometimes have cases when several anti-virus researchers pick equally acceptable but different names for the same virus and send it almost simultaneously. Of course, with proper discussion we can always resolve what the proper name should be – but in the rush, we simply don’t have the time for it before we have to publish something that uses a name for the new virus.

One of the ideas that have been advanced, in order to help alleviate this particular problem, is to have some kind of list of “pre-approved names” for future viruses – just like the meteorologists keep a list of names for the future hurricanes. Then, when a virus appears, a name should be picked for it that is next in order on this list. In order to reduce the size of such a list and the work involved, this should be done only for the viruses that spread in-the-wild. Unfortunately, this idea has many deficiencies.

First of all, hurricanes develop over multiple days and weeks and there is plenty of time to name them. Second, when a hurricane appears, there is little doubt that it is, indeed, a hurricane (or at least a major tropical storm) deserving a name. As opposed to that, when a new virus appears, we generally have no clue whether it will become widespread or not. Third, nobody is likely to misuse a list of known future hurricane names for marketing reasons or for personal fame. However, if such a list of future virus names is established and becomes public knowledge, the anti-virus companies will be hard-pressed by their marketing departments to pick from it the name of any obscure new virus they discover – because they would know that the mere fact that its name comes from “the list” will gain it (and, by association, them) wide press coverage. Likewise, the virus authors are likely to design their viruses in such a way (with appropriate text messages, behavior, and so on), that naming them after one of the names on “the list” is the obvious thing to do (which means that this is what most people will do) – even if the virus doesn’t manage to get widespread.

3.4 Difficult to Change

For many anti-virus producers, once they have picked a name for a virus in their products, it is extremely difficult (and, sometimes, nearly impossible) to change this name at a later time. The original name is most likely already present in the published press release, in the virus description on the anti-virus producer’s Web site, in the virus definition files for the scanner. If the name is suddenly changed (e.g., to a “more appropriate one”; to one required by a newly reached agreement on a standard name for that virus), this will cause a lot of confusion among the users of that anti-virus producer’s product. They will start calling technical support and asking why the “new virus” is suddenly no longer listed as detected by the product or described on the anti-virus producer’s Web site. These additional support issues, especially in the middle of a virus epidemic, are certainly something the anti-virus producers could do without!

In some rare circumstances, the “old” (inappropriate) virus name has already gone to the printed manuals of the anti-virus product. Changing it would not only be difficult and time consuming; it will not only cause confusion – but it would also be rather expensive.

For such reasons, at least some anti-virus producers have a policy to never change the name they have given once to a virus.

3.5 The Stand-Aparts

Then, again, there are those few anti-virus producers who simply refuse to comply with a virus naming standard. It doesn’t really matter what their reasons for such a non-compliance might be. The point is – if a standard isn’t followed (and if there are no ways for its enforcement, it is inevitable that it won’t be followed universally), it simply cannot hope to be of much help in standardizing things.

3.6 Levels of (In)Competence

Another problem is that the anti-virus researcher who receives the new virus has to be competent enough to implement handling (detection, recognition, identification and disinfection) of it – but does not necessarily have to be competent enough to name and classify it properly. Since adding handling of many new viruses is the main thing that our virus labs do, we have invested significant efforts in simplifying the process and in training people who can perform this task.

With the current state of the art in our company and with the internal tools we have, the author of this article can train a reasonably intelligent new employee how to add handling of at least the simplest kinds of new viruses in a couple of days. As opposed to that, learning how to analyze a virus and how to classify and name it properly requires years (if not decades) of experience and hundreds (if not thousands) of analyzed viruses. There are very few anti-virus researchers with the required level of competence for this – and they might not be immediately available when a new, explosively spreading virus appears. Which is why the names of such viruses are sometimes picked by people who simply are not qualified for this particular task – but who are qualified for implementing handling of the new virus and who are under extreme time pressure to do so.

3.7 No Automatic Classification

Another problem, somewhat related to the previous one, is that, for most kinds of viruses, we simply do not have the tools need for automatically identifying and classifying them.

Macro viruses are a fortunate exception of this rule. For them, we have excellent identification tools – tools which are, in fact, so good, that they allow us to share data, that allows us to implement full handling of a new virus without even having seen the virus! By sharing such data on our internal discussion lists we can quickly determine whether a particular virus is a known one or an old one – and we can also quickly see whether we’re all talking about one and the same virus.

Furthermore, we have an excellent tool for classifying macro viruses. It uses a neural network to do it and while it cannot be relied upon blindly, it is often good enough to pinpoint not only the correct family which a new variant should be classified in, but even report the known variant in this family which is the most closely related to the new one. With such tools it is relatively easy to teach even a beginner anti-virus researcher how to classify and name macro viruses properly.

Unfortunately, we simply do not have such tools for the other kinds of viruses – which also leads to the problem outlined in the previous section.

3.8 What’s in a Name?

The virus name that makes the most sense from a scientific point of view is not necessarily the one that would be the most appealing and the easiest to remember by the general public. Consider, for instance the name virus://VBS/VBSWG.J@mm. To a competent anti-virus researcher, this name is quite informative. It tells him or her that the malware named like that is a virus (as opposed to, say, a Trojan horse or some other kind of non-replicating malware), that it is written in VBScript, that it has been generated by the VBSWG virus construction kit, that this is the 10th virus generated by this virus construction kit that was discovered, and that this is a mass-mailing virus. However, for some unfathomable reason, the general public finds the name “Anna_Kournikova” as being more appealing and easier to remember. But the currently used virus naming scheme requires that we classify viruses into families, according to the code similarity of their replication part – so, we’re forced to classify this virus in the VBSWG family.

Of course, a reasonable question is why we didn’t name the family something easier to pronounce and less obscure than “VBSWG” in the first place. The no less reasonable answer is that when this virus construction kit was first discovered, it was nothing more than yet another obscrure, slightly buggy and, in general, remarkably unremarkable virus construction kit, which could be used to construct silly VBScript viruses. So, we gave it an obscure name and forgot about it. Nothing could tell us at the time that the 10th virus generated with it would become a “problem” – and, due to the “glut” problem explained in one of the previous sections, we simply cannot afford the time and effort to pick “nice and easy to remember” names for every new silly virus that appears.

Which leaves us with the problem that some anti-virus producers choose to follow the agreed-upon virus naming scheme and use the “proper, scientific” name for the virus – while others choose to use the name that the press was talking about and which the users were likely to ask about. Both approaches have their own “pros” and “cons” – but the end result is a virus naming mess.

Even worse, quite often new viruses are automatically detected by some “generic” virus definition designed to handle a particular virus family. As a result, the scanners report these viruses as belonging to that family. In some cases this proves a mistake – the virus should really be classified into a different family. However, the producer of the scanner that already detects the virus (albeit under an incorrect name) is usually happy that his product does that before anyone else’s and is not in a big hurry to change the reported name. With time, some products would choose to classify the virus properly – while others won’t bother touching a definition that already detects the virus or will use the “incorrect” name under which the virus is already detected by another product. Or, officially, the virus will be (improperly) “forced” to the old, known family, which would create a precendent and increase the virus naming mess when new variants appear – variants which undoubtedly should not belong to that family but which are quite similar to the particular variant that was “forced” in it.

3.9 Conclusion

The goal of this article was not to provide any neat solutions. Its goal was simply to explain why the problems exist and to point out that no matter how good a virus naming standard we agree on, and no matter how well we design our products in respect of sending (or not) e-mail warnings, these problems are likely to continue plaguing the users for the foreseeable future.

4 References