Lando virus
Risk Assessment: Home Low | Corporate Low
Date Discovered: 2/17/2009
Date Added: 2/17/2009
Origin: N/A
Length: 16,896 bytes
Type: Trojan
Subtype: Downloader Generic
DAT Required: 5529
Description
This is a trojan detection. Unlike viruses, trojans do not self-replicate. They are spread manually, often under the premise that they are beneficial or wanted. The most common installation methods involve system or security exploitation, and unsuspecting users manually executing unknown programs. Distribution channels include email, malicious or hacked web pages, Internet Relay Chat (IRC), peer-to-peer networks, etc.
Methods of Infection
Trojans do not self-replicate. They are spread manually, often under the premise that the executable is something beneficial. Distribution channels include IRC, peer-to-peer networks, newsgroup postings, etc. However they may be downloaded by other viruses and/or Trojans to be installed on the user's system.
Many of these are mass spammed by the author to entice people into double-clicking on them. Alternately they may be installed by visiting a malicious
Virus Characteristics
This Trojan injects threads into Internet Explorer. The injected threads create outbound TCP connections to the following IPs to download a file:
78.110.175.15
66.116.131.209
76.163.147.77
76.163.124.43
76.162.92.47
76.163.202.9
64.17.143.140
71.18.215.20
81.18.249.216
76.163.46.215
94.247.2.58
195.24.76.250
The threads repeatedly try to connect to these IPs using hunderds of increasing port numbers, hoping to bypass firewall rules that allow outbound connections for valid services.
At the time of this testing, the file requested was not being served by the above IPs.
All Users:
Use current engine and DAT files for detection and removal.
Modifications made to the system Registry and/or INI files for the purposes of hooking system startup, will be successfully removed if cleaning with the recommended engine and DAT combination (or higher).
RUPAK SEARCH ENGINE
Custom Search
http://adultsexyjokes.blogspot.com/
http://funnyvalentinesms.blogspot.com/
http://funnyquestionandanswer.blogspot.com/
http://funnypoliticaljokes.blogspot.com/
http://hotcelinaphoto.blogspot.com/
http://ranimukherjeephoto.blogspot.com/
http://sexymodelphoto.blogspot.com/
http://monalisaphoto.blogspot.com/
http://deletecomputervirus.blogspot.com/
http://techniqueupdate.blogspot.com/
http://shilpashettyphoto.blogspot.com/
http://hottestsushmitasen.blogspot.com/
http://hotmonicabellucci.blogspot.com/
http://collectionofmobilewallpapers.blogspot.com/
http://funnyvalentinesms.blogspot.com/
http://funnyquestionandanswer.blogspot.com/
http://funnypoliticaljokes.blogspot.com/
http://hotcelinaphoto.blogspot.com/
http://ranimukherjeephoto.blogspot.com/
http://sexymodelphoto.blogspot.com/
http://monalisaphoto.blogspot.com/
http://deletecomputervirus.blogspot.com/
http://techniqueupdate.blogspot.com/
http://shilpashettyphoto.blogspot.com/
http://hottestsushmitasen.blogspot.com/
http://hotmonicabellucci.blogspot.com/
http://collectionofmobilewallpapers.blogspot.com/
Defrag Hard Disk Fast With Free Defraggler
Defraggler is another FREE tool from the manufacture of CCleaner and Recuva, both of these programs has been on the top of their category.
Defraggler is another FREE tool which is quite fast in use and its operation, I have just tested Defraggler on my laptop it really saves a hell lot of time in analysing as compared to the conventional defragmentation comes embedded in windows
Just like windows defragmentation you can also schedule defragmentation on Daily, Weekly, Monthly with Defraggler.
Let’s see how can you schedule defrag with Defraggler and discuss what more features it can offer.
Schedule Defragmentation With Defraggler
Defraggler is better than the other tools in the market for disk defragmentation as it performs the defragmentation very fast as compared to other tools. It can also simply defrag the files you want without processing the whole drive.
Other Features of Defraggler
Defrag Individual Drives – Defraggler lets you defrag the individual files and folders which again is very time saving and usable when you want to defrag the selected files not the entire drive.
Defraggler is Portable – Defraggler is again very portable as it results in a single exe file after installation which you can take any where on your USB Pen drive.
Defraggler is Supported on all Windows – Unlike the other free programs for defragmentation Defraggler is supports almost all windows version released after Windows 2000 including 2003, XP and Vista. 64-bit.
Locate Files on the Drive – After analysis Defraggler lists all the fragmented files on the drive and by selecting them you can see their location. You can see the list of Fragmented files by clicking the view files button after analyse is complete.
Note: Defraggler is 100% completely free for both corporate and individual use.
Download Defraggler
Ten Tips for ProtectingYour Computer
1.Use protection software "anti-virus software" and keep it up to date.
Make sure you have anti-virus software on your computer! Anti-virus software
is designed to protect you and your computer against known viruses so you don't
have to worry. But with new viruses emerging daily, anti-virus programs need
regular updates, like annual flu shots, to recognize these new viruses. Be sure to
update your anti-virus software regularly! The more often you keep it updated, say
once a week, the better. Check with the web site of your anti-virus software
company to see some sample descriptions of viruses and to get regular updates for
your software. Stop viruses in their tracks!
2.Don't open email from unknown sources.
A simple rule of thumb is that if you don't know the person who is sending
you an email, be very careful about opening the email and any file attached to it.
Should you receive a suspicious email, the best thing to do is to delete the
entire message, including any attachment. Even if you do know the person sending
you the email, you should exercise caution if the message is strange and
unexpected, particularly if it contains unusual hyperlinks. Your friend may have
accidentally sent you a virus. Such was the case with the "I Love You" virus that
spread to millions of people in 2001. When in doubt, delete!
3. Use hard-to-guess passwords.
Passwords will only keep outsiders out if they are difficult to guess! Don't
share your password, and don't use the same password in more than one place. If
someone should happen to guess one of your passwords, you don't want them to be
able to use it in other places. The golden rules of passwords are: (1) A password
should have a minimum of 8 characters, be as meaningless as possible, and use
uppercase letters, lowercase letters and numbers, e.g., xk28LP97. (2) Change
passwords regularly, at least every 90 days. (3) Do not give out your password to
anyone!
4.Protect your computer from Internet intruders -use "firewalls".
Equip your computer with a firewall! Firewalls create a protective wall
between your computer and the outside world. They come in two forms, software
firewalls that run on your personal computer and hardware firewalls that protect a
number of computers at the same time. They work by filtering out unauthorized or
potentially dangerous types of data from the Internet, while still allowing other
(good) data to reach your computer. Firewalls also ensure that unauthorized
persons can't gain access to your computer while you're connected to the Internet.
You can find firewall hardware and software at most computer stores nationwide.
5. Don't share access to your computers with strangers.
Your computer operating system may allow other computers on a network,
including the Internet, to access the hard-drive of your computer in order to
"share files". This ability to share files can be used to infect your computer
with a virus or look at the files on your computer if you don't pay close
attention. So, unless you really need this ability, make sure you turn off filesharing.
Check your operating system and your other program help files to learn
how to disable file sharing. Don't share access to your computer with strangers!
6. Disconnect from the Internet when not in use.
Remember that the Digital Highway is a two-way road. You send and receive
information on it. Disconnecting your computer from the Internet when you're not
online lessens the chance that someone will be able to access your computer. And
if you haven't kept your anti-virus software up-to-date, or don't have a firewall
in place, someone could infect your computer or use it to harm someone else on the
Internet. Be safe and disconnect!
7. Back up your computer data.
Experienced computer users know that there are two types of people: those
who have already lost data and those who are going to experience the pain of
losing data in the future. Back up small amounts of data on floppy disks and
larger amounts on CDs. If you have access to a network, save copies of your data
on another computer in the network. Most people make weekly backups of all their
important data. And make sure you have your original software start-up disks handy
and available in the event your computer system files get damaged. Be prepared!
8. Regularly download security protection update "patches".
Most major software companies today have to release updates and patches to
their software every so often. Sometimes bugs are discovered in a program that may
allow a malicious person to attack your computer. When these bugs are discovered,
the software companies, or vendors, create patches that they post on their web
sites. You need to be sure you download and install the patches! Check your
software vendors' web sites on a regular basis for new security patches or use the
new automated patching features that some companies offer. If you don't have the
time to do the work yourself, download and install a utility program to do it for
you. There are available software programs that can perform this task for you.
9. Check your security on a regular basis.
The programs and operating system on your computer have many valuable
features that make your life easier, but can also leave you vulnerable to hackers
and viruses. You should evaluate your computer security at least twice a year.
Look at the settings on applications that you have on your computer. Your browser
software, for example, typically has a security setting in its preferences area.
Check what settings you have and make sure you have the security level appropriate
for you. Set a high bar for yourself!
10. Make sure your family members and/or your employees know what to do if your computer becomes infected.
It's important that everyone who uses a computer be aware of proper security
practices. People should know how to update virus protection software, how to
download security patches from software vendors and how to create a proper
password. Make sure they know these tips too!
Specific Virus and Antivirus Software Questions...(for computer)
===============================================
G1) I was infected by the Jerusalem virus and disinfected the infected
files with my favorite antivirus program. However, WordPerfect
and some other programs still refuse to work. Why?
The Jerusalem virus and WordPerfect 4.2 program combination is an
example of a virus and program that cannot be completely disinfected by
an antivirus tool. In some cases such as this, the virus will destroy
code by overwriting it instead of appending itself to the file. The
only solution is to re-install the programs from clean (non-infected)
backups or distribution media (see D10 and E8).
G2) Is my disk infected with the Stoned virus?
Of course the answer to this, and many similar questions, is to obtain a
good virus detector. There are many to choose from, including ones that
will scan diskettes automatically as you use them. As Stoned is a boot
sector infector, remember to check all diskettes, even non-system or
"data" diskettes (see E1).
It is possible, if you have an urgent need to check a system when you
don't have any antivirus tools, to run CHKDSK or MEM and note down the
values reported (see C1) and then to boot from a known clean system
diskette and compare the results returned by CHKDSK or MEM. If the
total amount of conventional memory reported is different between the
two boots then you may have a viral problem but this information alone
cannot tell us if it is Stoned. If you cannot see the PC's hard disk
(usually the C: drive) then it is even more likely you have a virus
problem, though definitely not Stoned. If you have a "disk editor" type
program, looking at the boot sector of a suspect floppy, or the MBR of
the suspect hard drive may be helpful. If you have Stoned, the first
byte will indicate the characteristic far jump of the virus (hex: EA)
instead of the more common short jump (hex: EB) of the boot loader.
Even if that is the first byte, you could be looking at a perfectly good
disk that has been "inoculated" against the virus *or* is infected with
some other virus which makes similar changes, or at a diskette that
seems safe but contains a totally different type of virus.
G3) I was told that the Stoned virus displays the text "Your PC is now
Stoned" at boot time. I have been infected by this virus several
times, but have never seen the message. Why?
The "original" Stoned message was ".Your PC is now Stoned!", where the
"." represents the "bell" character (ASCII 7 or "PC speaker beep"). The
message is displayed with a probability of 1 in 8 *only* when a PC is
booted from an infected *diskette*. When booting from an infected hard
disk, Stoned never displays this message.
Further, versions of Stoned with no message whatsoever or only the
leading bell character have become very common. These versions of
Stoned are likely to go unnoticed by all but the most observant, even
when regularly booting from infected diskettes.
Contrary to some reports, the Stoned virus does *not* display the
message "LEGALISE MARIJUANA", although such a string is quite clearly
visible in the boot sectors of diskettes and MBR's of hard disks
infected with the "original" version of Stoned.
G4) I was infected by both Stoned and Michelangelo. Why has my
computer become unbootable? And why, each time I run my favorite
scanner, does it find one of the viruses and say that it is
removed, but when I run it again, it says that the virus is still
there?
These two viruses store the original Master Boot Record at one and the
same place on the hard disk. They do not recognize each other, and
therefore a computer can become infected with both of them at the same
time.
The first of these viruses that infects the computer will overwrite the
Master Boot Record with its body and store the original MBR at a certain
place on the disk. So far, this is normal for a boot-record virus. But
if now the other virus infects the computer too, it will replace the MBR
(which now contains the virus that has come first) with its own body,
and store what it believes is the original MBR (but in fact is the body
of the first virus) *at the same place* on the hard disk, thus
*overwriting* the original MBR. When this happens, the contents of the
original MBR are lost. Therefore the disk becomes non-bootable.
When a virus removal program inspects such a hard disk, it will see the
*second* virus in the MBR and will try to remove it by overwriting it
with the contents of the sector where this virus normally stores the
original MBR. However, now this sector contains the body of the *first*
virus. Therefore, the virus removal program will install the first
virus in trying to remove the second. In all probability it will not
wipe out the sector where the (infected) MBR has been stored.
When the program is run again, it will find the *first* virus in the
MBR. By trying to remove it, the program will get the contents of the
sector where this virus normally stores the original MBR, and will move
it over the current (infected) MBR. Unfortunately, this sector still
contains the body of the *first* virus. Therefore, the body of this
virus will be re-installed over the MBR ad infinitum.
There is no easy solution to this problem, since the contents of the
original MBR are lost. The only solution for the antivirus program is
to detect that there is a problem, and to overwrite the contents of the
MBR with a valid MBR program, which the antivirus program has to provide
itself. If your favorite antivirus program is not that smart, consider
replacing it with a better one, or try using the boot sector
disinfection procedure described elsewhere (see C3).
In general, infection of the same file or area by multiple viruses is
possible and vital areas of the original may be lost. This can make it
difficult or impossible for virus disinfection tools to be effective,
and replacement of the lost file/area will be necessary.
G5) My scanner finds the Filler and/or Israeli Boot virus in memory,
but after I boot from a clean floppy it reports no viruses. Am I
infected?
This is almost certainly a "false positive" (see C5). One particular,
popular antivirus product (usually its TSR scanner/monitor VSAFE) leaves
its scan strings in memory in an unencoded form, and is well-known for
causing false positives on Filler and Israeli Boot. Your other scanner
sees the first's scan strings (at least those for Filler and/or Israeli
Boot) and reports a virus in memory. When you boot from a floppy you
(probably) are not loading the resident scanner, so it doesn't have a
chance to "booby-trap" your other scanner. To fix this problem, try
adding "REM " to the beginning of the line in your AUTOEXEC.BAT or
CONFIG.SYS file that loads the suspect TSR, and see if the problem
disappears.
G6) I was infected with Flip and now a large part of my hard disk
seems to have disappeared. What has happened?
Flip has a logic error, probably based on its author only knowing about
hard disk partitioning schemes under DOS 3.x (where partitions could not
exceed 32MB in size).
Part of Flip's infection routine decrements by six the "total number of
sectors" field in the BIOS Parameter Block (BPB--a table of critical
disk geometry data) in the DOS boot sector of the boot partition. For
partitions of 32MB and under this field is meaningful, but in larger
partitions, this field is set to zero and a field in the "extended BPB"
contains the "big number of sectors" for that partition instead. Not
knowing about larger partitions, Flip renders the large partitions it
meets a shade under 32MB. The fix for this is to use a disk sector
editor to set the word at offset 13h of the affected DOS boot sector to
"00 00" (they should be set to "FA FF" if the situation above applies).
If you don't understand these instructions, do *not* attempt to follow
them and seek the help of a more technically knowledgeable person.
G7) What does the GenB and/or the GenP virus do?
There is no such thing as *the* GenB or GenP virus. It is a heuristic
used by a very popular scanner to detect boot sector viruses and means
"There is something very suspicious in the boot sector (GenB) or in the
MBR (GenP), and I am pretty sure that it is a virus, however, I have no
idea which particular virus it might be". You should run a scanner
which has better recognition and identification capabilities (see B15),
if you want to know which particular virus you have. One advantage of
the GenB/GenP report is that you can often use the disinfection utility
from the same producer to remove the virus, even if no other scanner can
remove it. When told to remove the GenB/GenP "virus", the utility scans
the disk for something that looks like a saved copy of the original boot
sector or MBR and will put it back in place, thus removing the virus, or
it writes a good generic MBR if there is an apparently valid partition
table in the virus MBR.
G8) How do I "boot from a clean floppy"?
"Put it in the A: drive and turn the power on."
The facetious answer aside, the real question here is usually more one
of "How do I ensure I have a clean boot floppy?"
As with so many issues concerning viruses, the important thing is to be
prepared *in advance*. As with backups, a current, clean boot disk
should be a standard part of every personal computer system, as there
are other occasions than when facing a real or suspected virus infection
where being able to boot your computer to a "known good" state are
useful or desirable (e.g. you accidentally delete your disk-compression
driver from your hard disk). As with backups, a current, clean boot
disk is one of the standard parts of a personal computer system most
commonly missing.
The important thing in preparing a clean boot diskette, especially where
it has to be used with a (suspected) virus infection, is that it must
*not* run a single byte of code from your hard disk. This means your
boot floppy must contain all the basic operating system files, device
drivers and configuration commands necessary to make your system
minimally usable. This diskette must be prepared on a system that is,
itself, guaranteed "clean" and it should be write-protected immediately
after it is completed. Aside from a basic, minimal operating system,
your emergency boot diskette should contain the utilities necessary to
install your OS to a hard disk *and* basic diagnostic or "fix it"
programs and your favorite antivirus tools. Depending upon disk space
considerations, you may need additional diskettes to hold all these
utilities. For example, if you use DOS it is a good idea to copy the
following utility programs to your emergency boot disk (if your version
of DOS includes them): FDISK, CHKDSK and/or SCANDISK, FORMAT, SYS, MEM,
UNFORMAT, UNDELETE, MSD.
When it comes to rebooting your computer from a clean system disk, it is
most important that you perform a "cold start". On a PC, this means
pressing the reset button or turning the power off on again, *not* by
pressing Ctrl-Alt-Del. Regardless of the machine type, if you are
unsure, use the power off then power on method just described. It is
even more important that your machine is correctly configured to try
booting from the floppy first. Most contemporary BIOSes have an option
to select the boot order (A: then C: or C: then A:)--this must be set to
A: then C: for this procedure, though normally we strongly recommend
that you set this option to C: then A:.
As systems change from time to time, you may occasionally need to update
this most critical of diskettes so it will still boot your system to a
usable state. As you may have recently contracted a new virus that
bypasses your current antivirus precautions, this update process can put
you at risk of infecting your "clean" emergency boot diskette. Because
of this, it is prudent to have two such diskettes. With system changes
you would update these in a "leap frog" manner. This means your
previous emergency boot diskette might still bring your machine up to a
minimally useful state (such that you may still be able to make repairs)
should your updated emergency boot diskette be infected by a previously
unknown virus.
Unfortunately, this isn't the whole story either! A PC virus known as
EXE_Bug can fake out the boot process by setting the PC's CMOS to look
as if there are no floppy drives in the machine. Most BIOS'es don't
even try to boot from a floppy in this case, and go straight to the hard
disk, loading the virus from the MBR. When EXE_Bug first loads into
memory, it checks to see if there is a diskette in the first floppy
drive, and if there is, it loads the boot sector from the diskette and
lets the floppy boot as normal. Most people don't notice the subtly
different boot time and drive access order involved in this, so they
think they have booted clean, when in fact the virus is active in
memory! To circumvent this possibility, you have to check the PC's CMOS
settings before letting the floppy boot proceed, make sure that your PC
"knows" it has a floppy drive, *and*, with some PCs, make sure that the
boot order option is set to "A: then C:". This presents a chicken-and-
egg situation on some machines, as you may have to boot DOS on the
machine to be able to run the utility program that lets you change its
CMOS settings.
Remember, if you changed your BIOS's boot order option, set it back to
C: then A: after disinfecting your PC.
G9) My PC diagnostic utility lists "Cascade" amongst the hardware
interrupts (IRQs). Does this mean I have the Cascade virus?
No! This is quite normal on AT-style (286 and better) PCs (and on a few
8086 (XT) class machines). The original IBM PC design had one
Programmable Interrupt Controller (PIC) to handle hardware interrupts
generated when devices like disk controllers, serial and parallel ports,
LAN adaptors, etc have to be serviced. While developing the AT, IBM
decided that the eight Interrupt ReQuest (IRQ) lines the original PIC
supported were probably insufficient for likely future expansion needs,
so they added a second PIC. The two PIC's had to cooperate, so both
didn't interrupt the CPU concurrently. This was achieved by having the
second PIC use an IRQ to signal the first PIC when it has an IRQ to
service. IRQs 2 and 9 were used for this and are commonly called the
"cascade" IRQ, as they allow the second PIC to cascade an IRQ down to
the first PIC.
G10) Occasionally the text "welcome datacomp" appears in my Mac
documents without me typing it. Is this a virus?
Most likely not. This phenomenon has been reported for a particular
make/model of third-party Macintosh-compatible keyboard. It appears to
be a practical joke, coded into the keyboard's ROM, that causes the
keyboard to output that text (as if it was typed) after a period of
keyboard inactivity. The only practical fix is to replace the keyboard.
This is, in effect, a hardware (technically "firmware") Trojan Horse--
the keyboard has features or functions that are not advertised and that
will be performed without the owner's or user's wish or permission.
G11) How good are the antivirus tools included with MS-DOS 6?
While this FAQ sheet avoids answering specific questions about
particular antivirus software (partly because the ground tends to move
very quickly!), the antivirus tools included with MS-DOS 6 are very
widely distributed and accessible. We will not give a wide-ranging
answer here, but will point out that Microsoft Corporation does not use
MSAV but a competitor's product. We suggest that anyone considering
using the antivirus tools supplied with MS-DOS 6 as a significant part
of their virus defense should read the review available by anonymous FTP
from (amongst others) ftp.informatik.uni-hamburg.de (IP = 134.100.4.42)
as /pub/virus/texts/viruses/msaveval.zip.
G12) When I do a "DIR MORE", I see two files with random names that
are not there when I just use "DIR". On my friends's system they
cannot be seen. Do I have a virus?
No. DOS's default commandline interpreter (COMMAND.COM) creates two
temporary files with unique names for every pipe character ("") used on
the command line. Starting with DOS version 5.0, these files are
created in the directory pointed to by the TEMP environment variable,
not in the current directory as they were in earlier DOS versions. If
your TEMP setting is invalid or you have an earlier version of DOS you
will see these files in the current directory when you pipe the output
of a DIR command through MORE (or any other filter). If you don't see
these files in the current directory's listing, performing the command
"DIR MORE" on the directory specified by the TEMP variable will reveal
them.
Generally, you would be better to use "DIR /P" instead of "DIR MORE",
as this avoids the creation of the temporary files. If you use an
alternative commandline interpreter, none of the above may apply.
G13) What is the ChipAway virus? (Or ChipAwayVirus?)
The ChipAway virus is not a virus at all. In fact, it is a poorly
chosen name for a good idea. Many PCs have an advanced BIOS feature
that, when activated, prevents any writes to the MBR through BIOS disk
routines. If active, this feature can cause problems if you install non-
DOS operating systems (like OS/2, Windows 95 or Windows NT), as their
installation routines typically need to write to the MBR, but for
general purpose computers, it is a good idea to turn on these options,
if they exist.
Unfortunately, one of the earliest and most widely available
implementations of this idea prints a message on screen at each system
startup to the effect "ChipAwayVirus installed". This is supposed to
calm the owner's nerves, making them confident that their BIOS antivirus
system is working for them. For fairly obvious reasons, it tends to
have the opposite effect!
G1) I was infected by the Jerusalem virus and disinfected the infected
files with my favorite antivirus program. However, WordPerfect
and some other programs still refuse to work. Why?
The Jerusalem virus and WordPerfect 4.2 program combination is an
example of a virus and program that cannot be completely disinfected by
an antivirus tool. In some cases such as this, the virus will destroy
code by overwriting it instead of appending itself to the file. The
only solution is to re-install the programs from clean (non-infected)
backups or distribution media (see D10 and E8).
G2) Is my disk infected with the Stoned virus?
Of course the answer to this, and many similar questions, is to obtain a
good virus detector. There are many to choose from, including ones that
will scan diskettes automatically as you use them. As Stoned is a boot
sector infector, remember to check all diskettes, even non-system or
"data" diskettes (see E1).
It is possible, if you have an urgent need to check a system when you
don't have any antivirus tools, to run CHKDSK or MEM and note down the
values reported (see C1) and then to boot from a known clean system
diskette and compare the results returned by CHKDSK or MEM. If the
total amount of conventional memory reported is different between the
two boots then you may have a viral problem but this information alone
cannot tell us if it is Stoned. If you cannot see the PC's hard disk
(usually the C: drive) then it is even more likely you have a virus
problem, though definitely not Stoned. If you have a "disk editor" type
program, looking at the boot sector of a suspect floppy, or the MBR of
the suspect hard drive may be helpful. If you have Stoned, the first
byte will indicate the characteristic far jump of the virus (hex: EA)
instead of the more common short jump (hex: EB) of the boot loader.
Even if that is the first byte, you could be looking at a perfectly good
disk that has been "inoculated" against the virus *or* is infected with
some other virus which makes similar changes, or at a diskette that
seems safe but contains a totally different type of virus.
G3) I was told that the Stoned virus displays the text "Your PC is now
Stoned" at boot time. I have been infected by this virus several
times, but have never seen the message. Why?
The "original" Stoned message was ".Your PC is now Stoned!", where the
"." represents the "bell" character (ASCII 7 or "PC speaker beep"). The
message is displayed with a probability of 1 in 8 *only* when a PC is
booted from an infected *diskette*. When booting from an infected hard
disk, Stoned never displays this message.
Further, versions of Stoned with no message whatsoever or only the
leading bell character have become very common. These versions of
Stoned are likely to go unnoticed by all but the most observant, even
when regularly booting from infected diskettes.
Contrary to some reports, the Stoned virus does *not* display the
message "LEGALISE MARIJUANA", although such a string is quite clearly
visible in the boot sectors of diskettes and MBR's of hard disks
infected with the "original" version of Stoned.
G4) I was infected by both Stoned and Michelangelo. Why has my
computer become unbootable? And why, each time I run my favorite
scanner, does it find one of the viruses and say that it is
removed, but when I run it again, it says that the virus is still
there?
These two viruses store the original Master Boot Record at one and the
same place on the hard disk. They do not recognize each other, and
therefore a computer can become infected with both of them at the same
time.
The first of these viruses that infects the computer will overwrite the
Master Boot Record with its body and store the original MBR at a certain
place on the disk. So far, this is normal for a boot-record virus. But
if now the other virus infects the computer too, it will replace the MBR
(which now contains the virus that has come first) with its own body,
and store what it believes is the original MBR (but in fact is the body
of the first virus) *at the same place* on the hard disk, thus
*overwriting* the original MBR. When this happens, the contents of the
original MBR are lost. Therefore the disk becomes non-bootable.
When a virus removal program inspects such a hard disk, it will see the
*second* virus in the MBR and will try to remove it by overwriting it
with the contents of the sector where this virus normally stores the
original MBR. However, now this sector contains the body of the *first*
virus. Therefore, the virus removal program will install the first
virus in trying to remove the second. In all probability it will not
wipe out the sector where the (infected) MBR has been stored.
When the program is run again, it will find the *first* virus in the
MBR. By trying to remove it, the program will get the contents of the
sector where this virus normally stores the original MBR, and will move
it over the current (infected) MBR. Unfortunately, this sector still
contains the body of the *first* virus. Therefore, the body of this
virus will be re-installed over the MBR ad infinitum.
There is no easy solution to this problem, since the contents of the
original MBR are lost. The only solution for the antivirus program is
to detect that there is a problem, and to overwrite the contents of the
MBR with a valid MBR program, which the antivirus program has to provide
itself. If your favorite antivirus program is not that smart, consider
replacing it with a better one, or try using the boot sector
disinfection procedure described elsewhere (see C3).
In general, infection of the same file or area by multiple viruses is
possible and vital areas of the original may be lost. This can make it
difficult or impossible for virus disinfection tools to be effective,
and replacement of the lost file/area will be necessary.
G5) My scanner finds the Filler and/or Israeli Boot virus in memory,
but after I boot from a clean floppy it reports no viruses. Am I
infected?
This is almost certainly a "false positive" (see C5). One particular,
popular antivirus product (usually its TSR scanner/monitor VSAFE) leaves
its scan strings in memory in an unencoded form, and is well-known for
causing false positives on Filler and Israeli Boot. Your other scanner
sees the first's scan strings (at least those for Filler and/or Israeli
Boot) and reports a virus in memory. When you boot from a floppy you
(probably) are not loading the resident scanner, so it doesn't have a
chance to "booby-trap" your other scanner. To fix this problem, try
adding "REM " to the beginning of the line in your AUTOEXEC.BAT or
CONFIG.SYS file that loads the suspect TSR, and see if the problem
disappears.
G6) I was infected with Flip and now a large part of my hard disk
seems to have disappeared. What has happened?
Flip has a logic error, probably based on its author only knowing about
hard disk partitioning schemes under DOS 3.x (where partitions could not
exceed 32MB in size).
Part of Flip's infection routine decrements by six the "total number of
sectors" field in the BIOS Parameter Block (BPB--a table of critical
disk geometry data) in the DOS boot sector of the boot partition. For
partitions of 32MB and under this field is meaningful, but in larger
partitions, this field is set to zero and a field in the "extended BPB"
contains the "big number of sectors" for that partition instead. Not
knowing about larger partitions, Flip renders the large partitions it
meets a shade under 32MB. The fix for this is to use a disk sector
editor to set the word at offset 13h of the affected DOS boot sector to
"00 00" (they should be set to "FA FF" if the situation above applies).
If you don't understand these instructions, do *not* attempt to follow
them and seek the help of a more technically knowledgeable person.
G7) What does the GenB and/or the GenP virus do?
There is no such thing as *the* GenB or GenP virus. It is a heuristic
used by a very popular scanner to detect boot sector viruses and means
"There is something very suspicious in the boot sector (GenB) or in the
MBR (GenP), and I am pretty sure that it is a virus, however, I have no
idea which particular virus it might be". You should run a scanner
which has better recognition and identification capabilities (see B15),
if you want to know which particular virus you have. One advantage of
the GenB/GenP report is that you can often use the disinfection utility
from the same producer to remove the virus, even if no other scanner can
remove it. When told to remove the GenB/GenP "virus", the utility scans
the disk for something that looks like a saved copy of the original boot
sector or MBR and will put it back in place, thus removing the virus, or
it writes a good generic MBR if there is an apparently valid partition
table in the virus MBR.
G8) How do I "boot from a clean floppy"?
"Put it in the A: drive and turn the power on."
The facetious answer aside, the real question here is usually more one
of "How do I ensure I have a clean boot floppy?"
As with so many issues concerning viruses, the important thing is to be
prepared *in advance*. As with backups, a current, clean boot disk
should be a standard part of every personal computer system, as there
are other occasions than when facing a real or suspected virus infection
where being able to boot your computer to a "known good" state are
useful or desirable (e.g. you accidentally delete your disk-compression
driver from your hard disk). As with backups, a current, clean boot
disk is one of the standard parts of a personal computer system most
commonly missing.
The important thing in preparing a clean boot diskette, especially where
it has to be used with a (suspected) virus infection, is that it must
*not* run a single byte of code from your hard disk. This means your
boot floppy must contain all the basic operating system files, device
drivers and configuration commands necessary to make your system
minimally usable. This diskette must be prepared on a system that is,
itself, guaranteed "clean" and it should be write-protected immediately
after it is completed. Aside from a basic, minimal operating system,
your emergency boot diskette should contain the utilities necessary to
install your OS to a hard disk *and* basic diagnostic or "fix it"
programs and your favorite antivirus tools. Depending upon disk space
considerations, you may need additional diskettes to hold all these
utilities. For example, if you use DOS it is a good idea to copy the
following utility programs to your emergency boot disk (if your version
of DOS includes them): FDISK, CHKDSK and/or SCANDISK, FORMAT, SYS, MEM,
UNFORMAT, UNDELETE, MSD.
When it comes to rebooting your computer from a clean system disk, it is
most important that you perform a "cold start". On a PC, this means
pressing the reset button or turning the power off on again, *not* by
pressing Ctrl-Alt-Del. Regardless of the machine type, if you are
unsure, use the power off then power on method just described. It is
even more important that your machine is correctly configured to try
booting from the floppy first. Most contemporary BIOSes have an option
to select the boot order (A: then C: or C: then A:)--this must be set to
A: then C: for this procedure, though normally we strongly recommend
that you set this option to C: then A:.
As systems change from time to time, you may occasionally need to update
this most critical of diskettes so it will still boot your system to a
usable state. As you may have recently contracted a new virus that
bypasses your current antivirus precautions, this update process can put
you at risk of infecting your "clean" emergency boot diskette. Because
of this, it is prudent to have two such diskettes. With system changes
you would update these in a "leap frog" manner. This means your
previous emergency boot diskette might still bring your machine up to a
minimally useful state (such that you may still be able to make repairs)
should your updated emergency boot diskette be infected by a previously
unknown virus.
Unfortunately, this isn't the whole story either! A PC virus known as
EXE_Bug can fake out the boot process by setting the PC's CMOS to look
as if there are no floppy drives in the machine. Most BIOS'es don't
even try to boot from a floppy in this case, and go straight to the hard
disk, loading the virus from the MBR. When EXE_Bug first loads into
memory, it checks to see if there is a diskette in the first floppy
drive, and if there is, it loads the boot sector from the diskette and
lets the floppy boot as normal. Most people don't notice the subtly
different boot time and drive access order involved in this, so they
think they have booted clean, when in fact the virus is active in
memory! To circumvent this possibility, you have to check the PC's CMOS
settings before letting the floppy boot proceed, make sure that your PC
"knows" it has a floppy drive, *and*, with some PCs, make sure that the
boot order option is set to "A: then C:". This presents a chicken-and-
egg situation on some machines, as you may have to boot DOS on the
machine to be able to run the utility program that lets you change its
CMOS settings.
Remember, if you changed your BIOS's boot order option, set it back to
C: then A: after disinfecting your PC.
G9) My PC diagnostic utility lists "Cascade" amongst the hardware
interrupts (IRQs). Does this mean I have the Cascade virus?
No! This is quite normal on AT-style (286 and better) PCs (and on a few
8086 (XT) class machines). The original IBM PC design had one
Programmable Interrupt Controller (PIC) to handle hardware interrupts
generated when devices like disk controllers, serial and parallel ports,
LAN adaptors, etc have to be serviced. While developing the AT, IBM
decided that the eight Interrupt ReQuest (IRQ) lines the original PIC
supported were probably insufficient for likely future expansion needs,
so they added a second PIC. The two PIC's had to cooperate, so both
didn't interrupt the CPU concurrently. This was achieved by having the
second PIC use an IRQ to signal the first PIC when it has an IRQ to
service. IRQs 2 and 9 were used for this and are commonly called the
"cascade" IRQ, as they allow the second PIC to cascade an IRQ down to
the first PIC.
G10) Occasionally the text "welcome datacomp" appears in my Mac
documents without me typing it. Is this a virus?
Most likely not. This phenomenon has been reported for a particular
make/model of third-party Macintosh-compatible keyboard. It appears to
be a practical joke, coded into the keyboard's ROM, that causes the
keyboard to output that text (as if it was typed) after a period of
keyboard inactivity. The only practical fix is to replace the keyboard.
This is, in effect, a hardware (technically "firmware") Trojan Horse--
the keyboard has features or functions that are not advertised and that
will be performed without the owner's or user's wish or permission.
G11) How good are the antivirus tools included with MS-DOS 6?
While this FAQ sheet avoids answering specific questions about
particular antivirus software (partly because the ground tends to move
very quickly!), the antivirus tools included with MS-DOS 6 are very
widely distributed and accessible. We will not give a wide-ranging
answer here, but will point out that Microsoft Corporation does not use
MSAV but a competitor's product. We suggest that anyone considering
using the antivirus tools supplied with MS-DOS 6 as a significant part
of their virus defense should read the review available by anonymous FTP
from (amongst others) ftp.informatik.uni-hamburg.de (IP = 134.100.4.42)
as /pub/virus/texts/viruses/msaveval.zip.
G12) When I do a "DIR MORE", I see two files with random names that
are not there when I just use "DIR". On my friends's system they
cannot be seen. Do I have a virus?
No. DOS's default commandline interpreter (COMMAND.COM) creates two
temporary files with unique names for every pipe character ("") used on
the command line. Starting with DOS version 5.0, these files are
created in the directory pointed to by the TEMP environment variable,
not in the current directory as they were in earlier DOS versions. If
your TEMP setting is invalid or you have an earlier version of DOS you
will see these files in the current directory when you pipe the output
of a DIR command through MORE (or any other filter). If you don't see
these files in the current directory's listing, performing the command
"DIR MORE" on the directory specified by the TEMP variable will reveal
them.
Generally, you would be better to use "DIR /P" instead of "DIR MORE",
as this avoids the creation of the temporary files. If you use an
alternative commandline interpreter, none of the above may apply.
G13) What is the ChipAway virus? (Or ChipAwayVirus?)
The ChipAway virus is not a virus at all. In fact, it is a poorly
chosen name for a good idea. Many PCs have an advanced BIOS feature
that, when activated, prevents any writes to the MBR through BIOS disk
routines. If active, this feature can cause problems if you install non-
DOS operating systems (like OS/2, Windows 95 or Windows NT), as their
installation routines typically need to write to the MBR, but for
general purpose computers, it is a good idea to turn on these options,
if they exist.
Unfortunately, one of the earliest and most widely available
implementations of this idea prints a message on screen at each system
startup to the effect "ChipAwayVirus installed". This is supposed to
calm the owner's nerves, making them confident that their BIOS antivirus
system is working for them. For fairly obvious reasons, it tends to
have the opposite effect!
Miscellaneous most asked Questions for computer viruses
========================================
F1) How many viruses are there?
It is not possible to give an exact number because new viruses are
literally being created every day. Furthermore, different antivirus
researchers use different criteria to decide whether two viruses are
different or one and the same. Some count viruses as different if they
differ by at least one bit in their non-variable code. Others group
viruses in families and do not count the closely related variants within
a family as different viruses.
Further, some antivirus researchers have samples in their collections
that they count as viruses, but that several other experts strongly deny
are viruses. Sometimes these are "partial viruses", where a virus has
not properly infected a host and are therefore non-infective, other
times they are well-known non-viruses. As some of these non-viruses are
known to be in some of the common test sets, some antivirus software
vendors count them amongst the viruses they detect.
As of January 1995 there were about 5,600 PC viruses, about 150 Amiga
viruses, about 100 Acorn Archimedes viruses, about 45 Macintosh viruses,
several Atari ST viruses, a few Apple II viruses, four Unix viruses,
three MS Windows viruses, at least two OS/2 viruses and two VMS DCL-
based viruses.
Fortunately, few of the existing viruses are widespread. For instance,
only about three dozen of the known PC viruses cause most of the
reported infections and fewer than 200 PC viruses have been found in the
wild at all.
F2) How do viruses spread so quickly?
This is a very complex issue, and some viruses don't spread quickly at
all (though talk of them often does!).
Those that do spread widely are able to do so for a variety of reasons.
A large target population--millions of compatible computers--helps. A
large virus population helps. Vendors whose quality assurance relies
on, for example, outdated scanners, help. Users who gratuitously
install new software on their systems without making any attempt to test
for viruses help. All of these things are factors.
F3) What is the correct plural of "virus"? "Viruses" or "viri" or
"virii" or "vira" or...
The correct English plural of "virus" is "viruses". The Latin word is a
mass noun (like "air") and, therefore, there is no correct Latin plural.
Please use "viruses", and if people use other forms, please do *not* use
Virus-L/comp.virus to correct them.
F4) When reporting a virus infection (and looking for assistance), what
information should be included?
People frequently post messages to Virus-L/comp.virus requesting
assistance with a suspected virus problem. Quite often the information
supplied is insufficient for the various experts on the list to be able
to help at all. Also, please note that any such assistance from members
of the list is provided on a voluntary basis; be grateful for any help
received. Try to provide the following information in your requests for
assistance:
1. The date and location (town and country) of suspected
infection.
2. The name of the virus (if known)
3. The program (or programs) and version that called the virus
by that name.
4. Any other antivirus software that you are running and whether
it has been able to detect the virus or not, and if yes, what
name it called the virus.
5. Your software and hardware configuration (computer type,
kinds of disk(ette) drives, amount of memory and
configuration (extended/expanded/conventional), the exact
version of your OS, TSR programs and device drivers used,
control panels and INITs, etc.).
6. Any "unusual" behavior that has occurred recently and any new
software (including upgrades) you have recently installed.
It is helpful if you can use more than one scanning program to identify
a virus, and to say which scanner gave which identification. However,
some scanning programs leave "scan strings" in memory which will confuse
others, so it is best to do a "cold reboot" between runs of successive
scanners, particularly if you are getting conflicting results (see C6).
F5) How often should we upgrade our antivirus tools to minimize
software and labor costs and maximize our protection?
This is a difficult question to answer. Antivirus software is a kind of
insurance, and these type of calculations are difficult.
There are two things to watch out for here: the general "style" of the
software, and the scan strings that scanners use to identify viruses.
Scanners should be updated more frequently than other software, and it
is probably a good idea to update a scanner's set of scan strings at
least once every two months. In the six or so months prior to January
1995, most of the popular PC-based virus scanners typically added
detection of about 500-600 new viruses or variants--this averages out to
between two and three new viruses per day!
Some antivirus software looks for changes to programs or specific types
of viral "activity", and these programs generally claim to be good for
"all current and future viral programs". However, even these programs
cannot guarantee to protect against all future viruses, as new "attack"
and anti-antivirus methods are continually being developed by virus
writers. Thus, even this type of antivirus software needs to be
upgraded occasionally.
Of course, not every antivirus product is effective against all viruses,
even if upgraded regularly. Thus, do *not* depend on the fact that you
have upgraded your product recently as a guarantee that your system is
free of viruses!
F6) What are "virus simulators" and what use are they?
There are three different kinds of programs that are often called "virus
simulators". None of the three generate actual viruses. The first kind
demonstrate the audio- and video-effects of some real computer viruses.
The second kind are programs that simulate a virtual environment--a
virtual computer, with virtual disks, virtual files, and virtual viruses
on them. The user of such programs can manipulate the simulated
objects, letting the simulated viruses infect the simulated files on the
simulated disks, watching every step of the process, without a danger of
"real infection". The third kind are programs that generate files
containing scan strings used by some scanners to detect real viruses.
The idea is that those scanners will detect the generated files too,
thus letting the user get the feeling of what discovering a virus is
like, but without the danger of risking a real infection.
There are three ways in which virus simulators are usually used:
1) For educational purposes. The second kind of virus simulators are
very useful and valuable for this purpose, provided the simulated
environment is realistic enough. The first kind are also somewhat
useful--mainly teaching the users what the video- or audio-effects of
particular viruses are like. There is the danger, however, that users
will get the incorrect impression that *every* computer virus
demonstrates itself in some visible or audible way. The third kind of
virus simulators are not useful for this purpose--they do not show how
computer viruses work, do not show what computer viruses do, and because
their virus fragments are not reliably detected as viruses by many good
scanners, may give the wrong impression of a scanner's value.
2) As an installation check that antivirus defenses are installed and
working. The first and second kinds of virus simulators are unsuitable
for this, because they do not trigger any antivirus defenses. Even the
third kind of virus simulators have a rather limited value in this
regard, as the files generated by them often fail to trigger virus
defenses, which are designed to protect against *real* viruses. Unlike
the producers of such simulators, many believe it is the job of the
producer of an antivirus product to provide the means of checking
whether their product is installed and working. This position is based
on the authors knowing their products better than anyone else and that
updated check methods will normally be provided as the antivirus
defenses employed in any given product change.
3) As a test of the quality of the antivirus defense--usually a scanner.
Again, the first two kinds of simulators are unsuitable for this purpose
because they do not trigger antivirus defenses. The third kind of virus
simulators often do, from which many users get the impression that they
are suitable for these testing purposes. This is a serious
misconception. The files that such programs generate are not real
viruses; antivirus programs, particularly virus-specific ones like
scanners, are designed to detect real viruses. Therefore, one must not
draw a conclusion from the ability or the inability of a product to
detect "simulated viruses" of the third kind--the fact that they are
detected does not necessarily mean that a real virus will be detected,
and the fact that they are not detected does not mean that the real
virus it is supposed to represent will not be detected!
One exception to the above are simulators that do not generate files
containing scan strings, but which simulate the different kinds of
attacks that real viruses use, but without being able to replicate.
Examples of such attacks include different methods of tunnelling,
stealth, attacks against integrity checkers, and so on. Such simulators
are useful for testing antivirus products that are not virus-specific,
especially if the simulator exercises a wide range of known attacks.
F7) I've heard talk of "good viruses". Is it possible to use a
computer virus for something useful?
A very hotly debated topic that has flared-up dramatically several times
in Virus-L/comp.virus. The answer to this is not simple and largely
hinges on your definition or interpretation of the term computer virus.
By definition (see B1), viruses do not have to do something "bad"
(although many people argue that the uninvited "resource wasting" that
is almost inherent in viral activity is necessarily bad). From this
point (and based on his somewhat esoteric definition of the term
computer virus) Fred Cohen has argued that "good" or "useful" computer
viruses are a serious possibility. In fact, Dr. Cohen offered a reward
of $1000 for the first clearly "useful" virus--despite several potential
claimants, however, he hasn't paid up.
Although there has never been a position that was widely agreed upon as
a result of any of these discussions, many contributors to this forum
believe that there are serious problems with the idea of implementing
useful computing functionality through self-replicating programs.
Vesselin Bontchev's paper originally delivered at the 1994 EICAR
conference, titled "Are `Good' Computer Viruses Still a Bad Idea?", is
available by anonymous FTP from ftp.informatik.uni-hamburg.de (IP =
134.100.4.42), as pub/virus/texts/viruses/goodvir.zip. *Anyone* wishing
to raise this discussion in Virus-L/comp.virus again should read and
carefully consider this paper before posting. It contains many strong
arguments against the idea of "good computer viruses", and some
prescriptions of how good viruses would have to be implemented and
distributed to deserve the label "good". To date no strong arguments
countering the points in this paper or otherwise arguing in favor of the
concept of good viruses have been posted to the group.
F8) Wouldn't adding self-checking code to your programs be a good idea?
Every few months somebody suggests the idea of adding a small piece of
code to existing programs. This code would check for virus infections
when the program is executed by comparing a previously computed CRC or
cryptographic checksum (hash value) of the file in its known clean state
with its current value. The idea is that this will detect any virus
infection immediately, and is thus effective against unknown viruses.
A simple and intuitively attractive idea--in fact, some antivirus
programs have included options to do just this. There are, however,
some serious flaws with this approach.
This method cannot prevent the program from getting infected in the
first place. Further, if a program that has been protected this way
becomes infected later, whenever it is run the virus code will be
activated first. The virus may then be able to detect or even remove
the self-checking code, or it might make it totally ineffective by using
stealth techniques, so the self-checking code only "sees" the original,
non-infected program.
Some programs contain an internal self-check--much antivirus software,
for example. Such internal code might also be unable to detect stealth
viruses, but unless the external self-check code uses stealth techniques
too, the result will be a conflict, where the internal check will notice
the newly added code and decide that it has been "infected".
Moreover, this method is ineffective against "companion" viruses that
don't modify the applications they infect.
It may not be possible to protect all programs this way. For example,
under DOS it is relatively easy to add code of this type to most COM
files (unless the original program was slightly less than 64K, and the
resulting file would break that limit). However, EXE files are more of
a problem--especially those containing internal overlays, where one
cannot append the code to the file, as the resulting file might become
too big to load. Windows applications are also a problem, as they have
two different entry points, and special care has to be taken to handle
that correctly.
On the other hand, adding internal self-checking to programs as part of
their development is a good idea. Although it has the same limitations
regarding stealth viruses, it does not cause the conflicts described
above, and can be put in any program at compile-time. It is also much
more difficult for viruses to bypass.
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 =
129.170.16.4) 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.
Protection plans with computer virus
=================================
D1) What is the best antivirus program?
None! Different products are more or less appropriate in different
situations, but in general you should build a cost-effective *strategy*
based on multiple layers of defense. There are three main kinds of
antivirus software, plus several other means of protection, such as
hardware write-protect methods (see D4). When planning your antivirus
strategy you should also look closely at your backup policies and
procedures (see 10).
1. ACTIVITY MONITORING programs. These try to prevent infection
before it happens by looking for virus-like activity, such as
attempts to write to another executable, reformat the disk,
etc. An alternative term is BEHAVIOR BLOCKER.
Examples: SECURE and FluShot+ (PC), and GateKeeper
(Macintosh).
These programs are considered the weakest line of defense
against viruses on a system that does not have memory
protection, because in such an environment it is possible for
a tunnelling virus (see B12) to bypass or disable them.
2. SCANNERS. Most look for known viruses by searching your
disks and files for "scan strings" or patterns, but a few use
heuristic techniques to recognize viral code. Most now also
include some form of "algorithmic scanning" in order to
detect known polymorphic viruses. A scanner may be designed
to examine specified disks or files on demand, or it may be
resident, examining each program which is about to be
executed. Most scanners also include virus removers.
Examples: FindViru in Dr Solomon's AntiVirus ToolKit, Frisk
Software's F-PROT, McAfee's VirusScan (all PC), Disinfectant
(Macintosh).
Resident scanners: McAfee's V-Shield, and F-PROT's VIRSTOP.
Heuristic scanners: the Analyse option in F-PROT, TBAV's
TbScan and ChkBoot (from Padgett Peterson's FixUtils).
Scanners are the most convenient and the most widely used
kind of antivirus programs. They are a relatively weak line
of defense because even the simplest virus can bypass them if
it is new and unknown to the scanner. Therefore, your virus
protection system should not rely on a scanner alone.
3. INTEGRITY CHECKERS or MODIFICATION DETECTORS. These compute
a small "checksum" or "hash value" (usually CRC or
cryptographic) for files when they are presumably uninfected,
and later compare newly calculated values with the original
ones to see if the files have been modified. This catches
unknown viruses as well as known ones and thus provides
*generic* detection. On the other hand, modifications can
also be due to reasons other than viruses. Usually, it is up
to the user to decide which modifications are intentional and
which might be due to viruses, although a few products give
the user help in making this decision. As in the case of
scanners, integrity checkers may be called to checksum entire
disks or specified files on demand, or they may be resident,
checking each program which is about to be executed (the
latter is sometimes called an INTEGRITY SHELL). A third
implementation is as a SELF-TEST, where the checksumming code
is attached to each executable file so they check themselves
just before execution. It is generally considered a bad idea
to add such code to existing executables (see F8).
Examples: ASP Integrity Toolkit (commercial), and Integrity
Master and VDS (shareware), all for the PC.
Integrity checkers are considered to be the strongest line of
defense against computer viruses, because they are not virus-
specific and can detect new viruses without being constantly
updated. However, they should not be considered as an
absolute protection--they have several drawbacks, cannot
identify the particular virus that has attacked the system,
and there are successful methods of attack against them too.
3a. Some modification detectors provide HEURISTIC DISINFECTION.
Sufficient information is saved for each file so that it can
be restored to its original state in the case of the great
majority of viral infections, even if the virus is unknown.
Examples: V-Analyst 3 (BRM Technologies, Israel), the VGUARD
module of V-Care and ThunderByte's TbClean.
Note that behavior blockers and scanners are virus *prevention* tools,
while integrity checkers are virus *detection* tools.
Of course, only a few examples of each type have been given. All of
these types of antivirus program have a place in protecting against
computer viruses, but you should appreciate the limitations of each
method, along with system-supplied security measures that may or may not
be helpful in defeating viruses. Ideally, you should arrange a
combination of methods that cover each others' weaknesses.
A typical PC installation might include a protection system on the hard
disk's MBR to protect against viruses at load time (ideally this would
be hardware or in BIOS, but software methods such as DiskSecure and
Henrik Stroem's HS are pretty good). This would be followed by resident
virus detectors loaded as part of the machine's startup (CONFIG.SYS or
AUTOEXEC.BAT), such as FluShot+ and/or VirStop and/or ChkBoot. A
scanner such as F-PROT or McAfee's VirusScan and an integrity checker,
such as Integrity Master, could be put into AUTOEXEC.BAT, but this may
be a problem if you have a large disk to check, or don't reboot often
enough. Most importantly, new files and diskettes should be scanned as
they arrive *regardless* of their source. If your system has DR DOS
installed, you should use the PASSWORD command to write-protect all
system executables and utilities. If you have Stacker or SuperStor, you
can get some improved security from these compressed drives, but also a
risk that those viruses stupid enough to directly write to the disk
could do much more damage than normal. In this case a software write-
protect system (such as provided with Disk Manager or The Norton
Utilities) may help. Possibly the best solution is to put all
executables on a disk of their own, with a hardware write-protect system
that sounds an alarm if a write is attempted.
If you do use a resident BSI detector or a scan-while-you-copy detector,
it is important to trace back any infected diskette to its source. The
reason viruses survive so well is that usually you cannot do this,
because the infection is found long after the infecting diskette has
been forgotten due to most people's lax scanning policies.
Organizations should devise and implement a careful policy that may
include a system of vetting new software brought into the building and
free virus detectors for home machines of employees/students/etc who
take work home with them.
Other antivirus techniques include:
1. Creation of a special MBR to make the hard disk inaccessible
when booting from a diskette (the latter is useful since
booting from a diskette will normally bypass any protection
measures loaded in the CONFIG.SYS and/or AUTOEXEC.BAT files
on the hard disk).
Some of these systems won't prevent attack by some MBR virus
infections if booting from an infected floppy. This approach
is less important now, as most newer PCs allow you to change
the boot order so the first hard drive is tried *before* any
of the floppy drives.
2. Use of Artificial Intelligence to learn about new viruses and
extract scan patterns for them.
Examples: V-Care (CSA Interprint, Israel; distributed in the
US by Sela Consultants Corp.), Victor Charlie (Bangkok
Security Associates, Thailand; distributed in the US by
Computer Security Associates).
3. Encryption of files (with decryption before execution).
4. Diskette "fences". There are three different approaches to
this. One prevents executables from being accessed from
floppy drives while another prohibits the use of unscanned
(possibly "unclean") files or diskettes. A third method uses
a non-standard diskette format so diskettes can only be used
on (and therefore shared among) machines using the
appropriate antivirus software (usually all those within a
site or company). This last method is probably the most
common diskette fence and provides better protection against
boot sector viruses than the other "fence" types.
The workings of the first and third are probably fairly clear
from these brief descriptions. The second approach works by
writing special information to normally unused areas of the
diskette as part of the scanning process and employing a
driver in the users' machines prevents access to files that
aren't marked as scanned (or to any part of a diskette that
contains unscanned files). Alternatives include encrypting
scanned files and drivers that only allow access to encrypted
files, and so on. One advantage of this second type of
system is that you only need scanners for "perimeter
checking" machines, reducing the overhead and cost of keeping
your scanners up to date.
Examples: D-Fence, Virus Fence, TbFence, DiskNet.
D2) Is it possible to protect a computer system with only software?
Not perfectly; although software defenses can significantly reduce your
risk of being affected by viruses *when applied appropriately*. All
virus defense systems are tools--each with its own capabilities and
shortcomings. Learn how your system works and be sure to work within
its limitations.
Using a layered approach, a very high level of protection/detection can
be achieved with software only.
1. ROM BIOS--password (access control) and selecting to boot
from the hard drive rather than from diskette. (Some may
consider this hardware.)
2. Boot sectors--integrity management and change detection.
3. OS programs--integrity management of existing programs,
scanning of unknown programs. Requirement of authentication
values for any new or transmitted software.
4. Locks that prevent writing to a fixed or floppy disk.
As each layer is added, undetected invasion becomes more difficult.
Nevertheless, complete protection against any possible attack cannot be
provided without dedicating the computer to pre-existing or unique
tasks. International standardization on the IBM PC architecture is both
its greatest asset and its greatest vulnerability.
D3) Is it possible to write-protect the hard disk with software only?
The answer is no. There are several programs that claim to do this, but
*all* of them can be bypassed with techniques already used by some
viruses. Therefore you should never rely on such programs *alone*,
although they can be useful in combination with other antivirus
measures.
D4) What can be done with hardware protection?
Hardware protection can accomplish various things, including: write
protection for hard disk drives, memory protection, monitoring and
trapping unauthorized system calls, etc. Again, no single tool will be
foolproof and the "stronger" hardware-based protection is, the more
likely it will interfere with the "normal" operation of your computer.
The popular idea of write-protection (see D3) may stop viruses
*spreading* to the disk that is protected, but doesn't, in itself,
prevent a virus from *running*.
Also, some existing hardware protection schemes can be easily bypassed,
fooled, or disconnected, if the virus writer knows them well and designs
a virus that is aware of the particular defense.
The big problem with hardware protection is that there are few (if any)
operations that a general-purpose computer can perform that are used by
viruses *only*. Therefore, making a hardware protection system for such
a computer typically involves deciding on some (small) set of operations
that are "valid but not normally performed except by viruses", and
designing the system to prevent these operations. Unfortunately, this
means either designing limitations into the level of protection the
hardware system provides or adding limitations to the computer's
functionality by installing the hardware protection system. Much can be
achieved, however, by making the hardware "smarter". This is double-
edged: while it provides more security, it usually means adding a
program in an EPROM to control it. This allows a virus to locate the
program and to call it directly after the point that allows access. It
is still possible to implement this correctly though--if this program is
not in the address space of the main CPU, has its own CPU and is
connected directly to the hard disk and the keyboard. As an example,
there is a PC-based product called ExVira which does this and seems
fairly secure, but it is a whole computer on an add-on board and is
quite expensive.
D5) Does setting a file's attributes to READ ONLY protect it from
viruses?
Generally, no. While the Read Only attribute will protect your files
from a few viruses, most simply override it, and infect normally. So,
while setting executable files to Read Only a good idea (it protects
against accidental deletion), it is certainly not a thorough protection
against viruses!
In some environments the Read Only attribute does provide some
additional protection. For instance, under Novell Netware a user can be
denied the right to modify file attributes in directories on the server.
This means that a virus that infects such a user's machine will be
unable to infect files in those server directories if the files have
their Read Only attribute set.
D6) Do password/access control systems protect my files from viruses?
All password and other access control systems are designed to protect
the user's data from other users and/or their programs. Remember,
however, that when you execute an infected program the virus in it will
gain your current rights/privileges. Therefore, if the access control
system provides *you* the right to modify some files, it will provide it
to the virus too. Note that this does not depend on the operating
system used--DOS, Unix, or whatever. Therefore, an access control
system will protect your files from viruses no better than it protects
them from you.
Under DOS, there is no memory protection, so a virus could disable the
access control system in memory, or even patch the operating system
itself. On more advanced operating systems (Unix, OS/2, Windows NT)
this is much harder or impossible, so there is much less risk that such
protection measures could be disabled by a virus. Even so, viruses will
still be able to spread, for the reasons noted above. In general,
access control systems (if implemented correctly) are only able to slow
down virus spread, not to eliminate viruses entirely.
Of course, it's better to have access control than not to have it at
all. Just be sure to not develop a false sense of security or come to
rely *entirely* on your access control system to protect you.
D7) Do the protection systems in DR DOS work against viruses?
Partially. Neither the password file/directory protection available
from DR DOS version 5 onwards, nor the secure disk partitions from DR
DOS 6 were intended to combat viruses, but they do so to some extent.
If you have DR DOS, it is very wise to password-protect your files (to
stop accidental damage too), but don't depend on it as your only means
of defense.
The use of the password command (e.g. PASSWORD/W:MINE *.EXE *.COM) will
stop more viruses than the plain DOS attribute facility (see D5), but
that isn't saying much! The combination of the password system plus a
disk compression system may be more secure, because to bypass the
password system a virus must access the disk directly, but under
SuperStor or Stacker the physical disk will be meaningless to a virus.
There may be some viruses that, rather than invisibly infecting files on
compressed disks, very visibly corrupt such disks.
The main use of the "secure disk partitions" system, introduced in
DR DOS 6, is to stop people from fiddling with your hard disk while you
are away from the PC. The way this is implemented, however, may also
help against a few viruses that look for DOS partitions on a disk.
Furthermore, DR DOS is not fully compatible with MS/PC-DOS, especially
when you get down to the low-level tricks that some viruses use. For
instance, some internal memory structures are "read-only" in the sense
that they are constantly updated (for MS/PC-DOS compatibility) but not
really used by DR DOS, so even if a sophisticated virus modifies them,
it will not have any effect, or at least not that intended by the
virus's author.
In general, using a less compatible system diminishes the number of
existing viruses that can infect it. For instance, the introduction of
hard disks made the Brain virus almost disappear; the introduction of
the 80286 and DOS 4.0+ made the Yale and Ping Pong viruses next to
extinct, and so on.
D8) Does a write-protect tab on a floppy disk stop viruses?
In general, yes. The write-protection on IBM PC (and compatible) and
Macintosh floppy disk drives is implemented in hardware, not software,
so viruses cannot infect a diskette when the write-protection mechanism
is functioning properly (though many "friend of a friend" stories abound
contesting this).
But remember:
1. A computer may have a faulty write-protect system (this
happens!)--you can test it by trying to copy a file to a
diskette that is apparently write-protected.
2. Someone may have removed the tab for a while, allowing a
virus on.
3. The files may have been infected before the disk was
protected. Even some diskettes "straight from the factory"
have been known to be infected during the production process.
Thus, you should scan even new, write-protected disks for viruses. You
should also scan new, pre-formatted diskettes, as there have been cases
of infected, shrink-wrapped new diskettes.
D9) Do local area networks (LANs) help to stop viruses or do they
facilitate their spread?
Both. A set of computers connected in a well managed LAN, with
carefully established security settings, with minimal privileges for
each user, and without a transitive path of information flow between the
users (i.e., the objects writable by any of the users are not readable
by any of the others) is more virus-resistant than the same set of
computers if they are not interconnected. The reason is that when all
computers have (read-only) access to a common pool of executable
programs, there is usually less need for diskette swapping and software
exchange between them, and therefore less chances for a virus to spread.
However, if the LAN has lax security and is not well managed, it could
help a virus to spread like wildfire. It might even be impossible to
remove the infection without shutting down the entire LAN. Stories of
LAN login programs, shared copies of which are run on every workstation,
becoming infected are, unfortunately, not uncommon.
A network that supports login scripting is inherently more resistant to
viruses than one that does not *if* this is used to validate the client
before allowing access to the network.
D10) What is the proper way to make backups?
A good backup regime is at the heart of any comprehensive virus defense
scheme. No matter what combination of software and hardware defenses
you install, nor what "policy" you implement, there is always the
possibility that some new virus will be devised that can beat your
defenses *or* that someone will fail to follow "proper protocol" with
"foreign" media or file sources. In corporate settings, the possibility
of the latter as a form of directed attack by disgruntled employees
cannot be overlooked.
Planning to minimize the impact of a virus infection on your computing
is much like planning to minimize the effect of an earthquake or fire.
You cannot be sure where, when or even *if* you will ever be "hit"; the
potential impact could fall anywhere in a very wide range of possible
damage; being "completely safe" can involve enormous expense; and you
cannot adequately test your preparations without exposing yourself to
serious risk of damage. Therefore, finalizing on the defense scheme
that suits you involves deciding on the level of loss you can afford to
stand and probably settling on a system that, while not "perfectly
watertight," is "good enough".
Despite the importance of a good backup scheme, it is really beyond the
scope of this FAQ sheet to provide a definitive guide to planning your
backup procedure--that could easily take another document the size of
this! All this said however, we provide the following advice as, we
hope, a good starting point.
Planning an effective backup scheme really starts with answering some
important questions. Consider:
1. Who is dependent on the files on this system? Is it a home
computer mostly used by the kids for games, a standalone
workstation running a small business, a networked workstation
in a medium-sized company or the same in a large corporate
environment, or a server with many (hundreds) of users?
2. How long can the most important user be without access to
these files? One hour, 2, 4, 8, a day, a week? Remember to
assume that your problems will arise at the worst possible
moment (like 24 hours before a tax audit is due to start!).
3. What proportion (and volume!) of files are "fixed" (in the
sense that they seldom change) versus those that change? Do
all changes have to be backed-up, or is a "once-some-given-
time-period" backup acceptable?
4. What type of information is in the regularly changing files?
The answers to these (and other) questions help shape backup and
recovery plans and are fairly well understood issues amongst computer
systems professionals. Highly critical systems containing crucial data
will be designed from the outset to have high redundancy (disk
mirroring, disk arrays, UPSes, maybe even redundant servers), though
such system options *alone* provide no real protection from virus
attacks. You may opt for a backup system that records every change to
any files on your system (server-only or clients and servers) or regular
(often nightly) backup of changed data files, and so on.
When it comes to planning backup regimes with an eye to the possibility
of recovering from a virus attack, you also have to consider that
regularly backing-up executables (loosely, "programs") can cause
problems. If you do and are infected by a virus, unless you can be
*absolutely sure* of the date of first infection (despite sounding
simple, this is not something that can commonly be done!), you may have
quite a few problems finding the best backup set to restore from, as you
will probably have several sets including infected executables.
For home or small business use, it may be best to maintain two kinds of
backups. One would contain only your data files and one your operating
system and program files (issues to consider are covered in the next two
paragraphs). This may be facilitated by maintaining a strict separation
of the two kinds of files, perhaps by putting the operating system and
programs on one drive or partition and your data files on another.
While this is probably not practical for many existing machines,
enforcing adherence to the "rule" that data files should only be placed
in appropriate sub-directories (folders) within a prescribed data
directory may not be a bad thing.
The best way to manage backup of data files depends on the answers to
too many of the questions listed above for us to give definitive advice
here. While planning your backup regime, bear in mind that some viruses
damage some kinds of data files, while others make small, occasional,
random modifications as files are written to disk. While viruses with
either of these "features" are quite rare, both of these possibilities
mean that vital data files should probably be backed-up to long-cycle
media sets as well as to shorter cycle sets and other steps taken to
ensure you can recreate the sequence of changes. (For example, retain
all transaction records so they can be re-entered.)
You should probably backup executables once after installing them and
only *after* you are sure they are virus-free according to your current
antivirus screening procedures. *Never* make a backup containing
executables over media that hold *any* of your current backups. The
more cautious of us maintain several cycles of executable backups.
These precautions should ensure you don't face the problem outlined
several paragraphs ago, and mean that should a newly installed program
be infected with a virus your current defenses don't detect, you can
easily restore your system and installed software to how it was before
the infected software was installed, when you do become aware of its
presence. You will probably have to manually reinstall any programs you
installed subsequent to installing the infected program.
Having referred to this second kind of backup as "executables only", we
should point out that a complete system backup is also acceptable for
this type of backup. However, note that a sequence of full system
backups with interim "incremental" backups (when only those files that
have changed since the last complete backup are saved) is *not* what we
are advocating. Such systems tend to be too "broad brush" to be truly
useful for recovering from an unknown, future virus attack.
Unfortunately, this tends to be the preferred/recommended backup scheme
for small-to-medium sized systems (including most personal computers),
and is typically what most popular backup software for such systems is
designed to do. This doesn't mean that popular backup systems and
software aren't useful, just that you have to exercise some care in
using them (like excluding executable files from your incremental
backups).
Having said all this, there are still a few other problems to consider,
especially: Which files should you count as "data" files? This can be
problematic as most people immediately think of their word-processor and
spreadsheet files, and the like, as data, and that's about it. What
about the files in which your programs store their configuration
information? In a sense, these are as much "your data" as they are
program files, because they reflect your preferred screen colors and
layouts, default fonts, personalized button bars and so on. When you
look at the time people spend finding the (often obscure) options
settings in their programs and making them work "just right", and how
upset they can be if they lose these settings, it makes sense to treat
such configuration files as you treat other "personal data files" in
your backup regimes. Similarly, people tend to treat system
configuration files (in DOS/Windows PCs CONFIG.SYS, AUTOEXEC.BAT,
WIN.INI, SYSTEM.INI at a minimum!) as part of the system, often ignoring
the (sometimes considerable) fine-tuning these configuration files go
through *between* system and executable backups.
One last point--it cannot be stressed enough that you *MUST* have a
full, working copy of the software you need to restore your backups in a
safe place. You must be able to guarantee that this software is not
virus infected should you ever have to use it, *AND* that it is fully
usable should you be facing a machine that has had its entire hard drive
"wiped clean".
D1) What is the best antivirus program?
None! Different products are more or less appropriate in different
situations, but in general you should build a cost-effective *strategy*
based on multiple layers of defense. There are three main kinds of
antivirus software, plus several other means of protection, such as
hardware write-protect methods (see D4). When planning your antivirus
strategy you should also look closely at your backup policies and
procedures (see 10).
1. ACTIVITY MONITORING programs. These try to prevent infection
before it happens by looking for virus-like activity, such as
attempts to write to another executable, reformat the disk,
etc. An alternative term is BEHAVIOR BLOCKER.
Examples: SECURE and FluShot+ (PC), and GateKeeper
(Macintosh).
These programs are considered the weakest line of defense
against viruses on a system that does not have memory
protection, because in such an environment it is possible for
a tunnelling virus (see B12) to bypass or disable them.
2. SCANNERS. Most look for known viruses by searching your
disks and files for "scan strings" or patterns, but a few use
heuristic techniques to recognize viral code. Most now also
include some form of "algorithmic scanning" in order to
detect known polymorphic viruses. A scanner may be designed
to examine specified disks or files on demand, or it may be
resident, examining each program which is about to be
executed. Most scanners also include virus removers.
Examples: FindViru in Dr Solomon's AntiVirus ToolKit, Frisk
Software's F-PROT, McAfee's VirusScan (all PC), Disinfectant
(Macintosh).
Resident scanners: McAfee's V-Shield, and F-PROT's VIRSTOP.
Heuristic scanners: the Analyse option in F-PROT, TBAV's
TbScan and ChkBoot (from Padgett Peterson's FixUtils).
Scanners are the most convenient and the most widely used
kind of antivirus programs. They are a relatively weak line
of defense because even the simplest virus can bypass them if
it is new and unknown to the scanner. Therefore, your virus
protection system should not rely on a scanner alone.
3. INTEGRITY CHECKERS or MODIFICATION DETECTORS. These compute
a small "checksum" or "hash value" (usually CRC or
cryptographic) for files when they are presumably uninfected,
and later compare newly calculated values with the original
ones to see if the files have been modified. This catches
unknown viruses as well as known ones and thus provides
*generic* detection. On the other hand, modifications can
also be due to reasons other than viruses. Usually, it is up
to the user to decide which modifications are intentional and
which might be due to viruses, although a few products give
the user help in making this decision. As in the case of
scanners, integrity checkers may be called to checksum entire
disks or specified files on demand, or they may be resident,
checking each program which is about to be executed (the
latter is sometimes called an INTEGRITY SHELL). A third
implementation is as a SELF-TEST, where the checksumming code
is attached to each executable file so they check themselves
just before execution. It is generally considered a bad idea
to add such code to existing executables (see F8).
Examples: ASP Integrity Toolkit (commercial), and Integrity
Master and VDS (shareware), all for the PC.
Integrity checkers are considered to be the strongest line of
defense against computer viruses, because they are not virus-
specific and can detect new viruses without being constantly
updated. However, they should not be considered as an
absolute protection--they have several drawbacks, cannot
identify the particular virus that has attacked the system,
and there are successful methods of attack against them too.
3a. Some modification detectors provide HEURISTIC DISINFECTION.
Sufficient information is saved for each file so that it can
be restored to its original state in the case of the great
majority of viral infections, even if the virus is unknown.
Examples: V-Analyst 3 (BRM Technologies, Israel), the VGUARD
module of V-Care and ThunderByte's TbClean.
Note that behavior blockers and scanners are virus *prevention* tools,
while integrity checkers are virus *detection* tools.
Of course, only a few examples of each type have been given. All of
these types of antivirus program have a place in protecting against
computer viruses, but you should appreciate the limitations of each
method, along with system-supplied security measures that may or may not
be helpful in defeating viruses. Ideally, you should arrange a
combination of methods that cover each others' weaknesses.
A typical PC installation might include a protection system on the hard
disk's MBR to protect against viruses at load time (ideally this would
be hardware or in BIOS, but software methods such as DiskSecure and
Henrik Stroem's HS are pretty good). This would be followed by resident
virus detectors loaded as part of the machine's startup (CONFIG.SYS or
AUTOEXEC.BAT), such as FluShot+ and/or VirStop and/or ChkBoot. A
scanner such as F-PROT or McAfee's VirusScan and an integrity checker,
such as Integrity Master, could be put into AUTOEXEC.BAT, but this may
be a problem if you have a large disk to check, or don't reboot often
enough. Most importantly, new files and diskettes should be scanned as
they arrive *regardless* of their source. If your system has DR DOS
installed, you should use the PASSWORD command to write-protect all
system executables and utilities. If you have Stacker or SuperStor, you
can get some improved security from these compressed drives, but also a
risk that those viruses stupid enough to directly write to the disk
could do much more damage than normal. In this case a software write-
protect system (such as provided with Disk Manager or The Norton
Utilities) may help. Possibly the best solution is to put all
executables on a disk of their own, with a hardware write-protect system
that sounds an alarm if a write is attempted.
If you do use a resident BSI detector or a scan-while-you-copy detector,
it is important to trace back any infected diskette to its source. The
reason viruses survive so well is that usually you cannot do this,
because the infection is found long after the infecting diskette has
been forgotten due to most people's lax scanning policies.
Organizations should devise and implement a careful policy that may
include a system of vetting new software brought into the building and
free virus detectors for home machines of employees/students/etc who
take work home with them.
Other antivirus techniques include:
1. Creation of a special MBR to make the hard disk inaccessible
when booting from a diskette (the latter is useful since
booting from a diskette will normally bypass any protection
measures loaded in the CONFIG.SYS and/or AUTOEXEC.BAT files
on the hard disk).
Some of these systems won't prevent attack by some MBR virus
infections if booting from an infected floppy. This approach
is less important now, as most newer PCs allow you to change
the boot order so the first hard drive is tried *before* any
of the floppy drives.
2. Use of Artificial Intelligence to learn about new viruses and
extract scan patterns for them.
Examples: V-Care (CSA Interprint, Israel; distributed in the
US by Sela Consultants Corp.), Victor Charlie (Bangkok
Security Associates, Thailand; distributed in the US by
Computer Security Associates).
3. Encryption of files (with decryption before execution).
4. Diskette "fences". There are three different approaches to
this. One prevents executables from being accessed from
floppy drives while another prohibits the use of unscanned
(possibly "unclean") files or diskettes. A third method uses
a non-standard diskette format so diskettes can only be used
on (and therefore shared among) machines using the
appropriate antivirus software (usually all those within a
site or company). This last method is probably the most
common diskette fence and provides better protection against
boot sector viruses than the other "fence" types.
The workings of the first and third are probably fairly clear
from these brief descriptions. The second approach works by
writing special information to normally unused areas of the
diskette as part of the scanning process and employing a
driver in the users' machines prevents access to files that
aren't marked as scanned (or to any part of a diskette that
contains unscanned files). Alternatives include encrypting
scanned files and drivers that only allow access to encrypted
files, and so on. One advantage of this second type of
system is that you only need scanners for "perimeter
checking" machines, reducing the overhead and cost of keeping
your scanners up to date.
Examples: D-Fence, Virus Fence, TbFence, DiskNet.
D2) Is it possible to protect a computer system with only software?
Not perfectly; although software defenses can significantly reduce your
risk of being affected by viruses *when applied appropriately*. All
virus defense systems are tools--each with its own capabilities and
shortcomings. Learn how your system works and be sure to work within
its limitations.
Using a layered approach, a very high level of protection/detection can
be achieved with software only.
1. ROM BIOS--password (access control) and selecting to boot
from the hard drive rather than from diskette. (Some may
consider this hardware.)
2. Boot sectors--integrity management and change detection.
3. OS programs--integrity management of existing programs,
scanning of unknown programs. Requirement of authentication
values for any new or transmitted software.
4. Locks that prevent writing to a fixed or floppy disk.
As each layer is added, undetected invasion becomes more difficult.
Nevertheless, complete protection against any possible attack cannot be
provided without dedicating the computer to pre-existing or unique
tasks. International standardization on the IBM PC architecture is both
its greatest asset and its greatest vulnerability.
D3) Is it possible to write-protect the hard disk with software only?
The answer is no. There are several programs that claim to do this, but
*all* of them can be bypassed with techniques already used by some
viruses. Therefore you should never rely on such programs *alone*,
although they can be useful in combination with other antivirus
measures.
D4) What can be done with hardware protection?
Hardware protection can accomplish various things, including: write
protection for hard disk drives, memory protection, monitoring and
trapping unauthorized system calls, etc. Again, no single tool will be
foolproof and the "stronger" hardware-based protection is, the more
likely it will interfere with the "normal" operation of your computer.
The popular idea of write-protection (see D3) may stop viruses
*spreading* to the disk that is protected, but doesn't, in itself,
prevent a virus from *running*.
Also, some existing hardware protection schemes can be easily bypassed,
fooled, or disconnected, if the virus writer knows them well and designs
a virus that is aware of the particular defense.
The big problem with hardware protection is that there are few (if any)
operations that a general-purpose computer can perform that are used by
viruses *only*. Therefore, making a hardware protection system for such
a computer typically involves deciding on some (small) set of operations
that are "valid but not normally performed except by viruses", and
designing the system to prevent these operations. Unfortunately, this
means either designing limitations into the level of protection the
hardware system provides or adding limitations to the computer's
functionality by installing the hardware protection system. Much can be
achieved, however, by making the hardware "smarter". This is double-
edged: while it provides more security, it usually means adding a
program in an EPROM to control it. This allows a virus to locate the
program and to call it directly after the point that allows access. It
is still possible to implement this correctly though--if this program is
not in the address space of the main CPU, has its own CPU and is
connected directly to the hard disk and the keyboard. As an example,
there is a PC-based product called ExVira which does this and seems
fairly secure, but it is a whole computer on an add-on board and is
quite expensive.
D5) Does setting a file's attributes to READ ONLY protect it from
viruses?
Generally, no. While the Read Only attribute will protect your files
from a few viruses, most simply override it, and infect normally. So,
while setting executable files to Read Only a good idea (it protects
against accidental deletion), it is certainly not a thorough protection
against viruses!
In some environments the Read Only attribute does provide some
additional protection. For instance, under Novell Netware a user can be
denied the right to modify file attributes in directories on the server.
This means that a virus that infects such a user's machine will be
unable to infect files in those server directories if the files have
their Read Only attribute set.
D6) Do password/access control systems protect my files from viruses?
All password and other access control systems are designed to protect
the user's data from other users and/or their programs. Remember,
however, that when you execute an infected program the virus in it will
gain your current rights/privileges. Therefore, if the access control
system provides *you* the right to modify some files, it will provide it
to the virus too. Note that this does not depend on the operating
system used--DOS, Unix, or whatever. Therefore, an access control
system will protect your files from viruses no better than it protects
them from you.
Under DOS, there is no memory protection, so a virus could disable the
access control system in memory, or even patch the operating system
itself. On more advanced operating systems (Unix, OS/2, Windows NT)
this is much harder or impossible, so there is much less risk that such
protection measures could be disabled by a virus. Even so, viruses will
still be able to spread, for the reasons noted above. In general,
access control systems (if implemented correctly) are only able to slow
down virus spread, not to eliminate viruses entirely.
Of course, it's better to have access control than not to have it at
all. Just be sure to not develop a false sense of security or come to
rely *entirely* on your access control system to protect you.
D7) Do the protection systems in DR DOS work against viruses?
Partially. Neither the password file/directory protection available
from DR DOS version 5 onwards, nor the secure disk partitions from DR
DOS 6 were intended to combat viruses, but they do so to some extent.
If you have DR DOS, it is very wise to password-protect your files (to
stop accidental damage too), but don't depend on it as your only means
of defense.
The use of the password command (e.g. PASSWORD/W:MINE *.EXE *.COM) will
stop more viruses than the plain DOS attribute facility (see D5), but
that isn't saying much! The combination of the password system plus a
disk compression system may be more secure, because to bypass the
password system a virus must access the disk directly, but under
SuperStor or Stacker the physical disk will be meaningless to a virus.
There may be some viruses that, rather than invisibly infecting files on
compressed disks, very visibly corrupt such disks.
The main use of the "secure disk partitions" system, introduced in
DR DOS 6, is to stop people from fiddling with your hard disk while you
are away from the PC. The way this is implemented, however, may also
help against a few viruses that look for DOS partitions on a disk.
Furthermore, DR DOS is not fully compatible with MS/PC-DOS, especially
when you get down to the low-level tricks that some viruses use. For
instance, some internal memory structures are "read-only" in the sense
that they are constantly updated (for MS/PC-DOS compatibility) but not
really used by DR DOS, so even if a sophisticated virus modifies them,
it will not have any effect, or at least not that intended by the
virus's author.
In general, using a less compatible system diminishes the number of
existing viruses that can infect it. For instance, the introduction of
hard disks made the Brain virus almost disappear; the introduction of
the 80286 and DOS 4.0+ made the Yale and Ping Pong viruses next to
extinct, and so on.
D8) Does a write-protect tab on a floppy disk stop viruses?
In general, yes. The write-protection on IBM PC (and compatible) and
Macintosh floppy disk drives is implemented in hardware, not software,
so viruses cannot infect a diskette when the write-protection mechanism
is functioning properly (though many "friend of a friend" stories abound
contesting this).
But remember:
1. A computer may have a faulty write-protect system (this
happens!)--you can test it by trying to copy a file to a
diskette that is apparently write-protected.
2. Someone may have removed the tab for a while, allowing a
virus on.
3. The files may have been infected before the disk was
protected. Even some diskettes "straight from the factory"
have been known to be infected during the production process.
Thus, you should scan even new, write-protected disks for viruses. You
should also scan new, pre-formatted diskettes, as there have been cases
of infected, shrink-wrapped new diskettes.
D9) Do local area networks (LANs) help to stop viruses or do they
facilitate their spread?
Both. A set of computers connected in a well managed LAN, with
carefully established security settings, with minimal privileges for
each user, and without a transitive path of information flow between the
users (i.e., the objects writable by any of the users are not readable
by any of the others) is more virus-resistant than the same set of
computers if they are not interconnected. The reason is that when all
computers have (read-only) access to a common pool of executable
programs, there is usually less need for diskette swapping and software
exchange between them, and therefore less chances for a virus to spread.
However, if the LAN has lax security and is not well managed, it could
help a virus to spread like wildfire. It might even be impossible to
remove the infection without shutting down the entire LAN. Stories of
LAN login programs, shared copies of which are run on every workstation,
becoming infected are, unfortunately, not uncommon.
A network that supports login scripting is inherently more resistant to
viruses than one that does not *if* this is used to validate the client
before allowing access to the network.
D10) What is the proper way to make backups?
A good backup regime is at the heart of any comprehensive virus defense
scheme. No matter what combination of software and hardware defenses
you install, nor what "policy" you implement, there is always the
possibility that some new virus will be devised that can beat your
defenses *or* that someone will fail to follow "proper protocol" with
"foreign" media or file sources. In corporate settings, the possibility
of the latter as a form of directed attack by disgruntled employees
cannot be overlooked.
Planning to minimize the impact of a virus infection on your computing
is much like planning to minimize the effect of an earthquake or fire.
You cannot be sure where, when or even *if* you will ever be "hit"; the
potential impact could fall anywhere in a very wide range of possible
damage; being "completely safe" can involve enormous expense; and you
cannot adequately test your preparations without exposing yourself to
serious risk of damage. Therefore, finalizing on the defense scheme
that suits you involves deciding on the level of loss you can afford to
stand and probably settling on a system that, while not "perfectly
watertight," is "good enough".
Despite the importance of a good backup scheme, it is really beyond the
scope of this FAQ sheet to provide a definitive guide to planning your
backup procedure--that could easily take another document the size of
this! All this said however, we provide the following advice as, we
hope, a good starting point.
Planning an effective backup scheme really starts with answering some
important questions. Consider:
1. Who is dependent on the files on this system? Is it a home
computer mostly used by the kids for games, a standalone
workstation running a small business, a networked workstation
in a medium-sized company or the same in a large corporate
environment, or a server with many (hundreds) of users?
2. How long can the most important user be without access to
these files? One hour, 2, 4, 8, a day, a week? Remember to
assume that your problems will arise at the worst possible
moment (like 24 hours before a tax audit is due to start!).
3. What proportion (and volume!) of files are "fixed" (in the
sense that they seldom change) versus those that change? Do
all changes have to be backed-up, or is a "once-some-given-
time-period" backup acceptable?
4. What type of information is in the regularly changing files?
The answers to these (and other) questions help shape backup and
recovery plans and are fairly well understood issues amongst computer
systems professionals. Highly critical systems containing crucial data
will be designed from the outset to have high redundancy (disk
mirroring, disk arrays, UPSes, maybe even redundant servers), though
such system options *alone* provide no real protection from virus
attacks. You may opt for a backup system that records every change to
any files on your system (server-only or clients and servers) or regular
(often nightly) backup of changed data files, and so on.
When it comes to planning backup regimes with an eye to the possibility
of recovering from a virus attack, you also have to consider that
regularly backing-up executables (loosely, "programs") can cause
problems. If you do and are infected by a virus, unless you can be
*absolutely sure* of the date of first infection (despite sounding
simple, this is not something that can commonly be done!), you may have
quite a few problems finding the best backup set to restore from, as you
will probably have several sets including infected executables.
For home or small business use, it may be best to maintain two kinds of
backups. One would contain only your data files and one your operating
system and program files (issues to consider are covered in the next two
paragraphs). This may be facilitated by maintaining a strict separation
of the two kinds of files, perhaps by putting the operating system and
programs on one drive or partition and your data files on another.
While this is probably not practical for many existing machines,
enforcing adherence to the "rule" that data files should only be placed
in appropriate sub-directories (folders) within a prescribed data
directory may not be a bad thing.
The best way to manage backup of data files depends on the answers to
too many of the questions listed above for us to give definitive advice
here. While planning your backup regime, bear in mind that some viruses
damage some kinds of data files, while others make small, occasional,
random modifications as files are written to disk. While viruses with
either of these "features" are quite rare, both of these possibilities
mean that vital data files should probably be backed-up to long-cycle
media sets as well as to shorter cycle sets and other steps taken to
ensure you can recreate the sequence of changes. (For example, retain
all transaction records so they can be re-entered.)
You should probably backup executables once after installing them and
only *after* you are sure they are virus-free according to your current
antivirus screening procedures. *Never* make a backup containing
executables over media that hold *any* of your current backups. The
more cautious of us maintain several cycles of executable backups.
These precautions should ensure you don't face the problem outlined
several paragraphs ago, and mean that should a newly installed program
be infected with a virus your current defenses don't detect, you can
easily restore your system and installed software to how it was before
the infected software was installed, when you do become aware of its
presence. You will probably have to manually reinstall any programs you
installed subsequent to installing the infected program.
Having referred to this second kind of backup as "executables only", we
should point out that a complete system backup is also acceptable for
this type of backup. However, note that a sequence of full system
backups with interim "incremental" backups (when only those files that
have changed since the last complete backup are saved) is *not* what we
are advocating. Such systems tend to be too "broad brush" to be truly
useful for recovering from an unknown, future virus attack.
Unfortunately, this tends to be the preferred/recommended backup scheme
for small-to-medium sized systems (including most personal computers),
and is typically what most popular backup software for such systems is
designed to do. This doesn't mean that popular backup systems and
software aren't useful, just that you have to exercise some care in
using them (like excluding executable files from your incremental
backups).
Having said all this, there are still a few other problems to consider,
especially: Which files should you count as "data" files? This can be
problematic as most people immediately think of their word-processor and
spreadsheet files, and the like, as data, and that's about it. What
about the files in which your programs store their configuration
information? In a sense, these are as much "your data" as they are
program files, because they reflect your preferred screen colors and
layouts, default fonts, personalized button bars and so on. When you
look at the time people spend finding the (often obscure) options
settings in their programs and making them work "just right", and how
upset they can be if they lose these settings, it makes sense to treat
such configuration files as you treat other "personal data files" in
your backup regimes. Similarly, people tend to treat system
configuration files (in DOS/Windows PCs CONFIG.SYS, AUTOEXEC.BAT,
WIN.INI, SYSTEM.INI at a minimum!) as part of the system, often ignoring
the (sometimes considerable) fine-tuning these configuration files go
through *between* system and executable backups.
One last point--it cannot be stressed enough that you *MUST* have a
full, working copy of the software you need to restore your backups in a
safe place. You must be able to guarantee that this software is not
virus infected should you ever have to use it, *AND* that it is fully
usable should you be facing a machine that has had its entire hard drive
"wiped clean".
Subscribe to:
Posts (Atom)
