Most antivirus professionals will accept a working definition of the term computer virus like this: “a program that replicates by ‘infecting’ other programs, so that they contain a (possibly evolved) copy of the virus.” (F. Cohen: A Short Course on Computer Viruses.)

Note that the emphasis here is on reproduction by infection. A virus is not destructive per se, whereas a destructive program is not a virus per se. Furthermore, although most viruses do attempt to operate without the knowledge of the system user, this isn’t a requirement, either. The only defining characteristic is replication—the primary “intent” of the infective program is to reproduce.

Infection is sometimes described in terms of attachment of the viral program to one or more programs on the target system. However, attachment is perhaps a misleading term, although it is conventionally used in this context because the word attachment has a rather different connotation in the context of email. It might be more useful to look at the process in terms of a chain of command. The viral code is inserted into the chain of command, so that when the legitimate but infected program is run, the viral code is also executed (in some instances, the infected program runs instead of the legitimate code—some viruses and worms replace legitimate files, rather than attaching themselves to them).

We often describe infection in terms of the viral code becoming physically attached to the host program, but this isn’t always the case. Sometimes, the environment is manipulated, so that calling a given program calls the viral program. Sometimes, the viral program is activated before any program is run. This can effectively “infect” every executable file on the system, even though none of those files are actually physically modified. Viruses that take this approach include cluster or File Allocation Table (FAT) viruses, which redirect system pointers to infected files, companion viruses, and viruses that modify the Windows Registry, so that their own code is called before legitimate executables.

Except for a few extraordinarily primitive and destructive examples that actually trash the host program on infection, all viruses work along the following lines:

Companion or spawning viruses follow the same sequence, but the virus code is contained in a separate file, which is characteristically renamed, so that it will be executed instead of the program the victim thought he was launching. It then normally hands over control to the legitimate program.

Viruses that infect by overwriting the host file so that its normal functionality is impaired (or simply replace it) have not been particularly successful at spreading “in the wild,” historically. However, some email viruses have gone against this trend by replacing legitimate program or data files with copies of the malicious program. The “Loveletter” family of viruses used this technique with notable success (in terms of dissemination), often overwriting genuine graphics files such as JPEGs with a malicious Visual Basic script, in combination with the “double extension” trick of appending an extension signifying an executable filetype (in this case .VBS) to the filename, so that Windows recognized it as an executable file rather than as a non-executable data file.

The virus process is a little like the process of biological viral infection, although the analogy is overworked and can be misleading. Think of a person infected with an airborne disease. Whenever he exhales in a public place, he risks infecting others. Similarly, whenever an infected program is executed, the virus’ infective routine also runs, and can infect one or more other objects “in range.” Just as biological viruses infect hosts that are predisposed to infection, computer viruses target certain type of files and system areas, according to the virus type.

Replication is also the defining characteristic of a worm, and some authorities (including Fred Cohen, the “father” of computer virology) regard worms as a subset of the genus virus. However, worms present particular problems of definition. One viable definition distinguishes between worms and viruses in terms of attachment. Whereas a virus in some sense “attaches” to a legitimate program, a worm copies itself across networks and/or systems without attachment. It can be said that the worm infects the environment (an operating system or mail system, for instance), rather than specific infectable objects, such as files.

Some observers have used the term worm to refer to self-replicating malware that spreads across networks. This doesn’t really amount to a meaningful distinction, because many viruses can travel between machines on a Local Area Network, for instance, without being “aware” that a target volume is not on the same machine. This isn’t to say, of course, that viruses are never network-aware.

Some people seem to believe that computer viruses appear spontaneously in the same way that biological viruses seem to do. This isn’t quite as silly as it sounds. Completely new viruses don’t just pop out of the primeval soup without warning. However, it’s not uncommon for a new variant (not necessarily a viable virus in terms of replication and the capability to infect) to be born without direct human intervention. For instance, a macro virus consisting of a fixed number of modules might mutate by losing some of its constituent macros, or gaining unconnected (not necessarily viral) macros. Some Word macro viruses have mutated without human intervention into many hundreds of variants. However, someone had to write the original virus.

It’s not inconceivable that an operating environment might come into general use, in that a viral program can be created from scratch without direct human intervention, but it doesn’t seem to have happened yet.

Most virus writers (and a high percentage of the rest of the world) have an exaggerated view of the ability necessary to produce a working virus. Undoubtedly, some virus writers produce technically competent code—but many more don’t. Furthermore, as we’ve seen, many viruses are one-trick ponies. They might do the replication trick well or not so well, but replication, even when done efficiently, represents a somewhat limited functionality, compared to that of a compiler or business application.

Older viruses were often written in assembly language. In fact, it’s difficult to write some types of viruses in a high-level language, even with the help of an inline assembler. This is an advantage, from the viewpoint of virus victims, in that it takes a certain level of programming expertise to create even a weak virus (or even to modify an existing virus so as to create a variant). Many variants are, in fact, simply existing viruses with a slight change that doesn’t affect functionality (such as modification to unimportant embedded text). Such a change might require no programming at all.

Some virus writers and their admirers still regard proficiency in assembly language as the hallmark of programming excellence. This is actually in sharp contrast to the professional programmer, whose choice of tool, given a choice, is liable to be somewhat more pragmatic, based on the best tool for a given job, rather than a preference for the esoteric. However, the current is, by and large, flowing the other way in malware coding. The most recent and widespread viruses and worms are very often written in high-level languages.

As virus technology developed, some virus programmers turned their attention to creating kits to enable a wannabe virus author to “develop” other viruses without programming—that is, using virus generators to produce virus code. This has not, however, necessarily resulted in an increase in the total number of viruses “in the wild.”

Kit viruses are often not actually viable (that is, they don’t replicate), and are frequently detectable generically. A new kit virus might be identifiable as having been generated by a particular generator, simply by family resemblance. Thus, kit viruses have tended to contribute to the “glut” problem (the sheer weight in numbers), rather than to the “in-the-wild” problem (see the next section).

Certainly, assembly language is not necessarily the language of choice among the current generation of virus writers. Interpreted macro languages (especially Visual Basic for Applications) are generally harder to use than kits, but much easier than assemblers. Furthermore, disk space and main memory are no longer expensive, and grossly bloated files are less conspicuous in a Windows environment. Thus, its become more practical (as well as easier) to write viruses and worms in C++ or Delphi.

A virus is deemed to be “in the wild” when it has escaped or been released into the general population. The general population refers to computing environments outside the development environment where the virus was created and tested, or the collections of antivirus vendors, researchers, and collectors. Viruses in these environments are typically (hopefully) processed under controlled circumstances, where no danger is posed to the surrounding communities. However, when a virus escapes a controlled environment, it might be said to be “in the wild” (often expressed adjectivally in the antivirus community as “In-the-Wild” or “ItW”). Note, however, that in the antivirus community, the fact that a virus is available on a virus exchange bulletin board or Web site does not make it In-the-Wild. Because access to such resources and exchange of viruses is voluntary, this counts as a controlled environment. However, it is perfectly possible for one of these “zoo” viruses to find its way into the wild long ater its author has forgotten about it, simply because someone picked it up off a virus exchange site and catapulted it into the real world.

In his conference paper “Counting Viruses” (Virus Bulletin, 1999), Paul Ducklin makes the distinction very clearly:

In fact, the definition used by the WildList Organization is, historically, far stricter. For a virus to be on the WildList, the nearest thing to an industry standard metric for “In-the-Wildness,” it must be reported by two or more of the virus professionals who report to the WildList Organization. Furthermore, these reports must be accompanied by replicated samples. (Viruses that are reported by only one reporter are put into the supplementary list.) Clearly, this strictness means that the WildList can’t represent all the ItW viruses at a given time, but does represent viruses that are genuinely “out there.” Such data are often more useful than absolute numbers to the organizations and individuals using the WildList as a basis for testing and research. (Note that the WildList indicates a virus’s presence “out there,” but not the total number of virus incidents in which a single virus is implicated. Thus the list only provides a very rough guide to prevalence.)

In fact, the WildList Organization, which has had some financial and resource difficulties recently, seems to have relaxed this rule somewhat as more corporate administrators have joined the ranks of reporters. System administrators who report to WLO are not always able to capture samples, usually because malicious code is discarded before it passes inside their organization’s perimeter. This necessarily entails a change in the quality of information available from WLO. A reporter who cannot capture a sample has to accept that the discarded sample was the virus/ variant the antivirus scanner reported it as being. A discarded sample cannot be verified against a central pool of samples, so its exact identity is unproven. However, reporters with large customer bases do increase the size and volume of virus reports. The organization seems somewhat confused currently in its balancing industry reporters against corporate reporters.

What matters most for our purposes, however, is the disparity between the number of In-the-Wild viruses at one time (a few hundred, according to the prevailing WildList), and the total number of viruses in existence. At the time of this writing, that total is usually taken as being in excess of 70,000, although precise figures are dependent on exactly what is measured. There is no universal standard for distinguishing between viruses, virus variants, worms and other malicious code detected by anti-virus software, and, for technical and administrative reasons, it would be a huge job to enforce such a standard retrospectively by crossmatching samples.

A virus is, conceptually, a simple program. In its simplest form, a direct action virus can be modeled in terms of an algorithm such as the following:

begin 
  Look for (one or more infectable objects) 
    If (none found) 
    then 
      exit 
    else (infect object or objects). 
    endif 
end 

They don’t remain in memory, but execute all their code at once, and then hand over control to the host program.

Many viruses go memory resident (install themselves into memory) after the host program is executed, so that they can infect objects accessed after the infected application has been closed.

The term hybrid is sometimes used for viruses that stay active as long as the host program is running. It is also (perhaps with more justification) applied to viruses that are both direct action and memory resident.

In fact, all viable boot sector infectors are memory resident—they have to be. Otherwise, their code can only be executed during the boot process, which rather limits their opportunities to infect other boot sectors. We’ll consider boot sector viruses in detail later on in this chapter.

Of course, all but the most incompetent viruses are a little better error-trapped than this, and at least check that the infectable object hasn’t already been infected. You’ll notice that I’ve also skated over the infect object subroutine. We’ll come to infection mechanisms when we discuss the main virus types later in this section.

Some viruses, of course, do more than just replicate. We sometimes describe viruses as having up to three components: an infective routine, a payload, and a trigger. The previous models demonstrate an infective routine, although it can be said that finding an infectable object is the trigger for the infective routine. However, we more often think of the trigger as being the condition that has to exist before the payload (or warhead) can be executed.

The payload can, in principle, be any operation that any other program can perform. In real life, however, it tends to be something flippant and irritating, such as visual or audio effects, or else downright destructive. So now our model looks like the following:

begin 
  (Go resident) 
  if (infectable object exists) 
  then 
    if (object is not already infected) 
    then 
    (infect object) 
    endif 
  endif 
  if (trigger condition exists) 
  then 
    (deliver payload) 
  endif 
end 

The trigger condition might, for instance, be the execution of a file, or a particular date or time. The combination of a trigger and a malicious payload is sometimes called a logic bomb, especially in the context of a malicious program with no capability to self-replicate, such as a Trojan horse (covered in Chapter 18, “Trojans”).

Viruses can be classified conveniently (but by no means definitively) into five main classes:

To these classifications we might usefully add memetic viruses, especially virus hoaxes and other types of chain letters, and worms, though the distinction between worms and some of the other types of malware listed above is not absolute. One of the best-known macro viruses, Melissa, is usually described as a worm, as are most VBScript viruses.

There is a further class of virus that is unique, in that it comprises viruses that don’t exist as computer code. The term meme seems to have been coined originally by Richard Dawkins, whose paper “Viruses of the Mind” draws on computer virology as well as on the natural sciences. A meme is a unit of cultural transmission, of replication by imitation, much as a gene is a unit of inheritance (a rather imprecise unit, perhaps). The memes we are most concerned with in this chapter are those sometimes known as metaviruses. A metavirus is itself a virus (what Dawkins calls a “virus of the mind, not a computer virus”), but one that purports to deal with other computer viruses. These viruses don’t exist. In other words, they are virus hoaxes. Virus hoaxes are not only a subclass of memes in general, but a subset of a particular type of meme: the chain letter. However, the virus hoax is particularly relevant to this chapter, because the administrator who manages virus incidents will usually also be the person who has to respond to plagues of virus hoaxes. The same might not be true of other hoaxes and chain letters.

The most commonly encountered hoaxes are derived from the infamous Good Times hoax of the mid-90s. They conform to a pattern much like this:

By the way, as far as I know there is no Green Eggs and Ham virus or hoax. I’ve just done what many real hoaxers have done and pulled a silly title out of thin air (or in this case, my daughter’s bookshelf). In fact, the infuriating aspect of this problem is that most hoaxers are abominably lazy and unoriginal, and the subject of the email that carries the supposed virus is often the only bit of the hoax that varies between two variants.

This sort of hoax only continues to work because masses of people with little technical knowledge of computers (let alone computer viruses) join the Internet community for the first time every day. Each one is at high risk of passing on such a hoax because they don’t know any better. Of course, a hoax can be much subtler than this, but I’m not here to tell you how to write a hoax that might fool even an expert.

Here are a few of the features that will alert the experienced hoax watcher to the unreliability of the Green Eggs and Ham alert:

The 1988 Morris Worm (the Internet Worm) and its siblings, such as WANK and CHRISTMA EXEC, usually targeted heavy-duty mainframe and minicomputer hardware, mail, and operating systems. More recent threats have been aimed primarily at PCs, and in one highly publicized incident (the AutoStart worm), Apple Macs. However, worms might also have the incidental effect of bringing down mail servers through the sheer weight of the traffic they generate. Some of these have been variously classified by different researchers and vendors as viruses, as worms, as virus/worm hybrids, and occasionally as Trojan horses.

Universally accepted classifications of worms don’t yet exist, but Carey Nachenberg, in a paper for the 1999 Virus Bulletin Conference, proposed a classification scheme along the following lines:

As well as proposing classification by transport mechanism, Nachenberg also proposed classification by launching mechanism:

In fact, some of the worms we’ve seen to date are probably better classified as Hybrid-launch Worms (by Nachenberg’s classification scheme) or multipartite (in terms of conventional virus terminology) because they use both self-launching and user-launched mechanisms. Nimda and later members of the Code Red family are hybrid worms, using a variety of techniques to infect and spread.

The following characteristics are not necessarily restricted to particular virus/worm classifications, but are of some importance if only because of the way the terms stealth and polymorphism are so often misused:

The classifications of viral malware described earlier do not cover the entire range of objects detected by antivirus software. Some vendors are quick to point out that what they sell is antivirus software, not anti-malware software. Nonetheless, nowadays most commercial products detect some Trojan horses (see Chapter 18) and other objects that barely qualify as malware, let alone viruses. Such objects include intended (nonfunctioning) viruses, joke programs, DDoS programs, even garbage files that are known to be present in poorly maintained virus collections likely to be used by product reviewers. There are obvious commercial disadvantages to refusing to detect objects that are not viral or even malicious, when products may be marked down in poorly implemented comparative reviews for failing to detect them.

It might be noticeable that this chapter has been largely PC-centric. Certainly, there are more viruses that infect PC platforms (DOS and all flavors of Windows) than any other operating system. Native Macintosh viruses are far fewer. In fact, there are probably more native viruses on systems such as Atari and Amiga that have never had the same popularity (in corporate environments, at least). However, the fact that Macintoshes share with Windows a degree of vulnerability to Microsoft Office macro viruses makes them the other main virus-friendly environment today.

It should not be assumed, however, that other platforms don’t have virus problems. Access controls can be imposed on unprivileged accounts in Unix (including Linux), NT, NetWare, and other platforms to restrict infection flow. However, they can’t prevent unprivileged users from sharing files, if only by email. Nor can they prevent a privileged user from inadvertently spreading infection. Even systems that don’t support any known native viruses (servers or workstations) can carry infected objects between infectable hosts, a process sometimes known as heterogeneous virus transmission. It’s just as important to scan network file servers, intranet, and other Web servers, regardless of their native operating system. In fact, an increasing number of products detect viruses associated with other operating environments. Thus, some Mac products detect PC viruses, and vice versa.

A similar situation has arisen in Linux circles recently, as Linux worms have become more common, and possibly as more PC enthusiasts have taken to running multiple operating systems on a single PC. Indeed, the common hardware architecture hosting both Windows and some Linux versions results in some (limited) potential for cross-platform viral functionality.

Clearly, viruses do represent a risk on the Internet. That risk is higher for those running DOS, any variant of Windows, or certain macro-capable applications, especially the Microsoft Office applications suite. Mostly this is a matter of market share. Most virus writers target PCs and Windows because that’s what they have access to. However, there are other factors that increase the risk: PC hardware architecture, Microsoft’s dismissive stance regarding the need for security on single-user systems, and the dangers of having macro code and data in the same file.

There are some tools to help keep systems safe from virus attacks listed later in this chapter. Be aware though; the only way to guarantee safety is by obeying Richards’ Law of Data Security—don’t buy a computer, and, if you do buy one, don’t turn it on. (A tip of the hat to Robert Slade, my fellow author and collaborator on “Viruses Revealed” for bringing that one to my attention.) Antivirus software is mostly reactive: It responds to a perceived threat, and works most effectively against threats it can identify with precision (known viruses). The best defense against unknown viruses is often to work in an environment that doesn’t provide a host to particular classes of threat. Sadly, however, this is often not an option, particularly in some corporate environments where Microsoft products are considered obligatory.

The NAI range includes the current incarnations of McAfee and Dr. Solomon’s for a wide range of workstation and server platforms, including PCs/Windows, Macintosh, and Unix (including Linux). Visit NAI’s Web site at http://www.nai.com/.

Norton Anti-Virus is available for a wide range of workstation, server, and gateway platforms, including DOS, Macintosh, Windows 9x, and Windows NT/2000/XP. Find out more at http://www.symantec.com.

One of the few remaining desktop products free to some computer users. Visit http://www.grisoft.com for more information.

Eliashim, producer of eSafe and now part of the Aladdin empire, focuses primarily on gateway protection from viruses and other malicious software. Contact them at http://www.eliashim.com/.

Sybari’s groupware security product supports a number of mail server products and configurations. More information is available at http://www.sybari.com.

PC-Cillin by Trend Micro can be found along with their InterScan gateway products at both http://www.antivirus.com/ and http://www.trendmicro.com.

Sophos is focused on the corporate market. Products are available for a wide range of workstation, server, and gateway platforms, including PCs/Windows, Macintosh, and Unix (including Linux). Learn more at http://www.sophos.com/.

A number of products have been based on the F-Prot detection engine. The original product (which is free for personal use, and also available as a commercial product) can be found at http://www.complex.is.

The product formerly sold by DataFellows as F-Prot Professional is now known as F-Secure, and is available at http://www.f-secure.com.

The Command Software version of F-Prot Professional is at http://www.commandcom.com/.

Integrity Master by Stiller Research combines an advanced change detector with conventional known-virus scanning. The Stiller Web site is a good source of general information (hoax information, for example), and is located at http://www.stiller.com/stiller.htm.

There are hundreds of virus scanners and utilities. Those listed here have a good reputation, are easily available on the Internet, and are updated frequently. Viruses are found each day, all over the world. Most of them are unlikely ever to be seen In-the-Wild, but sometimes a formerly quiet virus will suddenly “get lucky” and go feral. New worms and other email-borne viruses such as Melissa or LoveLetter can go from unknown to global within hours. Strange to think that only a few years ago, it was still normal for antivirus software to be updated on a quarterly basis.