====================================================== = Section E. Facts and Fibs About Computer Viruses = ====================================================== E1) Can boot sector viruses infect non-bootable DOS floppy disks? Any DOS diskette that has been properly formatted contains some executable code in its boot sector. (There is some debate as to whether this code should be called a program or not. The important thing here is that this code is *executed* at system startup if the diskette is in the system's boot drive.) If a diskette is not "bootable", all that boot sector (normally) does is print a message (on a PC, typically something like "Non-system disk or disk error; replace and strike any key when ready"). However, the boot sector is still executable and therefore vulnerable to infection. Should you accidentally boot your machine with a "non-bootable" diskette in the boot drive, and see that message, it means that any boot virus that may have been on that diskette *has* run, and had the chance to infect your hard drive, or whatever. So, when talking about viruses, the words "bootable" and "non- bootable" are misleading. All formatted diskettes are capable of carrying boot sector viruses. Most current computers will try to boot from their (first) floppy drive before trying to load an operating system off their hard disks. Because of this and the fact that every floppy disk is possibly infected with a boot sector virus, it is a *very* good idea to set your computer to try to boot from its hard disk. Many newer PCs offer the option to select boot order in their system CMOS setup routines. If your computer has such an option, set it to try to boot from your hard disk first. E2) Can a virus hide in a PC's CMOS memory? No. The CMOS RAM in which PC system information is stored and backed up by batteries is accessible through the I/O ports and not directly addressable. That is, in order to read its contents you have to use I/O instructions rather than standard memory addressing techniques. Therefore, anything stored in CMOS is not directly "in memory". Nothing in a normal machine loads the data from CMOS and executes it, so a virus that "hid" in CMOS RAM would still have to infect an executable object of some kind in order to load and execute whatever had been written to CMOS. A malicious virus can of course *alter* values in the CMOS as part of its payload, but it can't spread through, or hide itself in, the CMOS. Further, most PCs have only 64 bytes of CMOS RAM and the use of the first 48 bytes of this is predetermined by the IBM AT specification. Several BIOS'es also use many of the "extra" bytes of CMOS to hold their own, machine-specific settings. This means that anything that a virus stores in CMOS can't be very large. A virus could use some of the "surplus" CMOS RAM to hide a small part of its body (e.g. its payload, counters, etc). Any executable code stored there, however, must first be extracted to ordinary memory in order to be executed. This issue should not be confused with whether a virus can *modify* the contents of a PC's CMOS RAM. Of course viruses can, as this memory is not specially protected (on normal PCs), so any program that knows how to change CMOS contents can do so. Some viruses do fiddle with the contents of CMOS RAM (mostly with ill-intent) and these have often been incorrectly reported as "infecting CMOS" or "hiding in CMOS". An example is the PC boot sector virus EXE_Bug, which changes CMOS settings to indicate that no floppy drives are present (see G8 for more details). E3) Can a PC virus hide in Extended or in Expanded RAM in a PC? Yes. If one does though, it has to have a small part resident in conventional RAM; it cannot reside *entirely* in Extended or in Expanded RAM. Currently there are no known XMS viruses and only a few EMS viruses (Emma is an example). E4) Can a virus hide in a PC's Upper Memory or in High Memory Area? Yes, it is possible to construct a virus which will locate itself in Upper Memory Blocks (UMBs--640K to 1024K) or in the High Memory Area (HMA--1024K to 1088K). Some viruses (e.g. EDV) do hide in UMBs and at least one, Goldbug, will use the HMA if it is available. It might be thought that there is no point in scanning in these areas for any viruses other than those that are specifically known to inhabit them. However, there are cases when even ordinary viruses can be found in Upper Memory. Suppose that a conventional memory-resident virus infects a TSR program and this program is loaded high by the user (for instance, from AUTOEXEC.BAT). Then the virus code will also reside in Upper Memory. Therefore, an effective scanner must be able to scan this part of memory for viruses too. E5) Can a virus infect data files? Some viruses (e.g., Frodo, Cinderella) modify non-executable files. However, in order to spread, the virus code must be executed. Therefore "infected" non-executable files cannot be sources of further infection. Such "infections" are usually mistakes, due to bugs in the virus. Even so, note that it is not always possible to make a sharp distinction between executable and non-executable files. One person's data can be another's code and vice versa. Some files that are not directly executable contain code or data which can, under some conditions, be executed or interpreted. Some examples from the PC world are OBJ files, libraries, device drivers, source files for any compiler or interpreter (including DOS BAT files and OS/2 CMD files), macro files for some packages like Microsoft Word and Lotus 1-2-3, and many others. Currently there are viruses that infect boot sectors, master boot records, COM files, EXE files, BAT files, OBJ files, device drivers, Microsoft Word document and template files, and C source code files, although any of the objects mentioned above theoretically can be used as an infection carrier. PostScript files can also be used to carry a virus, although no currently known virus does this. Aside from the above, however, there is an increasing possibility of viruses spreading through the sharing of data files. More and more we see the ease with which software producers give their programs the ability to embed "objects" of many kinds into document files, and into fields in databases and spreadsheets. Perhaps the best-known of these systems are Object Linking and Embedding (OLE) in MS Windows and the OpenDoc format. As these embedded objects often have the ability to "display" themselves we see that many files traditionally thought of as data-only, will increasingly be containers carrying data and executable code. We are not aware of any virus that specifically targets such executable "objects", but it is now a trivial task to embed executable files into some kinds of document files so they will be run when the icon representing them is clicked in the finished document. There is nothing to prevent infected executables being embedded in this way, and thus for viruses to be spread through the distribution of "data files". E6) Can viruses spread from one type of computer to another? The simple answer is that no currently known viruses can do this. Although some disk formats may be the same (e.g. Atari ST and DOS), the different machines interpret the code differently. For example, the Stoned virus cannot infect an Atari ST as the ST cannot execute the virus code in the boot sector. The Stoned virus contains instructions for the 80x86 family of CPUs that the 680x0 CPU family (used in the Atari ST) can't understand or execute. The more general answer is that such viruses are possible, but unlikely. Such a virus would be quite a bit larger than current viruses and might well be easier to find. Additionally, the low incidence of cross- platform sharing of software means that any such virus would be unlikely to spread--it would be a poor environment for virus growth. A related, but different, issue is that of viruses running under operating system emulators on machines other than those for which the operating system was originally designed. This is covered in some detail elsewhere in the FAQ sheet (see C12). E7) Are mainframe computers susceptible to computer viruses? Yes. Numerous experiments have shown that computer viruses spread very quickly and effectively on mainframe systems. To our knowledge, however, no non-research computer virus has been seen on mainframe systems. (Despite often being described as such, the widely reported Internet Worm of November 1988 was not a computer virus by most definitions, although it had some virus-like characteristics.) Many people think that computer viruses are impossible on mainframe computers, because their operating systems provide means of protection (e.g., memory protection, access control, etc.) that cannot by bypassed by a program, unlike the operating systems of most personal computers. Unfortunately, this belief is false. As demonstrated by Fred Cohen in 1984, access controls are unable to prevent computer viruses--they can only slow down the speed with which viruses spread. If there is a transitive path of information flow from one account to another on a mainframe computer, then a virus can spread from one account to the other, without having to bypass any protections. Consider the following example. The attacker (A) has an account on a machine and wants to attack it with a virus. In order to do this, A writes a virus and releases it. Due to the protection provided by the operating system, the virus can only infect the files writable by A. On a typical system, those would be only the files owned by A. However, A is not alone on the system. A works with B on some joint projects. At some time, B might want to check how far A has progressed in her/his part of the project. This might involve running one of the programs that A has written--programs that are now all infected with A's virus. On a sytem with protection based on discretionary access controls (e.g., Unix, VMS, and most other popular OSes), the program that is being executed usually runs with the privileges of the user who is executing it--not with those of the program's owner. (In the few instances where this is not the case, it presents a different kind of security threat, unrelated to viruses.) That is, when B runs A's infected program, the virus in it will run with B's privileges and will be able to infect all programs writable by B. At some later time, A and B's boss, C, might want to check whether they have completed that joint project. Even if the boss has reasons to suspect A (e.g., as a disgruntled employee), s/he is likely to trust B and execute one of her/his programs. This results in the virus running with C's privileges (which are likely to be significantly greater than those of A and B) and infecting all programs writable by C. Quite possibly, these programs will include many owned by other employees, thus creating many more distribution chains that nobody suspects. The virus may interfere somehow with C's normal work, which causes C (who is probably not very knowledgeable about such things as computer security and viruses) to ask the system administrator, D, for help. If D executes one of C's infected programs (and s/he is much more likely to trust a respectable person like C--who is quite probably D's boss as well--than any of C's employees), this will cause the virus that A wrote a long time ago to run with system administrator privileges and do whatever it wants with the system--infect other users' files, attack other systems, etc. A trivial improvement of the above scenario (in terms of speeding up the virus' spread) would be for the attacker to place the virus in some kind of Trojan Horse--for example, in an attractive game or utility--placed in a publicly accessible area. Why, then, are there so many fewer viruses for mainframe computers than for personal ones? The answer to this question is complex. First, writing a well-made mainframe virus--one that does not cause problems and is likely to remain unnoticed--is not a trivial task. It requires a lot of knowledge about the operating system. This knowledge is not commonly available and the typical youngster who is likely to hack a quick-and-dirty PC virus is unlikely to possess it or be in a position to learn it. People who possess this knowledge are likely to use it in more constructive, satisfying, and profitable ways. Second, the culture of software exchange in the mainframe world differs considerably from that of the PC world--we don't see many VMS users running around with a bootable tape of the latest game... Third, very often it is easier to attack a mainframe computer by using some security hole or a Trojan Horse, instead of by using a virus. So, computer viruses for mainframe computers are definitely possible and several already exist (see question F1). Also, some IBM PC viruses can infect any IBM PC compatible machine, even if it runs a "real" OS like Unix. For more information, refer to questions D6 and E7. Forms of malware other than computer viruses--notably Trojan Horses--are far quicker, more effective, and harder to detect than computer viruses. Nevertheless, on personal computers many more viruses are written than Trojan Horses. There are two reasons for this: 1. Since a virus is self-propogating, the number of users to which it can spread (and cause damage) can be much greater than in the case of a Trojan; 2. It's almost impossible to trace the source of a virus since (generally) viruses are not attached to any particular program. For further information on malicious programs on multi-user systems, see Matt Bishop's paper, "An Overview of Malicious Logic in a Research Environment", available by anonymous FTP on Dartmouth.edu (IP = 22.214.171.124) as pub/security/mallogic.ps. E8) Some people say that disinfecting is a bad idea. Is that true? Disinfection is completely "safe" only if the disinfecting process completely restores the non-infected state of the object. That is, not only must the virus be removed from the object, but the original length must be restored exactly, as well as any system attributes (such as time and date of last modification, fields in the header, etc). Sometimes it is necessary to be sure that the object is placed on the same sectors of the disk that it occupied prior to infection (this is particularly important for some system areas and some files from programs which use certain kinds of self-checking or copy protection). None of the currently available disinfecting programs do all this. For instance, because of the bugs that exist in many viruses and because some infection processes involve overwriting (part of) the objects of infection, some of the information about the original object may be irrevocably destroyed. Sometimes it is not even possible to detect that this information has been destroyed and to warn the user. Furthermore, some viruses corrupt information very slightly and in a random way (Nomenklatura, Ripper), so that it is not even possible to tell which objects have been corrupted. Therefore, it is usually better to replace infected objects with clean backups, provided you are certain that your backups are uninfected (see D10), or from the original media. You should try to disinfect files only if they contain some valuable data that cannot be restored from backups or recompiled from their original source. E9) Can I avoid viruses by avoiding shareware, free software or games? No. There are many documented instances in which even commercial "shrink wrapped" software was inadvertently distributed containing viruses. Avoiding shareware, freeware, games, etc, only isolates you from a vast collection of software (some of it very good, some of it very bad, most of it somewhere in between...). The important thing is not to avoid a certain type of software, but to be cautious of *any and all* newly acquired software and diskettes. Merely scanning all new software media for known viruses would be rather effective at preventing virus infections, especially when combined with some other prevention/detection strategy such as integrity management of programs. E10) Can I contract a virus on my PC by performing a "DIR" of an infected floppy disk? Assuming the PC you are using is virus free before you perform the DIR command, then the answer is "No". When you perform a DIR, the contents of the boot sector of the diskette are loaded into a buffer for use in determining disk layout etc, and certain antivirus products will scan these buffers. If a boot sector virus has infected your diskette, the virus code will be contained in the buffer, which may cause some antivirus packages to produce a message like "xyz virus found in memory...". In fact, the virus is not a threat at this point since control of the CPU is never passed to the virus code residing in the buffer. Even though the virus is really not a threat at this point, this message should not be ignored. If you get a message like this, and then reboot from a clean DOS diskette (see G8) and scan your hard-drive and find no virus, then you know that the false positive was caused by an infected boot-sector loaded into a buffer, and the diskette should be disinfected before use. The use of DIR will not infect a clean system, even if the diskette it is being performed on does contain a virus (see C8 also). Please note, however, that running DIR on a diskette can result in the infection of a clean diskette if the PC is already infected. Despite our categorical "No" answer above, there is a small risk that a virus infection could be transferred from a floppy through a DIR listing. If you use an ANSI console driver that allows key remapping, it is possible that a specially prepared diskette could reprogram your keyboard so that pressing a particular key caused an infected program on the diskette to run the next time the reprogrammed key was pressed. The risk of such an attack is very low and can easily be negated following the general advice for preventing ANSI bombs (see B14). Mac users with system software prior to version 7.0 should be aware of a greater threat in their environment. Various system resources (which can contain executable code) are loaded from the automatic access to a diskette that is part of the system building its desktop view of the diskette's contents. When such a resource is required, the most recently loaded one will be used. Thus, if a diskette with a virus- infected resource in the Desktop file is in your Mac's drive, and an uninfected copy of that resource has not subsequently loaded from elsewhere, the next time that resource is required the infected copy will be executed, along with the virus. This kind of attack was removed with the introduction of version 7.0 (and later) of the system software, which handles such things quite differently. A common Mac virus, WDEF, uses this infection path, as do a few others. Early versions of AmigaDOS are susceptible to a threat similar to the Mac WDEF virus--on inserting a diskette into the drive, the operating system runs the Disk Validator from the diskette. At least one Amiga virus, Saddam, attaches itself to Disk Validator to help it spread. Version 2.0 of AmigaDOS eliminated the threat of this type of attack by removing the need for the Disk Validator. E11) Is there any risk in copying data files from an infected floppy disk to a clean PC's hard disk? Assuming that you did not boot or run any executable programs from the infected disk, the answer generally is no. There are two caveats: 1. You should be somewhat concerned about checking the integrity of these data files as they may have been destroyed or altered by the virus. 2. If any of the "data" files are interpretable as executable by some other program (such as a Lotus macro) then these files should be treated as potentially malicious until the symptoms of the infection are known. The copying process itself is safe (given the above scenario) although you should be concerned with what type of files are being copied to avoid introducing other problems. E12) Can a DOS virus survive and spread on an OS/2 system using the HPFS file system? Yes, both file-infecting and boot sector viruses can infect HPFS partitions. File-infecting viruses function normally and can activate and do their dirty deeds, and boot sector viruses can prevent OS/2 from booting if the primary bootable partition is infected. Viruses that try to address disk sectors directly cannot function under OS/2 because the operating system prevents this activity. E13) Under OS/2 2.0+, could a virus infected DOS session infect another DOS session? Each DOS program is run in a separate Virtual DOS Machine (their memory spaces are kept separate by OS/2). However, any DOS program has almost complete access to the files and disks, so infection can occur if the virus infects files; any other DOS session that executes a program infected by a virus that makes itself memory resident would itself become infected. Also, bear in mind that generally all DOS sessions share the same copy of the command interpreter. Hence if *it* becomes infected, the virus will be active in *all* DOS sessions. E14) Can normal DOS viruses work under MS Windows? Most of them cannot. A system that runs exclusively MS Windows is, in general, more virus-resistant than a plain DOS system. The reason is that most resident viruses are not compatible with the memory management in Windows. Furthermore, most existing viruses will damage Windows applications if they try to infect them as normal (i.e. DOS) EXE files. The damaged applications will stop working and this will alert the user that something is wrong. Virus-resistant however, is by no means virus-proof. For instance, most of the well-behaved resident viruses that infect only COM files (Cascade is an excellent example), will work perfectly in a "DOS box". All non- resident COM infectors will be able to run and infect too. Aside from DOS viruses, MS Windows users can also contract several currently known Windows-specific viruses, which are able to infect Windows applications properly (i.e., they are compatible with the NewEXE file format). Any low level trapping of Interrupt 13, as by resident boot sector and MBR viruses, can also affect Windows operation, particularly if protected disk access (32BitDiskAccess=ON in SYSTEM.INI) is used. E15) Can I get a virus from reading e-mail, BBS message forums or USENET News? In general terms, the answer is no. E-mail messages and postings on BBSes and News are text data and will not be executed as programs. Computer viruses are programs, and must be executed to do anything, so the simple act of reading online messages doesn't pose a threat of catching a computer virus. There are a few provisos to be made. If your computer uses ANSI screen and keyboard controls, you may be susceptible to an ANSI bomb (see B14). An ANSI bomb may, merely by being placed in text read on the screen, temporarily redefine keys on the keyboard to perform various functions. It is, however, very unlikely that you will ever see an ANSI bomb in e-mail, or that it could do significant damage while you are reading mail. Another possibility is that mail can be used to send programs. To do this program files have to be encoded into a special form so the binary (8-bit) program files are not corrupted by transfer over the text-only (7-bit) e-mail transport medium. Probably the commonest of these encoding schemes is uuencoding, though there are several others. If you receive an encoded program, you normally have to use a decoding program or special option in your e-mail program to extract it and decode it before it can be run. Once you have extracted the program though, you should then treat it as you would any other program whose source you do not know, and test it before you run it. A third possibility is with the newer, highly-automated online systems. Some of these attempt to make online access much easier for the user by automating such features as file transfer and program updates. At least one commercial online service is known to have the capability of sending new programs to the user and to invoke those programs while the user is still online. While there is no reason to assume that any service that does this *will* infect you, any time things are going on that you are not being told about, you are at greater risk. E16) Can a virus "hide" in a GIF or JPEG file? The simple answer is "no". The complete answer is more complex. GIF and JPEG (.JPG) files contain compressed graphical information. Every now and then, rumors arise that is possible to infect those files with a virus in such a way, that it will spread when you display one of these images. This is technically impossible--no part of the GIF or JPEG format contains code that is executed by the viewer program. It *is* possible to use the least significant bit of the color information for each pixel in GIF files to store additional information, without visibly altering the quality of the picture contained in the file. This is called "steganography" and is sometimes used to transmit secretly encrypted messages. Since a virus is nothing more than information, it is possible to "encode" it into a GIF file and transmit it this way. However, the recipients must be aware that the GIF file contains such hidden information and take some deliberate steps to extract it--it cannot happen against their will.