Fortunately most PC users don't come across viruses every day of their working life. The average PC support person will typically spend more time reviving dead laser printers, configuring the network, and keeping an eye on their users than dealing with viruses. However, any user who has suffered from a virus outbreak will appreciate just how important it is to be aware of how viruses work, and the methods available to minimize infection.
And therein lies the problem. It's easy to train someone to support a laser printer or a network, but far more difficult to train someone in the subject of viruses. For understandable reasons, most reputable anti-virus researchers are unwilling to supply viruses for such a purpose!* The problem is: 'How do I test my anti-virus product, when I don't have any viruses?'
The purpose of this guide is to answer some of the most common questions about how to test and evaluate anti-virus software. It outlines some of the pitfalls that can be fallen into, and some of the more important functions to check in anti-virus software.
It is our hope that after reading this guide, you will find the job of evaluating anti-virus software a much easier task.
* Several, however, will provide access to their collection under controlled conditions. Dr Solomon's Software has secure labs which you are welcome to ask to use.
The problem for the anti-virus developer is to discriminate reliably between
without having any major impact on the usefulness of the computer.
The problem for the person evaluating anti-virus software is to determine which developer is most successful in discriminating between viruses and non-viruses.
In the anti-virus developers' world, there are two ways of 'playing the game' when it comes to fighting virus authors:
'Play first', in other words, predict what the virus authors are going to do next.
or
'Play second', in other words, react to what the virus authors have already done.
There are obvious advantages to reacting to what the virus authors have done ('playing second'). In this scenario the developer can analyse the virus authors' methods and provide an accurate means of detection, limiting the capacity of the virus to do widespread damage. The vast majority of viruses can be detected by good anti-virus software before they are 'in the wild'. In this sense, anti-virus software is reactive; it is written to counter the threat of specific viruses, which are known and which have been analysed.
'Playing first', on the other hand, can only work if the anti-virus vendor can identify precisely what the virus author is planning. In practice, such predictions are not easy, and can only at best be generalisations.
However, there are ways in which anti-virus vendors can 'steal a match' of the virus authors. By using the experience and knowledge gained in analysing so many viruses (around 300-400 every month), anti-virus researchers are able to build-up a good understanding of the methods used by virus authors. Heuristic analysis (analysing code to determine if it is using virus like techniques) can provide the ability to detect new and unknown viruses.
These can be in the following forms: On-Access, On-Demand, and hardware.
On-access scanners check for viruses when files or floppy disks are "accessed". They are designed to run transparently in the background. When well implemented they should be invisible to the user - they shouldn't even realise they are running an anti-virus product until it intercepts a virus. It has been our experience that on-access scanners are the most popular type of anti-virus product.
On-demand scanners only execute when the user tells them to execute. In other words they only scan for viruses when the user tells them, for example, to scan the floppy disk they have just inserted. The drawback with this method is that users have to remember to scan files and disks for viruses.
Hardware anti-virus products tend to be unpopular. The reason for this is that it is considerably harder to install a hardware card into many hundreds of PCs than it is to install computer software. Furthermore, difficulties may arise if the hardware anti-virus needs to be updated to deal with new threats (macro viruses for example).
These three forms of anti-virus product can be further broken down into the following categories: Scanners, Integrity Checkers, Behaviour Blockers, Heuristic Analysis, and Access Control.
A virus-specific scanner needs to be updated to find the latest viruses. The researchers working at Dr Solomon's Virus Labs estimate that approximately 400 new viruses are being released each month. This isn't necessarily anything to get worried about - the majority of these new viruses are extremely unlikely to become widespread. The problem, however, is that no-one knows which virus will be the next one to 'get lucky'. A virus gets lucky when it is distributed (inadvertently or deliberately), enabling it to get a foothold 'in the wild'. Tequila, Form, WM/Concept and WM/Wazzu are all examples of viruses which have 'got lucky' in this way.
It is impossible to dictate how often a company should update its scanner. However, if an organisation feels it is particularly vulnerable then it would be wise to give the option of, for example, monthly updates. Since the advent of macro viruses (which spread very quickly via the Internet and as e-mail attachments) regular updating has become essential. Anything more regular than monthly upgrades may not be possible on a regular basis because of the amount of testing and quality assurance a reputable anti-virus company would go through before releasing a product.
Some scanners will have problems with polymorphic viruses. Polymorphic viruses are viruses which change their appearance on every infection. There are some viruses which can "change their spots" in thousands of different permutations. Some anti-virus products have experienced difficulty detecting all instances of a particular virus without also detecting a file which is not the virus, causing a false alarm. In this scenario some anti-virus vendors may have deliberately failed to detect all instances of the virus to avoid the problem of false alarms, and the consequential burden on their technical support department.
If a scanner can identify a virus precisely there should be a method to remove the virus. Why disinfect when you have a backup? Imagine the situation where a large network has been infected with a virus. Your users may be unwilling to wait the 'x' hours whilst the backup is restored to the network, your manager may be unhappy that the network is unavailable for so long a period. If the anti-virus product has a reliable disinfect facility, however, then the network can soon be up and running again. The network administrator may then restore the backup directory by directory if he so wishes at a time which does not inconvenience users.
It should be noted that there is a difference between On-Access and On-Demand scanners. Not all On-Access scanners find as many viruses as their On-Demand counterparts (this is in particular true of DOS TSR on-access scanners). Also many On-Access scanners do not include a disinfection capability.
An integrity checker (also known as a checksummer) is a program that determines whether another program has been altered or changed. For a virus infection to occur, executable code needs to have been altered by the virus. An integrity checker searches for such changes and flags them as suspicious.
However, an integrity checker can only flag a change as suspicious, it cannot determine whether it is a genuine virus infection. This is the major drawback of integrity checking. For example, the DOS program SETVER.EXE alters its own executable file, other programs save configuration information about themselves within their own executable. In a software development environment, for example, an integrity checker becomes almost impossible to use as executables are being altered and re-compiled on a regular basis.
To get around this problem, an integrity checker normally includes some option to exclude certain executable files or directories from being checked.
Furthermore integrity checkers cannot recognise all known viruses, let alone the future viruses they might claim to detect. For example, two of the oldest viruses Brain and Denzuk do not infect hard disks. It is impractical to use integrity checkers against floppy disks.
There have also been viruses written which are specifically designed to evade integrity checkers. The virus Starship appears to have been written to deliberately circumvent detection by an integrity checker. The Peach and Encroacher viruses were written to target the security loopholes in integrity checkers from particular anti-virus developers.
For an integrity checker to detect a stealth virus, such as Frodo, a cold boot is typically required (If a stealth virus is in memory it can hide itself from the integrity checker). It has been our experience that most users are extremely reluctant to cold boot their PCs from a clean DOS floppy every day just to run an integrity checker. Furthermore those viruses which are sparse infectors (infect other files infrequently) tend not to be detected until they trigger.
It should also be recognized that integrity checkers are ineffective against macro viruses, such as WM/Concept and XM/Laroux, which infect documents and spreadsheets. The reason for this is that documents and spreadsheets change very often for legitimate reasons. Integrity checkers find it difficult to determine when such a file changes legitimately, and when it changes because of a virus infection. Because macro viruses are now the most common type of virus, it is hard to recommend integrity checkers.
Behaviour blockers work on the following principle: There is a list of rules which legitimate programs follow, and there is a list of rules which viruses follow. If a program breaks one of the legitimate rules (or follows one of the virus rules) then the user is alerted.
The problem is that a virus is simply a program that copies itself. A virus can do anything that a normal program can do. To determine what the rules are is extremely difficult. For example, one rule might be that if a program goes memory resident in an unorthodox way the user should be alerted. Unfortunately some very early TSRs typically used non-standard methods to go memory-resident - at the time it was the standard method! Similarly, a disk formatting program will try to make low level writes to the disk. Should this be flagged as a possible virus?
It is up to the user to decide whether the alert is valid or not. Typically the user sees a message similar to the following:
Goobledygook gobbledygook
Continue YES or NO? (Y/N)
The user is inevitably not equipped with the necessary knowledge to know whether the program should be allowed to continue. They don't understand the warning message. They don't know whether what the program is attempting to do is valid or not, and eventually resort to pressing YES all the time. There is no discrimination between a legal and an illegal action. The one time a genuine virus is operating the user will probably press YES. The user has become too accustomed to false alarms.
Since behaviour blockers can be a nuisance there is often a documented way to turn them off. Unfortunately the virus authors are also aware of the methods which can be used to turn behaviour blockers off and some viruses use them.
Because behaviour blockers know nothing about the virus themselves - only the behaviour that viruses exhibit - they cannot reliably disinfect virus infections.
When first encountered behaviour blockers sound like a great idea. When asked, users have confirmed that almost nobody leaves them installed on their PC for longer than a week. The nuisance factor is far too high.
Furthermore, behaviour blockers also face a major difficulty when asked to deal with macro viruses, such as WM/Concept and WM/Wazzu.
Heuristic analysis is the technique of scanning a file for suspicious code and techniques. As discussed earlier, it is very difficult to determine what code is suspicious. The code that might be innocent in one program (for example, FORMAT.COM) might be suspect in a virus infected file.
For this reason, it is necessary for heuristic analysers to calculate how suspicious a file appears. Typically, a scoring system is implemented, and any file which has enough suspicious elements (a high enough score) is flagged as being a possible virus.
There are two major problems with this technique. Firstly, heuristic programs are prone to false alarms. A false alarm is nearly always significantly more trouble and time-consuming than a genuine virus infection. Secondly, heuristic programs are unable to detect every existing virus.
Virus authors are aware of what anti-virus researchers consider to be "suspicious code". Some anti-virus researchers have even released documentation detailing how their scoring system works! With such information it is relatively easy for the virus author to write their virus with this information in mind, thus avoiding detection.
Dr Solomon's have developed Advanced Heuristic Analysis, a technology for detecting new viruses without false alarming. In laboratory tests it has been shown to detect over 80% of new, unknown viruses without a single false alarm. Dr Solomon's does this by employing negative heuristics in its techniques. Negative heuristics keep track of what code and techniques are definitely not indicative of virus infection. Once the positive heuristics have identified a file that could contain a virus, Dr Solomon's checks to see whether it also contains code which is definitely not virus-like. This data is then "weighed", and an accurate conclusion is drawn as to whether the file contains a virus or not.
Dr Solomon's even includes heuristics for detecting new, unknown macro viruses - again without a false alarm problem.
Access control describes a variety of different methods to avoid unauthorised programs being installed on a PC, unauthorised disks being accessed, or unauthorised personnel from using a PC. Through this control the chances of a virus being allowed onto the computer are reduced.
Since access control methods cannot discriminate between viruses and non-viruses another type of anti-virus product has to be incorporated into the system. Access control systems provide an extra degree of security to the PC user, but this can be at the expense of flexibility.
If a virus manages to get past the access control system then it can be more difficult to control its future spread.
The basic task of anti-virus software is to accurately determine what is a virus and what is not a virus, and to remove the virus from the user's system. There are five types of anti-virus software, each adopting a different approach to the problem of identifying and removing viruses: scanners, integrity checkers, behaviour blockers, heuristic analysis, and access control.
The best kind of anti-virus software is a scanner, because it can provide precise identification of known viruses, and exact disinfection. Scanners are also less prone to "false alarms", in which the anti-virus reports a virus when in fact there isn't one. A false alarm is often far more costly than a genuine infection, because the user wastes time and money trying to pinpoint and eliminate a problem that doesn't exist.
There are two types of scanners, "on-demand" scanners, and "on-access" scanners. On-demand scanners are invoked by the user, either directly via user interaction or indirectly, via a scheduler or batch process. The advantage of "on-access" scanners such as Virtual Device Drivers (VxDs) or Terminate and Stay Resident programs (TSRs) is that they can run all the time, transparent to the user. VxDs load via SYSTEM.INI or the Registry, whereas TSRs are installed via the user's AUTOEXEC.BAT or CONFIG.SYS processes. On-access scanners monitor for viruses during the normal opening and saving of files on the user's workstation, requiring no interaction from the user. In fact, users only realise that they are running the scanner when it finds a virus.
Second to scanners in effectiveness are integrity checkers, which can identify tell-tale signs of virus infection, such as file growth and changes to executable code. However, integrity checkers are prone to false alarms, and not effective against the most prevalent type of virus today, the macro virus. This inability to deal well with macro viruses make integrity checkers a poor choice for protection.
While there have been promising attempts to "guess" what virus writers will do next, and to incorporate that logic into software, it is better to "know" what viruses have done, and build detection into a scanner.
There are a number of guidelines to bear in mind when evaluating anti-virus software. Following these rules should help you avoid many of the common traps and pitfalls others have fallen into before.
Golden rules for evaluating an anti-virus scanner Several elements are normally evaluated: speed of scanning, accuracy at finding viruses, false alarm testing, quality of technical support, ease of updating, management facilities (for server based products) and alerting. Occasionally factors such as user interface or ease-of-use may be addressed. Another interesting aspect to evaluate is the product's ability to disinfect virus infections. This document will only look at some of these issues.
Speed of scanning should be tested on a clean, uninfected machine. This is how users will be running the software 99.99% of the time. Some scanners slow down to identify viruses accurately, but this is not seen in the normal everyday operation of scanning a clean machine. It doesn't really matter how long a scanner takes to scan a dirty machine as this will only occur occasionally and, when it does, thoroughness (not speed) is the crucial factor.
Of course this will not be relevant for non-DOS platforms.
One factor that also needs to be born in mind is that of what scanning options should be chosen during a test. The obvious answer is to use the anti-virus product's "default settings". However, different products have different options turned on by default. For example, one scanner may have scanning inside compressed files enabled by default whereas another does not. The former scanner could end up being penalised for running slower.
Another important aspect to test with on-access scanners is the amount of memory they require when resident. This is particularly relevant when users are hoping to use the product in conjunction with memory-hungry network drivers, and so forth.
Viruses 'in the zoo' are those which researchers have not yet seen outside their research environment. It is important to detect these too, as no one knows which viruses will be found in the wild next. Ensuring that a scanner detects all viruses in the wild is of course more important than detecting those not found in the wild.
The purpose of anti-virus software is not really to stop viruses. It's real purpose is to maintain business continuity and allow companies to do what they like to do best - make money! Restoring from a backup may remove the virus, but may also prevent users from doing their jobs for several hours.
We would argue that a more sensible policy for those intending to minimize disruption to their company when dealing with a virus outbreak is to clean-up the network infection with an anti-virus product. This allows people to get on with their work quickly. The system administrator can then decide later whether they wish to restore the infected files from a clean backup at a time which will not inconvenience his users.
From the above it is clear that tests of an anti-virus product's ability to disinfect (as well as detect) virus infections are useful to corporate users. The question that remains is how to test this ability.
Testing a product's ability to detect viruses in memory is simple. The tester makes the virus memory-resident and then runs the anti-virus product to see if it detects the infection.
Testing a product's ability to clean-up viruses reliably, however, is more prone to complications.
Firstly let us consider traditional executable file viruses.
There are some viruses which damage files so badly they cannot be resuscitated. Viruses are written by humans, and humans make mistakes. Viruses have bugs in them and sometimes damage files too badly for *any* product to clean them up. Such viruses should not be used in a disinfection test.
A valid disinfection test would not place extreme importance on returning the infected file to its precise, byte for byte, pre-infected state. Many viruses "pad out" their infected victims to a multiple, say, of 16 bytes. An anti-virus product is unable to tell how much of this "padding" to remove.
The most important thing is once the virus infected file has been repaired does it work? If the infected file is still executable, and executes properly, after the clean-up is complete then the clean-up can be considered to be successful.
Macro file viruses cause other problems. WM/Concept, a Microsoft Word macro virus, is now the most common virus in the world. After initial accidental widespread distribution on CD ROM by Microsoft in the summer of 1995, anti-virus developers rushed to produce both detection and clean-up for this brand new type of virus.
Early fixes to the virus consisted of renaming the macros contained within the virus-infected document so they were no longer active. The drawbacks of this approach were that the virus code remain present in the document - causing the less precise anti-virus products to false alarm on the remains.
The best approach is to use an anti-virus product which understands the Microsoft Word OLE 2 document format, can remove the virus macros (leaving any innocent macros from prior to the infection in place).
Boot sector viruses infect the boot sector of floppy disks and the partition sector (MBR) of hard disks (a few, for example Form, infect the boot sector of the hard disk rather than the partition sector).
Floppy disk infections by boot sector viruses should be capable of being disinfected by an anti-virus product. It is not considered essential to return the diskette to a system-bootable state if it was prior to infection.
Hard disk infections by a boot sector virus should be capable of being disinfected by an anti-virus product (the anti-virus product will be run after a cold-boot from a clean, virus-free, write-protected disk to ensure there is no virus present in memory). In the case of hard disks it is, of course, essential that once disinfected it can still boot up for normal operation. If the hard disk is no longer bootable after repair by the anti-virus then it can hardly be considered a successful clean-up! Some viruses have tried to make such disinfection more difficult (for example, Monkey which encrypts the partition data and One-Half which encrypts cylinders on the hard disk). However, competent anti-virus products should be able to cope with such viruses as they are commonly found "in the wild".
A final test of an anti-virus product's level of sophistication is to test its disinfection capability capabilities against an "in the wild", mutating, polymorphic virus such as SMEG. The more sophisticated anti-virus products will be able to identify a polymorphic virus precisely and they will also contain the necessary technology to return a working, uninfected file. This is an excellent way to measure the quality of the research and development team behind the anti-virus product under evaluation.
Use a reasonable number of viruses. Like a detection test it is next to useless to test against a small number of viruses. The problem, however, is that testing the disinfection capabilities of an anti-virus is more involved than simply testing its detection rate.
If you have access to a virus collection surely it's simple to evaluate which anti-virus scanner is the best? It's the one which finds the most viruses, right? Unfortunately, this isn't necessarily the case.
There are virus collections in existence which have been infiltrated by non-viruses. Put yourself in the hands of the owner of the virus collection. He or she has a very large job on their hands maintaining and updating their collection of viruses. From all round the world suspicious files are being sent to him or her to add to their collection.
The emergence in recent years of VX BBSes (Virus Exchange Bulletin Boards) and large collections on the internet has made the glut of non-viruses even larger. VX BBSes tend to work on the following principle: upload a new virus, and then you can download 'x' number of viruses off our BBS. Some users of Virus Exchange BBSes simply tamper an existing virus and upload that, others attempt to write their own, others still just upload junk.
The viruses they tampered with, or the ones they tried to write on their own, or even the junk files can fall into a virus collection. It may be the virus they tampered with no longer works (for example, it hangs the PC before infecting anything else), it may be the new virus they have written also fails to work for similar reasons. Nevertheless they have entered the anti-virus community as 'suspicious' files.
When a large collection of, say, 5,000 'suspicious' files lands on the desk of an anti-virus researcher there are two ways they can handle the situation.
Firstly, they could build detection for all the files (regardless of whether they are viruses) into their anti-virus package. This is by far the easiest option. The trouble is, you might have copies of FORMAT, CHKDSK, and anti-virus products in the collection, and it is a bad idea to call these viruses.
Alternatively, they could disassemble and examine each file to ascertain whether it is a real virus, before including detection for the file into their anti-virus package. This takes more time, and requires a higher level of expertise.
The irony is that when a detection test is run over the collection, the first anti-virus scanner will find more files which it claims to contain viruses. The second scanner will, if correctly implemented, detect the correct number of viruses in the collection and disregard the junk.
The problem arises, however, when someone tries to evaluate which anti-virus product is the best. The evaluator has no tools for ascertaining which viruses are real viruses, so they tend to believe that the scanner which finds the most viruses is the most competent of the scanners tested. In the scenario described above, it is shown to be the least competent.
There are currently virus collections being distributed (the NCSA collection as of 1992 is a classic case in mind.) which have junk files in them. In more recent times the NCSA collection has been greatly improved. Mark Ludwig's virus collection on CD ROM is occasionally used by reviewers but again includes many non-working files. The problem for the reputable anti-virus vendor is how do they avoid the situation where a worse scanner actually appears to be performing better than them?
Below are listed some good sources for "clean virus collections":
The Virus Test Center at the University of Hamburg (http://agn-www.informatik.uni-hamburg.de/vtc/naveng.htm);
The Virus Test Unit at the University of Tampere, Finland (http://www.uta.fi/laitokset/virus/);
Virus Bulletin (http://www.virusbtn.com);
Secure Computing Magazine (http://www.westcoast.com);
The International Computer Security Association (http://www.icsa.net)
At the time of writing, however, the ICSA virus collection is considerably smaller than that held by the other sources.
When is a virus not a virus? When it's a false alarm!
A false alarm is when an anti-virus product mistakenly identifies an innocent file as containing a virus infection. On first impressions this may seem harmless enough, but think a little deeper. What would you do if you had a false alarm? The first problem is that you don't know you have a false alarm. As far as you are aware the anti-virus product has correctly identified a virus infection on your computer. If you knew it was a defect in the anti-virus software then you would react differently, but all the information at your disposal suggests the more dramatic: YOU HAVE A VIRUS!
If the "infected" file has been found on a network drive and is available to many of your networked users your first reaction may be to shut down the network. That way no more users will be able to access the "infected" file. Shutting down the network costs money in lost work. Imagine how little work you would be able to do without a network.
Of course, the "infection" may not only be on the network. Maybe some users have already executed the "infected" file - they too may be infected. You will have to examine all computers which have access rights to the file to check whether they may be infected as well. Moreover, checking computers for a virus infection costs money, both in terms of the technicians examining the PCs and lost work of the computer users.
And then it doesn't end there - users use floppy disks. Maybe one of them may be infected as well. All will have to be checked for the"virus". Some users will have a few diskettes, others will have hundreds. Checking floppy disks takes even longer than checking individual hard disks, and can be politically embarrassing as you go rummaging in the Chief Executive's drawers for floppies.
Then it's a case of doing a clean-up. You run your anti-virus software over the infection and ask it to repair. To your astonishment it tells you that repair is not possible. You remember reading somewhere that not all infections can be reliably cleaned-up, so you turn to your trusty backup.
However, the nightmare has only just begun. Restoring the "infected" file from the backup reveals that that too is infected!
The sad truth of the matter is that, in the example above, there was no virus infection at all. All the hard work, time and money was brought out by a simple false alarm. In other words, a bug in the anti-virus software which misidentified an innocent file as being virus-infected.
One of the most infamous false alarms occurred in early 1993. A commercial anti-virus product mistakenly identified the brand new version of PKUNZIP.EXE (an extremely popular shareware tool for decompressing archived files) as containing a Maltese Amoeba virus infection.
Word soon spread, and other users of the anti-virus product in question also discovered their copy of PKUNZIP was also infected by this virus. Users of other anti-virus packages were disappointed to find that their anti-virus package had failed to detect this "virus".
Despite the protestations of PKWare (the developers of PKUNZIP) that the file was not infected and that the anti-virus was defective, users still believed the anti-virus was right. Months later users were still reporting how their anti-virus had detected Maltese Amoeba but had been unable to clean-up the infection. Many users went on to tell how they had been forced to delete the file as no repair facility was available.
More recently another anti-virus company has suffered from numerous false alarms claiming that "traces of [xyz] virus has been found in memory". These problems were caused by the anti-virus product no longer being able run correctly in low memory conditions. Rather than failing gracefully (and displaying an appropriate message) the anti-virus product began to act in an erroneous fashion. In the worst instances the anti-virus product claimed that "traces" of Word macro viruses had been found in memory upon DOS bootup - a technical impossibility!
It is commonly accepted that a false alarm can be more costly than a genuine virus infection.
Dr Solomon's Anti-Virus Toolkit has been deliberately designed to minimize the possibility of false alarms, thus avoiding the type of expense outlined above. This has been achieved through a number of methods.
Firstly, Dr Solomon's FindVirus and WinGuard use a very precise virus-finding engine which enables them to identify virus infections with 100% precision. Unlike some other anti-virus software Dr Solomon's is capable of telling you not only which virus you have, but precisely which variant. So, for example, Dr Solomon's can tell you that it has found an infection of "Flip.2153" rather than just "Flip". It does this by calculating a cryptographical checksum on the static bytes (those bytes which are not variable) in the virus code. If that checksum matches the figure stored inside the Dr Solomon's internal database of virus definitions then a precise identification can be guaranteed.
Secondly, Dr Solomon's Anti-Virus Toolkit goes through rigorous testing each month, not just against a large collection of viruses, but also a false alarms test. The false alarms test includes testing against gigabytes of known clean software to see whether any of the files are mistakenly identified as being infected.
Dr Solomon's Anti-Virus Toolkit also includes the ability to detect new and unknown viruses via a system known as Advanced Heuristic Analysis. Some other anti-virus products include a heuristic technique to detect possible new viruses but have been hit by an increased propensity for false alarms. The more sophisticated approach taken by Dr Solomon's means that it is capable of detecting more than 80% of new and unknown viruses without a false alarm problem.
False alarms by anti-virus products can cost large amounts of money and disrupt work in a corporate environment to an astonishing extent. An anti-virus product which false alarms may be bearable on a single PC, but imagine that you were supporting a few thousand PCs and each false alarms means a telephone call from a worried user asking for help. The peril and cost of false alarms should never be underestimated by those serious about keeping their corporation running smoothly and uninterrupted.
Fortunately testing anti-virus products' propensity to false alarm is fairly easy. All that is required is a large number of uninfected files. The simplest way to acquire a large collection of files is to purchase a number of shareware CD ROMs (hopefully virus-free!). These collections typically contain over 650MB of archived programs which can be extracted to a large network drive. The test is then simply a case of scanning the clean file collection with each anti-virus product.
The last few years have seen a great development in communication media. With the growing use of multimedia, CD-ROM and increased use of the Internet and on-line services as a means of communication and data transfer, it would not be out of place to say that for any PC user, 'The world is your oyster'. PC users have access to an astonishing range of information and executables from almost anywhere in the world. To an increasing degree, file-compression is used as a method for transferring executables. The transfer of any executable file, whether by disk, downloaded from a bulletin board or via one of the on-line services, carries with it the risk of virus infection. When executables are transferred in compressed form, the opportunity for a virus to 'slip through the net' increases.
If anyone is in any doubt about the potential threat of viruses being disseminated in this way, the distribution of a CD-ROM, 'Gates of the Underworld, Volume 1', containing compressed files infected with Taipan.438 and Gold Bug.a viruses, confirms this threat. The producer of the CD-ROM was checking its files with an anti-virus product; but that product was not able to detect the viruses within compressed files. However, to properly understand this 'hidden threat', it must be put in context.
In recent months there has been a growth in the number of polymorphic, or variably-encrypted viruses which are 'in the wild'. The fact that these viruses have gone from being 'in the lab' to 'in the wild' over a relatively short period of time has forced the anti-virus community to concentrate much of its efforts on developing scanning techniques to detect polymorphic viruses. The particular problem posed by polymorphic viruses is that there is no constant sequence of bytes which can be included in a scanner's database in order to reliably detect the virus.
The problems associated with the use of encryption, however, are not confined to polymorphic viruses. Developers of anti-virus programs are faced with similar problems when scanning files which have been archived or compressed using utilities such as PKZIP, LZH, PKLite and LZExe. These utilities are designed to economise on the amount of disk-space taken up by files.
There are several techniques which can be used to achieve this. Some program files, for example, contain a 'working area', normally initialised to a single value such as '0', which is used by the program once it has been executed. The file-compression utility can 'chop-out' this contiguous block of 0s, make a note of where in the file the 0s should be and when the file is decompressed subsequently put the 0s back in place.
Broadly-speaking, file-compression may take two forms. The first is where the files being compressed are contained within a completely separate file. In order for these files to be run subsequently, they must first be decompressed. This technique is used by PKZIP. For example, a series of executables may be compressed into a single file, with the extension ZIP. This file itself, is not executable, and the files contained within it cannot be run without first decompressing the ZIP file using PKUNZIP.
The other form of file compression is where a single program file is compressed. In this case, the file retains its original extension and when the program is executed, the file is decompressed 'on the fly', without reference to any external de-compression utility. These are known as self-extracting archive files. For this technique to be effective, information about the way the original program was compressed must be stored in the header of the new compressed file.
The Cruncher virus has already used this technique to try and hide itself from virus scanners. Cruncher "borrows" the compression code from the shareware utility Diet written by Teddy Matsumoto in order to compact itself after infection. Several scanners have had difficulties detecting this in-the-wild virus reliably because of their inability to scan inside the Diet compression format.
In either case, the sequence of bytes within an executable is not the same after it has been compressed as it was before and if we consider the way in which an anti-virus scanner looks at a file to determine whether it is clean or infected, the potential threat posed by compressed files becomes clear. A virus scanner is designed to examine a potentially infected file. It looks for a sequence of bytes belonging to a given virus in the part of the file where the virus will be if the file is infected. If the sequence of bytes in that location matches the scanner's database entry, the file should be reported as infected.
If a file becomes infected after it has been compressed, the file may be scanned in the same way as any other file. However, if the file or files, were infected before compression took place, things become more complicated. Just as a file infected by a polymorphic virus contains no single sequence of bytes which can always be found in any infected file, executable code contained within a compressed or self-extracting archive file will not look the same after the file has been compressed.
While it is possible with compressed files (PKZIP or ARJ, for example) to manually de-compress the files and check them for viruses, it is a time-consuming process. It also relies on users being familiar with the intricacies of de-compression utilities. In addition, this process, while safe in itself, leaves plenty of scope for mistakes to be made. In many cases user's may not even have access to these tools on their workstations.
Self-extracting archive files (such as PKLite or LZExe) pose more of a problem. It is less likely that anyone using such a file has access to the mechanism by which the files may be decompressed.
The increased use of file-compression as a means for transferring data, the potential threat to security involved in the use of compressed files and the absence of a realistic alternative (both in terms of security and time), make it vitally important that anti-virus scanners include a facility for scanning compressed and self-extracting archive files. With this facility built into your anti-virus scanner, you get ease-of-use coupled with the security of knowing that no viruses will penetrate your system unnoticed.
Independent testers have found that although many anti-virus products claim to scan inside compressed and archived files, the quality of such scanning can vary dramatically. Some products miss viruses in compressed files which they detect quite easily when uncompressed.
The way to test an anti-virus' ability to detect viruses in compressed and archived files is to compress a collection of viruses with popular archiving tools such as PKZIP, LZH, etc. It is then a simple case of scanning these archived files with the appropriate settings enabled.
A more thorough test involves compressing files multiple times (for example, a PKLite'd virus within a ZIP within an ARJ). Viruses are often distributed in this form over the Internet because virus authors know some anti-virus products have difficulty scanning recursively inside multiply compressed files. The better anti-virus products should have no such difficulty.
Unfortunately, for those of you who are already hyper-aware of security issues, it is not possible to scan executables which have been encrypted with passwords because in these cases, a user-defined level of encryption is used as part of the compression process. However, if FindVirus detects these type of files, it will report that password-encrypted files have been found on the disk. You can then decide to decompress the files manually and scan for viruses in the normal way.
The ideal situation in which to deal with scanning compressed files then, as indeed it should be with any incoming or outgoing files, should be a stand-alone 'footbath' PC. In this way, all incoming floppy disks can be scanned as they enter your organization, certified clean and passed to the relevant department or individual within the organization. Moreover, if there are password-encrypted files, these can be manually decompressed in a safe environment away from the PCs used as part of the day-to-day business of your organization.
EICAR (the European Institute of Computer Anti-virus Research) provide a test file which can be used to check you have installed your anti-virus correctly. Virtually all major anti-virus products support the EICAR test file.
Naturally, the file is not a virus. It can not be used to test the detection rate of an anti-virus product but it can be used to determine whether an anti-virus has been installed correctly. It also has the benefit of allowing users to see what happens when their anti-virus detects a virus.
When executed, EICAR.COM will display the text EICAR-STANDARD-ANTIVIRUS-TEST-FILE and exit.
To create the EICAR test file, use any ASCII text editor to create a file with the following single line at its very beginning:
X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*
Save the file to any name with COM extension, for example EICAR.COM. Make sure you save the file in standard MS-DOS ASCII format. The file should be 68 bytes long, but might be 70 bytes if the editor puts a CR/LF at the end. Now you can use this file to test what happens when your anti-virus product encounters a "real" virus.
If you are going to conduct tests against viruses you obviously should not use your network or regular work PCs. The PCs should be in a closed environment and not connected to any outside network. It is also preferable to have some physical access control preventing unauthorised personnel from gaining access to the infected PCs or the viruses.
It is essential (if only for your future job security!) that there is no possibility for viruses to escape from the controlled environment. Ideally no floppy disks should ever leave the room - the door acting as a one way valve. Furthermore hard disks will need to be completely wiped on PCs before they leave. Note: Formatting a hard drive is not enough to get rid of a virus infection - in many cases formatting removes everything from the hard disk apart from the virus.
It is essential that those conducting the tests are well-versed in the methods used by viruses. This information can be culled from the websites of anti-virus vendors, the manuals of anti-virus products, and the FAQ for the Internet newsgroup comp.virus
Further information and assistance in this difficult area is available from Dr Solomon's technical support staff.
The following list is not exhaustive, as switches are added and removed as part of the development cycle. Therefore not all the switches listed will work will all versions of Findvirus.
| /? /HELP | Display list of command line options. FindVirus will immediately quit after displaying this screen, regardless of other command line options. |
| /AD /ALLDRIVES /ALLVOLUMES | Check all fixed drives For NetWare only. Scans all volumes on the server. |
| /AN /ANALYSE /ANALYZE | Use Advanced Heuristic Analysis as well as traditional scanning techniques. |
| /APPEND (used with /REPORT=[fname]) /AUTOEXIT | Append FindVirus report to an existing report file Terminate the GUI Findvirus without waiting for user to press EXIT (or appropriate). If a virus is found Findvirus does not terminate automatically. |
| /BADLIST /BADLIST=[fname] | Create a file containing a list of infected files |
| /BEEP | Beep on completion when a virus is found (default) |
| /C=[filename] /CHECKLIST=[fname] | Check those files contained within the file specified using /BADLIST= |
| /DELETE (used with /REPAIR) | Deletes files which cannot be repaired |
| /D /DOALLFILES | Scans all files on your hard disk (including data files not normally infected by viruses). Note: FindVirus always scans EXE, COM, DOC, DOT, XLS, etc.. |
| /EVLOG /EXTERROR | Use Windows NT Event Logging Returns an extended set of errorlevels |
| /EXTRA=[fname] | Use a specified extra driver |
| /HTML /HTML=[filename] | Sends output to file specified in HTML format. If no file is specified the FINDVIRU.HTM is used. The resultant file can then be read using an appropriate Internet Browser. |
| /LC /LOCAL | Check all local fixed drives |
| /L /LOUD | Display status of each file checked |
| /MOVE /MOVE=[path] | Move infected file(s) to specified directory/path. If no directory is specified, the default is [\confined.vir] on the default drive. |
| /NOBEEP /NOMSG | Disable beep on completion when a virus is found Disable default network broadcast alert |
| /NOPACK | Disable checking of compressed files (PKLite, LZExe, ICE, Diet, CryptCOM, MS Compress) |
| /ONVIRUS=HALT /ONVIRUS='message' | On finding a virus, prints the message specified to the screen or halts the computer, requiring a reboot. NOTE : The HALT option is only available to DOS |
| /PACK | Enable checking of compressed files (PKLite, LZExe, ICE, Diet, CryptCOM, MS Compress). NOTE: Requires 386 or better processor. |
| /PAUSE /P | When scanning a floppy disk, prompt user at beginning of scan to insert floppy rather than after first scan |
| /PRINTOUT | Send FindVirus output to printer |
| /QUEUE=[queue] | Specify print queue. |
| /RP /REPAIR | Repair infected files (files are renamed if they cannot be repaired) |
| /REPORT /R=[fname] /REPORT=[fname] | Create a report to file specified. If no file is specified, the default FINDVIRU.REP is used |
| /SECURE | Shorthand equivalent to /ANALYZE /UNZIP /DOALLFILES. NOTE: Requires 386 or better processor |
| /S /SILENT | Suppress screen output |
| /TELL=[user] | Specify the user to receive a broadcast alert |
| /U /UNZIP | Enable checking of files within compressed files and archived files (ZIP, ZIP2EXE, ARC, ARJ, LZH, PKLite, LZExe, ICE, Diet, CryptCOM, and MS Compress). NOTE: This switch automatically enables /PACK and requires a 386 or better processor. |
| /YESBREAK | Enable interruption of FindVirus execution using [Ctrl-C] |