- Email: [email protected]
Nuisance or corporate threat?
November
Computer Fraud & Security Bulletin
Restore previous backed up files to the
COMPUTER VIRUSES
9.
NUISANCE THREAT?
10. Destroy all infected diskettes.
OR CORPORATE
This is the second of a two part investigation Systems
by Dr Ken Wong of B/S Applied
Disaster recovery
headache
viruses, the biggest
is the difficulty
PC user regularly
of ensuring
that the
keeps backup copies of files,
with archive copies for long term retention where necessary.
system.
As a result of the Internet worm attack, a post mortem meeting of interested parties under the aegis of the UN Department of Defence made a number of recommendations designed to respond to a future virus attack on networks. It is interesting to note that many of the recommendations have much in common
UK
For PC-based
If files are not judiciously
with disaster recovery provisions dealing with general network disruptions. A resume of the recommendations is as follows. 1.
Set up a central disaster coordination centre as a clearing house and repository of incidents (or disruptions), supported by an electronic bulletin board if necessary.
2.
Establish an alternative emergency voice broadcast network to warn all nodes of an imminent virus attack. This is in case the data network is down or overrun by the virus. The voice system can also provide a dial-in service for network users to check recovery progress.
3.
Set up an emergency response or disaster recovery team. The team will need to have relevant technical skills to decide on the logistics to combat a virus
backed up on a regular basis, one can run the risk of losing data and programs on corrupted or disappearing
files resulting from a virus
rampage. Otherwise
the following
recovery procedures
have been proposed, and
general
applied by many, to salvage systems and data after detecting a virus attack. 1.
Check all files and media to determine the extent of infection and recall all diskettes which have been in contact with the infected system for checking.
2.
Power down infected system.
3.
Reboot from original supplier diskette.
4.
Back up all non-executable files onto reformatted or hard disks, using the back-up utility from the original software diskette for the latter.
5.
Perform low level format on the infected disk.
6.
Restore the operating disk.
attack; e.g. shut down adjoining unaffected system, analyse the virus and apply appropriate system patches, etc. 4.
Establish central focal point for press relations. This will help to relieve the burden from the emergency response team and help with the recovery process through avoiding frequent interruptions to deal with the press.
5.
Set up change control procedures to ensure all system patches have been vetted to avoid any adverse side affects resulting from quick program fixes. Some means would have to be found to ensure that the system changes are provided by
system to the hard
7.
Restructure
8.
Replace all executable programs from original supplier diskettes.
6
7989
file directories.
01989
Elsevier Science Publishers
Ltd
November 1989
Computer Fraud & Security Bulletin
authorized individuals and have not been tampered with. This could be by way of password verification together with a cryptographic checksum or hash total of the changed coding.
6.
7.
Provide virus awareness training to system operators to acquaint them with the likely symptoms of a virus attack and an action checklist to follow, e.g. to administer any agreed antidotes, change the network’s configuration, or call on the emergency response team if necessary. Establish standard backup policies to determine what backups are required, when and where taken and frequency. Any mirror-image backups may need to be supplemented by keeping a standby system which uses previous versions of the software.
8.
Develop a common set of virus analysis tools to make available to the emergency response team.
Safe computing
practice
Returning to the PC-based virus threat, the most suitable approach is to enforce safe computing practice in the organization to minimise the risk of virus infection in the first place. This is both relatively traumatic
compared
of recovering
painless and less
with the substantial
from a potentially
efforts
widespread
infection. To begin with, it would be prudent to purchase software only from reputable sources. Check that it arrives in shrink wrap or sealed diskette containers; although the supplied diskette could have been resealed when it was returned from another customer. In any case the new software should be reviewed by systems staff before installing it on a distributed system, ideally undergoing a quarantine period on a standalone PC designated for testing new software on approval or from purchase.
01989
Elsevier Science Publishers
Ltd
Having checked the purchased software, a backup copy should then be made and stored off-site. At the same time the original diskette content should be protected from modification using the write-protect tab on the diskette. To simplify housekeeping and to achieve protection of system software from contamination, only one boot diskette with write-protection should be used for a number of diskette-based PCs in a distributed system or PC-network. The diskette should be labelled accordingly.
For hard disk-based
systems,
users should be discouraged from booting the system from a diskette disk drive, unless this is the original write-protected system diskette or the user is recovering the system from a virus attack. Most PC viruses enter the system via dubious games software. Users should be asked not to play games on the system disk. They should also be discouraged from using public domain software or shareware downloaded from a public electronic bulletin board. Pirated software should never be allowed on any system as the company may be brought into disrepute, to say nothing of incurring a high risk of infection. Users should be encouraged to watch out for symptoms of virus infection on their systems. The following tell-tale signs may not all apply in any particular case and may be ascribed to other system problems. Nevertheless it would be prudent to check for the presence of viruses when they occur frequently or persistently. Symptoms include slow program loading compared with normal working, excessive disk access even for simple tasks, frequent display of unusual error messages, access lights coming on even when devices are not referenced by the program, memory squeeze (i.e. less memory available than normal) files and programs mysteriously disappearing, sudden reduction in disk space, change of executable file size, hidden files suddenly appearing on the directory,etc.
November 1989
Computer Fraud & Security Bulletin
Try to minimise the exchange of executable code between any two systems in a PC-network or multi-system environment as this is the normal route for viruses to pass from system to system. When using someone else’s PC, try to transfer only the necessary data on a diskette with no executable code stored. If at all possible, avoid using diskettes which are bootable or contain system files. Users must be given proper security awareness training to recognize the necessity of keeping system backups of all software and data, following any program amendment, or at least once a week or once a month, depending on individual circumstances. Archive copies retained for long term storage should be held for at least a year before reuse in case a virus introduced into the system could have a long incubation period before activating its data corruption process. Otherwise all copies of the software would be infected and the previous clean copies are no longer available to recover the system. To prevent virus infection from a programmer working from home, using his home PC to support or maintain corporate systems or applications, the changed coding should ideally be kept in temporary buffer storage for examination by other system programmers, and should undergo some quarantine period before incorporating in the system library. Virus protection
products
These can be put into three broad categories: -
virus detection;
-
infection
prevention;
-
infection
identification.
Virus detection products are specifically targeted to detect certain types of virus. They
look for specific characteristics of the individual virus, e.g. scan the system for a particular segment of virus code, certain virus labels or copyright flags (e.g. Brain virus) or fake bad sectors on disks which contain data (e.g. Italian virus). Each product will only deal with one strain of virus and a company would have to obtain many different such products in order to detect the various popular virus strains at large, and have the attendant staff effort to run the antidote programs regularly. Also a product can only be developed when one knows enough about the characteristics of a specific virus. This could typically be 12-l 8 months after the virus was first detected while data is painstakingly collected on the virus’s characteristics, methods of replication anti-social or criminal intent.
and
An antidote can then be developed to deal with it, again requiring months of effort before an end product is available on the market. This all takes time. A virus detection product is generally used to establish the extent of infection in the organisation after it has been proven that a particular virus has infected some of the systems. Infection prevention products try to prevent a virus from infecting a system or replicating itself to a new host. The antidote program tends to remain resident in computer memory at all times, monitoring the system’s various activities to spot any tell-tale signs of the virus’s presence. It will intercept and check all file accesses (both read and write) by other programs, monitor programs which load into or out of memory, check all system interrupts to request service from the operating system, or keep watch over the system tables to monitor and examine every activity. When it gets any indication that a virus attempts to gain access to the boot segment, the operating system or any executable program, it will halt the system and issue a warning message on the screen. Such antidotes will not prevent boot infectors from invading the system, because
01989
Elsevier Science Publishers
Ltd
November 1989
the infection will have taken place when the system was powered up or rebooted, well before the antidote is loaded to the system. Also there are occasions when false alarms will happen because some of the system activities thought to manifest the presence of viruses do occur in some normal system operations. This type of product tends to be extremely demanding on system resources as they stay in residence in memory at all times. The use of such products in normal system running can incur punitive cuts in memory space as well as slow system response, because every system activity will be intercepted and checked for the presence of viruses.
Computer Fraud & Security Bulletin
checksum would remain the same as before infection. Another type of infection detector works by taking a snapshot of the system, storing away some key data in the system as matrices when it is first installed. Periodically the user can run checks on the system to compare the current system’s data values with the stored matrices. If any of the values differ, this will point to an area in the computer where a change has taken place since the initial logging of data matrices. Such products will detect all boot infectors, system infectors and application infectors. One can also keep the snapshot file on a different computer and compare the programs off-line to avoid infection.
Infection detection products will not prevent a virus from entering the system.
The drawback of using detection products is that it takes time to compute the checksums
Given prudent advance preparation before a viral infection, this type of product will locate traces of an infection after the event by monitoring changes in the system caused by the virus in its infection process.
(even longer for cryptographic checksums) and run the comparison programs for all production systems as a matter of routine. One company found it took 45 minutes every morning to use a detection software package to check out some 250 files. We feel a more realistic timescale may be to run the checks once every month or so.
One type of detection product will build into the system some self-checking mechanism such as a hash total, checksum or some mathematical algorithm to work out a cryptographic check-sum from the program’s instruction sequence. Every time before the program is executed, there will be a recalculation of the checksum to compare with its computed value when the program was last executed. If the values differ then the assumption is that the program has been tampered with (not necessarily the result of a virus) and a warning message would be issued. This form of ‘vaccination’ does not always work as some of the system’s critical programs are difficult to vaccinate. For instance, a boot infector would generally replace the entire boot sector with itself whilst displacing the original boot sector coding further down the disks storage area, and the vaccinated boot sector coding would then never execute after the virus infection. Also the entire coding although unchanged would be displaced, so the
01989
Elsevier Science Publishers Ltd
In the case of distributing software, either via a network or by other means, the incorporation of a checksum or cryptographic checksum with the software would enable some software integrity checks to be carried out by the recipient to ensure that the software has not been modified or contaminated in the intermediate stages. The checksum computed would otherwise not agree with the value which came with the software. In the case of the software supplier or distributor, who regularly sends out new software to customers on approval, recalculation of the checksum of the returned software would help to detect if the diskette had been infected before returning. Future implications The state of the art of computer viruses very much follows the rule of the poacher and gamekeeper. As soon as one virus is
November
Cornouter Fraud & Securitv Bulletin
discovered, the control logistics properly researched, antidotes developed and recovery process properly worked out, then another virus emerges from somewhere else and the whole process repeats. Of the 3040 strains of virus discovered so far, there is no clear evidence of any organization losing vast sums of money from a virus infection. The common thread appears to be the time and staff effort required to clean up the infected systems and media, which can be substantial in a widespread infection. Careful analysis of the more popular strains show that the replication mechanisms and damage effects on data and program files are relatively simple to isolate and contain. The risk of reinfection may mean devising new housekeeping procedures to track down the movement of diskettes and the shared usage of PCs in the company, to ensure that all those systems potentially at risk can be checked for possible infection.
1989
A group calling themselves VAXbusters claimed they could gain access to some 1000 VAX systems worldwide. A virus construction kit was widely available with a diskette containing ‘nightmare software’. When interviewed by a reporter on what motivates him to write computer viruses, one of the authors replied, “You feel something wonderful has happened (when you produced one). You have created something which lives. You don’t know where it will go, what it will do, and how it will live on.” This poses a challenge to the virus writer to create the most sophisticated virus to date, to improve hacking techniques to allow widespread penetration to as many channels of propagation as he can find, to prolong the virus’s life by making it difficult to detect and to circumvent any of the published virus control techniques in use. At a computer virus conference held in
Looking ahead to some of the future developments of both poachers and gamekeepers, it is difficult to predict if either side will win or lose in the battle of wits.
New York in June 1989, someone mentioned the discovery of a new dBASE virus. When it penetrates a system and becomes system resident, it will transpose two bytes of certain fields on the database file. During a database
What could tip the balance could be legislation and law enforcement. This would enable stiff fines and penalties to be imposed on those caught in the act of virus writing or virus infection. Last year the Chaos Computer.Club in West Germany devoted an entire private congress to the subject of computer viruses. Several hundred members attended, including at least 20 established and budding virus writers. Besides swapping passwords and exchanging sensitive system information to penetrate corporate systems worldwide, which would give them the means to plant viruses into the computer systems of victim companies, there was also intensive intellectual exchange of views and techniques on how to write more sophisticated viruses in future.
10
access the virus code will reverse the transposition to give the impression that the database system is working properly. This will go on for 90 days and then the virus will corrupt the file allocation table. If the virus were discovered before the due date and removed from the system, then the database would be corrupted by the 2 bytes which have been transposed in some of the data fields. The story may sound apocryphal; but it does present a good case to support safe computing practice. As one conference delegate put it, “It pays to know what your disks are and where they have been.” Ken Wong
01989
Elsevier Science Publishers Ltd
Computer Fraud & Security Bulletin
Restore previous backed up files to the
COMPUTER VIRUSES
9.
NUISANCE THREAT?
10. Destroy all infected diskettes.
OR CORPORATE
This is the second of a two part investigation Systems
by Dr Ken Wong of B/S Applied
Disaster recovery
headache
viruses, the biggest
is the difficulty
PC user regularly
of ensuring
that the
keeps backup copies of files,
with archive copies for long term retention where necessary.
system.
As a result of the Internet worm attack, a post mortem meeting of interested parties under the aegis of the UN Department of Defence made a number of recommendations designed to respond to a future virus attack on networks. It is interesting to note that many of the recommendations have much in common
UK
For PC-based
If files are not judiciously
with disaster recovery provisions dealing with general network disruptions. A resume of the recommendations is as follows. 1.
Set up a central disaster coordination centre as a clearing house and repository of incidents (or disruptions), supported by an electronic bulletin board if necessary.
2.
Establish an alternative emergency voice broadcast network to warn all nodes of an imminent virus attack. This is in case the data network is down or overrun by the virus. The voice system can also provide a dial-in service for network users to check recovery progress.
3.
Set up an emergency response or disaster recovery team. The team will need to have relevant technical skills to decide on the logistics to combat a virus
backed up on a regular basis, one can run the risk of losing data and programs on corrupted or disappearing
files resulting from a virus
rampage. Otherwise
the following
recovery procedures
have been proposed, and
general
applied by many, to salvage systems and data after detecting a virus attack. 1.
Check all files and media to determine the extent of infection and recall all diskettes which have been in contact with the infected system for checking.
2.
Power down infected system.
3.
Reboot from original supplier diskette.
4.
Back up all non-executable files onto reformatted or hard disks, using the back-up utility from the original software diskette for the latter.
5.
Perform low level format on the infected disk.
6.
Restore the operating disk.
attack; e.g. shut down adjoining unaffected system, analyse the virus and apply appropriate system patches, etc. 4.
Establish central focal point for press relations. This will help to relieve the burden from the emergency response team and help with the recovery process through avoiding frequent interruptions to deal with the press.
5.
Set up change control procedures to ensure all system patches have been vetted to avoid any adverse side affects resulting from quick program fixes. Some means would have to be found to ensure that the system changes are provided by
system to the hard
7.
Restructure
8.
Replace all executable programs from original supplier diskettes.
6
7989
file directories.
01989
Elsevier Science Publishers
Ltd
November 1989
Computer Fraud & Security Bulletin
authorized individuals and have not been tampered with. This could be by way of password verification together with a cryptographic checksum or hash total of the changed coding.
6.
7.
Provide virus awareness training to system operators to acquaint them with the likely symptoms of a virus attack and an action checklist to follow, e.g. to administer any agreed antidotes, change the network’s configuration, or call on the emergency response team if necessary. Establish standard backup policies to determine what backups are required, when and where taken and frequency. Any mirror-image backups may need to be supplemented by keeping a standby system which uses previous versions of the software.
8.
Develop a common set of virus analysis tools to make available to the emergency response team.
Safe computing
practice
Returning to the PC-based virus threat, the most suitable approach is to enforce safe computing practice in the organization to minimise the risk of virus infection in the first place. This is both relatively traumatic
compared
of recovering
painless and less
with the substantial
from a potentially
efforts
widespread
infection. To begin with, it would be prudent to purchase software only from reputable sources. Check that it arrives in shrink wrap or sealed diskette containers; although the supplied diskette could have been resealed when it was returned from another customer. In any case the new software should be reviewed by systems staff before installing it on a distributed system, ideally undergoing a quarantine period on a standalone PC designated for testing new software on approval or from purchase.
01989
Elsevier Science Publishers
Ltd
Having checked the purchased software, a backup copy should then be made and stored off-site. At the same time the original diskette content should be protected from modification using the write-protect tab on the diskette. To simplify housekeeping and to achieve protection of system software from contamination, only one boot diskette with write-protection should be used for a number of diskette-based PCs in a distributed system or PC-network. The diskette should be labelled accordingly.
For hard disk-based
systems,
users should be discouraged from booting the system from a diskette disk drive, unless this is the original write-protected system diskette or the user is recovering the system from a virus attack. Most PC viruses enter the system via dubious games software. Users should be asked not to play games on the system disk. They should also be discouraged from using public domain software or shareware downloaded from a public electronic bulletin board. Pirated software should never be allowed on any system as the company may be brought into disrepute, to say nothing of incurring a high risk of infection. Users should be encouraged to watch out for symptoms of virus infection on their systems. The following tell-tale signs may not all apply in any particular case and may be ascribed to other system problems. Nevertheless it would be prudent to check for the presence of viruses when they occur frequently or persistently. Symptoms include slow program loading compared with normal working, excessive disk access even for simple tasks, frequent display of unusual error messages, access lights coming on even when devices are not referenced by the program, memory squeeze (i.e. less memory available than normal) files and programs mysteriously disappearing, sudden reduction in disk space, change of executable file size, hidden files suddenly appearing on the directory,etc.
November 1989
Computer Fraud & Security Bulletin
Try to minimise the exchange of executable code between any two systems in a PC-network or multi-system environment as this is the normal route for viruses to pass from system to system. When using someone else’s PC, try to transfer only the necessary data on a diskette with no executable code stored. If at all possible, avoid using diskettes which are bootable or contain system files. Users must be given proper security awareness training to recognize the necessity of keeping system backups of all software and data, following any program amendment, or at least once a week or once a month, depending on individual circumstances. Archive copies retained for long term storage should be held for at least a year before reuse in case a virus introduced into the system could have a long incubation period before activating its data corruption process. Otherwise all copies of the software would be infected and the previous clean copies are no longer available to recover the system. To prevent virus infection from a programmer working from home, using his home PC to support or maintain corporate systems or applications, the changed coding should ideally be kept in temporary buffer storage for examination by other system programmers, and should undergo some quarantine period before incorporating in the system library. Virus protection
products
These can be put into three broad categories: -
virus detection;
-
infection
prevention;
-
infection
identification.
Virus detection products are specifically targeted to detect certain types of virus. They
look for specific characteristics of the individual virus, e.g. scan the system for a particular segment of virus code, certain virus labels or copyright flags (e.g. Brain virus) or fake bad sectors on disks which contain data (e.g. Italian virus). Each product will only deal with one strain of virus and a company would have to obtain many different such products in order to detect the various popular virus strains at large, and have the attendant staff effort to run the antidote programs regularly. Also a product can only be developed when one knows enough about the characteristics of a specific virus. This could typically be 12-l 8 months after the virus was first detected while data is painstakingly collected on the virus’s characteristics, methods of replication anti-social or criminal intent.
and
An antidote can then be developed to deal with it, again requiring months of effort before an end product is available on the market. This all takes time. A virus detection product is generally used to establish the extent of infection in the organisation after it has been proven that a particular virus has infected some of the systems. Infection prevention products try to prevent a virus from infecting a system or replicating itself to a new host. The antidote program tends to remain resident in computer memory at all times, monitoring the system’s various activities to spot any tell-tale signs of the virus’s presence. It will intercept and check all file accesses (both read and write) by other programs, monitor programs which load into or out of memory, check all system interrupts to request service from the operating system, or keep watch over the system tables to monitor and examine every activity. When it gets any indication that a virus attempts to gain access to the boot segment, the operating system or any executable program, it will halt the system and issue a warning message on the screen. Such antidotes will not prevent boot infectors from invading the system, because
01989
Elsevier Science Publishers
Ltd
November 1989
the infection will have taken place when the system was powered up or rebooted, well before the antidote is loaded to the system. Also there are occasions when false alarms will happen because some of the system activities thought to manifest the presence of viruses do occur in some normal system operations. This type of product tends to be extremely demanding on system resources as they stay in residence in memory at all times. The use of such products in normal system running can incur punitive cuts in memory space as well as slow system response, because every system activity will be intercepted and checked for the presence of viruses.
Computer Fraud & Security Bulletin
checksum would remain the same as before infection. Another type of infection detector works by taking a snapshot of the system, storing away some key data in the system as matrices when it is first installed. Periodically the user can run checks on the system to compare the current system’s data values with the stored matrices. If any of the values differ, this will point to an area in the computer where a change has taken place since the initial logging of data matrices. Such products will detect all boot infectors, system infectors and application infectors. One can also keep the snapshot file on a different computer and compare the programs off-line to avoid infection.
Infection detection products will not prevent a virus from entering the system.
The drawback of using detection products is that it takes time to compute the checksums
Given prudent advance preparation before a viral infection, this type of product will locate traces of an infection after the event by monitoring changes in the system caused by the virus in its infection process.
(even longer for cryptographic checksums) and run the comparison programs for all production systems as a matter of routine. One company found it took 45 minutes every morning to use a detection software package to check out some 250 files. We feel a more realistic timescale may be to run the checks once every month or so.
One type of detection product will build into the system some self-checking mechanism such as a hash total, checksum or some mathematical algorithm to work out a cryptographic check-sum from the program’s instruction sequence. Every time before the program is executed, there will be a recalculation of the checksum to compare with its computed value when the program was last executed. If the values differ then the assumption is that the program has been tampered with (not necessarily the result of a virus) and a warning message would be issued. This form of ‘vaccination’ does not always work as some of the system’s critical programs are difficult to vaccinate. For instance, a boot infector would generally replace the entire boot sector with itself whilst displacing the original boot sector coding further down the disks storage area, and the vaccinated boot sector coding would then never execute after the virus infection. Also the entire coding although unchanged would be displaced, so the
01989
Elsevier Science Publishers Ltd
In the case of distributing software, either via a network or by other means, the incorporation of a checksum or cryptographic checksum with the software would enable some software integrity checks to be carried out by the recipient to ensure that the software has not been modified or contaminated in the intermediate stages. The checksum computed would otherwise not agree with the value which came with the software. In the case of the software supplier or distributor, who regularly sends out new software to customers on approval, recalculation of the checksum of the returned software would help to detect if the diskette had been infected before returning. Future implications The state of the art of computer viruses very much follows the rule of the poacher and gamekeeper. As soon as one virus is
November
Cornouter Fraud & Securitv Bulletin
discovered, the control logistics properly researched, antidotes developed and recovery process properly worked out, then another virus emerges from somewhere else and the whole process repeats. Of the 3040 strains of virus discovered so far, there is no clear evidence of any organization losing vast sums of money from a virus infection. The common thread appears to be the time and staff effort required to clean up the infected systems and media, which can be substantial in a widespread infection. Careful analysis of the more popular strains show that the replication mechanisms and damage effects on data and program files are relatively simple to isolate and contain. The risk of reinfection may mean devising new housekeeping procedures to track down the movement of diskettes and the shared usage of PCs in the company, to ensure that all those systems potentially at risk can be checked for possible infection.
1989
A group calling themselves VAXbusters claimed they could gain access to some 1000 VAX systems worldwide. A virus construction kit was widely available with a diskette containing ‘nightmare software’. When interviewed by a reporter on what motivates him to write computer viruses, one of the authors replied, “You feel something wonderful has happened (when you produced one). You have created something which lives. You don’t know where it will go, what it will do, and how it will live on.” This poses a challenge to the virus writer to create the most sophisticated virus to date, to improve hacking techniques to allow widespread penetration to as many channels of propagation as he can find, to prolong the virus’s life by making it difficult to detect and to circumvent any of the published virus control techniques in use. At a computer virus conference held in
Looking ahead to some of the future developments of both poachers and gamekeepers, it is difficult to predict if either side will win or lose in the battle of wits.
New York in June 1989, someone mentioned the discovery of a new dBASE virus. When it penetrates a system and becomes system resident, it will transpose two bytes of certain fields on the database file. During a database
What could tip the balance could be legislation and law enforcement. This would enable stiff fines and penalties to be imposed on those caught in the act of virus writing or virus infection. Last year the Chaos Computer.Club in West Germany devoted an entire private congress to the subject of computer viruses. Several hundred members attended, including at least 20 established and budding virus writers. Besides swapping passwords and exchanging sensitive system information to penetrate corporate systems worldwide, which would give them the means to plant viruses into the computer systems of victim companies, there was also intensive intellectual exchange of views and techniques on how to write more sophisticated viruses in future.
10
access the virus code will reverse the transposition to give the impression that the database system is working properly. This will go on for 90 days and then the virus will corrupt the file allocation table. If the virus were discovered before the due date and removed from the system, then the database would be corrupted by the 2 bytes which have been transposed in some of the data fields. The story may sound apocryphal; but it does present a good case to support safe computing practice. As one conference delegate put it, “It pays to know what your disks are and where they have been.” Ken Wong
01989
Elsevier Science Publishers Ltd