VIRUS-L Digest Monday, 7 Oct 1991 Volume 4 : Issue 184
Today's Topics:
Hardware v. Software
Help in selecting an anti-virus utility for the PC (PC)
Re: Anti-virus sources off the nets?
Hardware, hardware...
Forget Turing...
Help! Viruses infecting only floppies (PC)
New NOVELL virus? (NOVELL) (PC)
Info on Solomon's A-V? (PC)
Re: Why Bulgaria?
Re: Bulgarian virus writers (PC)
Re: New Virus Warning (PC)
Overwriting viri
File infectors
Update to Product Test on Norton AntiVirus, version 1.5
VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed. Contributions should be relevant, concise,
polite, etc. Please sign submissions with your real name. Send
contributions to
[email protected] (that's equivalent to
VIRUS-L at LEHIIBM1 for you BITNET folks). Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list. Administrative mail (comments, suggestions,
and so forth) should be sent to me at:
[email protected].
Ken van Wyk
----------------------------------------------------------------------
Date: Sat, 05 Oct 91 11:36:00 -0400
>From:
[email protected]
Subject: Hardware v. Software
[Origin of the following is lost to me in the thread]:
> the enemy uses for attack. Hardware defenses are needed to put a
> stop to viruses. Software defenses can never do that. Hardware
> defenses cannot be subverted by software.
Bontchev:
>Prove your claim. Describe a hardware defense that cannot be
>subverted.
These are two extreme positions of the same argument.
Cohen has described a hardware mechanism that cannot be subverted by
software. It is called the application machine. It is a computer such
as your pocket calculator, the arcade machine, or the automatic teller
machine. It is a machine whose capabilities no longer include
programming. That is, it has been bound so as to resist any further
change. Cohen argues that in a world of such machines we might enjoy
most, but not all, of the advantages of the modern computer.
Most of us would resist such a world. We recognize that progammability
is too valuable to give up simply in the name of resisting viruses.
However, the argument demonstrates that what is at issue here is a
trade-off. We must strike a balance between early and total binding,
such as we might accomplish by burning a function into hardware, and
reserving so much freedom to the end-user that he damages himself and
others. It is the classic and eternal argument between authority and
freedom, order and chaos. These problems do not lend themselves to
global solutions. While the hardware solution is attractive, it is
Draconian.
Of course, it is also ineffective in the short term. The virus problem
is not a problem of the machines that we sell today, but of those that
have already been deployed. We have seen examples, described here, of
machines that include features that make them more resistant to viruses.
While they may offer some protection to the owners of those machines,
they have a vanishingly small effect on the global problem. Since the
population of machines in the world is obviously large enough to
guarantee the success of some viruses, and since that population is
likely to persist for a decade or more, new hardware features are not
likely to have much effect.
Note also that any hardware features that make a new machine
incompatible with current software will cost such machines a significant
part of the market. Viruses are just a special case of that software.
While it may be possible to design features that exploit the small
differences between viruses and other software, both Cohen and
experience to date suggest that such mechanisms can be only partially
effective.
The desire for hardware mechanism is part of the desire for measures
that are totally effective. In security in general, and virus
protection in particular, we have learned that all such measures,
hardware or software, have infinite cost. The issue is not preventing
the execution of all viruses all of the time. Rather, it is resisting
the execution of most viruses most of the time. Such a strategy is
capable of making the population sufficiently resistant to most viruses
that they cannot prosper and spread.
Software can contribute to this more readily than can hardware, if only
because it can be readily retrofitted to the existing population, where
the problem is. That is why it is called "soft," rather than "hard,"
ware. In this case, it is better to have a partially effective solution
widely deployed than a totally effective solution sparsely deployed.
One final comment: many complain that IBM and Microsoft are ultimately
responsible for the virus problem because they failed to make the
systems more resistant. In fact, our systems are vulnerable for the
same reasons that they are popular. They make it easy to get a program
executed at the right time. While many of us would be willing to give
up some of the features that viruses exploit to get themselves
executed, none of us would be able to give up all of them, and we would
not be able to agree on a list.
"Be careful what you ask for; you might get it."
William Hugh Murray, Executive Consultant, Information System Security
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840
203 966 4769, WHMurray at DOCKMASTER.NCSC.MIL
------------------------------
Date: 05 Oct 91 15:41:00 -0400
>From: "Michael Nieman" <
[email protected]>
Subject: Help in selecting an anti-virus utility for the PC (PC)
I am fairly unfamilar with ibm pc and their clones and I was
wondering if anyone out there could help me. I am looking for some
good antivirus utilities for the pc. Any suggestions are welcome and
I would prefer suggestions that I could get from an ftp site.
Thanks for your assistance
Michael Nieman
------------------------------
Date: Sun, 06 Oct 91 00:50:48 +0000
>From:
[email protected] (Ben Liberman)
Subject: Re: Anti-virus sources off the nets?
[email protected] (Albert Lunde) writes:
>I will be talking to some people on virus prevention. They are from
>business, and don't have much access to the "academic" nets like
>bitnet, internet and uucp.
>
>What is available from sources like Compuserve, GEnie, Delphi, BIX? I
>know Disinfectant is posted to a lot of these systems, but I have no
>idea about PC stuff, or about where (what SIG or library, etc.) this
>stuff would be kept.
McAfee's anti-virus software for PC's can be downloaded directly from
their BBS.
408 988 5138 (HST 9600 baud)
- --
------------ ------ ----------------------
Ben Liberman USENET
[email protected]
------------------------------
Date: Sat, 05 Oct 91 20:43:15 -0700
>From:
[email protected] (Fred Waller)
Subject: Hardware, hardware...
[email protected] (Vesselin Bontchev),
quotes from an article of mine:
>> But hardware alone is enough. To illustrate: there's no virus
>> in the world that can bypass a simple hardware device called
>> a write- protect tab. This humble little piece of black paper
>> doesn't care one bit about Cohen's theories. Disobeys them
>> every time. :-)
and replies:
> Wrong. Completely wrong. There is a Bulgarian virus, called
> Darth Vader, which infects COM files only when you copy them.
Darth Vader can infect only AFTER becoming TSR in the system.
HOW did that virus (of which I have some copies) would manage to
become TSR on the system? During COPY? Certainly not. So why the
attempt at confusing the issue with such misleading remarks: "Wrong.
Completely wrong"..?
In other words, the operator must not only intentionally defeat the
hardware protection before the virus can get through it, but s/he
must also EXECUTE the virus. Otherwise, it can't reproduce. That's
not surprising, is it? It's not the virus who's defeating hardware
protection, it's the operator.
Darth VAder may infect during COPY, or it may infect while one sings
La Donna e'Mobile in the shower, but only after becoming TSR and it
CANNOT by itself ever bypass that little piece of cheap black paper
called a write-protect tab, *as long as the tab is in place*. That
was my point.
Which illustrates that no software scheme, no matter how elaborate
or complex, can *ever* defeat even the simplest hardware protection.
And viruses are just software.
> Another Bulgarian virus, the Compiler, infects files only when
> they are created (by the compiler/linker) or when their size is
> about to change. In both cases either the respective media is
> not write-protected, or the user will remove the tab as soon
> as s/he sees the "Write protected" error message.
Again, assuming it has first become TSR, which in turn means that
hardware protection was removed, an infected file brought it and
the virus was then allowed to execute on the machine that had just
been unprotected. No virus can defeat hardware protection by itself.
It's physically impossible. No reasonable person could hold
otherwise.
Software protection, however, can always be defeated by other
software (such as viruses). It's not necessary for an operator to
disable it for a new virus to bypass it. Permanent software
protection against viruses is impossible.
Fred (W)
[email protected]
---------------------------------------------------------------------
Hardware vulnerari non posse. :-)
---------------------------------------------------------------------
------------------------------
Date: Sat, 05 Oct 91 20:47:30 -0700
>From:
[email protected] (Fred Waller)
Subject: Forget Turing...
[email protected] (Vesselin Bontchev) writes:
> Remember, Cohen proved that on machines with Turing capability,
> shareing of information, and transitivity of information flow,
> the viruses are possible, and unstoppable in general.
(Such faithful reliance on theory... But all theories die, sooner
or later. If Turing's original conceptualization is an obstacle,
why not just change it a little? :-) If the theory doesn't fit
the facts, change the theory, don't change the facts...)
I remember _something_, but am not sure that THAT's *exactly* what
Cohen said... And, if he did, then I wonder if he missed something...
Did he consider a variant of the multitape Turing machine (say, two-
tape) in which one of the tapes was only partially enabled,
operating under a specific (MS DOS) regime..?
It should be possible to make such a machine emulate a more
conventional Turing machine (i.e., it should compute the same
functions that a conventional, one-tape Turing-based machine can
compute, perhaps with minor modification in some cases) and yet
it could be made resistant to viruses.
Strict demonstration that the original Turing model and all the
modified models, including the multi-tape machine, can each compute
the same class of functions was done by showing that for every
"variant" machine there exists some form of "standard" Turing machine
that can emulate its behavior, and viceversa. In other words, all
proposed modifications of the Turing machine are "convertible" to
the standard machine, and viceversa.
However, for our concept to be practical, it has to mean that a
modified two-tape Turing machine in which one of the tapes is only
partially enabled (at the "physical" level) would be not-completely
equivalent to any possible form of the standard machine. This
would also mean that such a variation of the Turing machine might
actually be considered as a different kind of abstract computing
device which, unlike other modifications of the Turing machine,
cannot be *fully* emulated by a standard Turing machine.
As a practical test, physical realization of a computer having
such characteristics could be taken as indication that such a
Turing-based machine was a valid concept. If implemented, the
design could lead to a virus-resistant machine because it could
be made to allow discrimination between stored code and stored
data not only temporarily, but permanently as well.
As it turns out, under certain limited circumstances, it IS
possible to implement a design that is based on such a modification
of the multitape variation of the Turing model. Such a design
relies on currently-available properties of *both* software and
hardware, but is initially enabled by hardware modifications alone.
The new machine is able to perform unique functions by restricting
certain other functions of the standard model. One of the abilities
it acquires is equivalent to resolution of von Neumann's ambiguity
over long periods (under MS DOS and similar OS regimes).
A machine possessing such characteristics has been easily and
inexpensively built. As expected, it has indeed proven itself
to be virus-resistant _per se_ (at the hardware level) when used
properly *and* of being capable of running conventional (MS DOS)
computer programs at the same time.
The partially-enabled tape becomes a new kind of element in the
machine (i.e., one of the two "read/write heads" in the two-tape
modification becomes a "read-only" head). Of course, such elements
(not originally included in Turing's definition) or their functional
equivalents, have been commonplace for a long time, since the
introduction of optional write-protection in computers. (To my
knowledge, no one has claimed that our PCs "ceased being Turing-
based machines" while write-protection was in use, but if anyone
insists in viewing things that way, I won't object).
The characteristic that distinguishes my machine from conventional
Turing-capable microcomputers is that the partially-enabled tape
(= disk) is permanently dedicated to storage of instructions, while
the fully-enabled tape (= disk) is dedicated to storage of data.
Under an MS DOS regime, this duality allows resolving von Neumann's
ambiguity in practice (at least as far as MS DOS is concerned!),
because it provides permanent, physical separation of code and data.
Although this condition contradicts Turing's original definition,
it is achieved without significant detriment to the functionality
of the machine as an MS DOS computer in practical applications.
This quality also makes the machine virus-resistant. Even if a file
infector were to be intentionally allowed on the partially-enabled
drive, it would not be able to replicate there. (Intentionally-
allowed Boot viruses could still infect new diskettes inserted into
the machine, because the Boot sector is an exception to our rule
that executable code be restricted to the protected drive. This
breach of the rule can also be stopped by simple, but additional,
hardware means).
Thus, under selected circumstances (MS DOS regime), it's possible
to implement in practice a computer based on a variation of the
Turing machine which can emulate most functions of a conventional
Turing-based computer but which, in turn, cannot be fully emulated
by one. Such a machine is inherently virus-resistant. The resistance
is achieved by selectively restricting some of the qualities of
the `standard' machine.
A main reason this design is possible in practice is that MS DOS
does not use ALL the Turing-like capabilities of the standard
machine. It may allow them, but does not require them. Therefore,
it is a simple matter to design a physical system, capable of running
MS DOS and its applications, in which the not-required functions are
restricted or eliminated. Making the restriction permanent limits
certain desirable functions (ability to update programs), so it is
made temporary, i.e., the resolution of von Neumann's ambiguity
is discontinnuous over time, but the periods of resolution are made
so long (weeks, years) as to be considered permanent for practical
purposes.
(The design described here was originally suggested by practical
necessity during work with viruses. I have made no detailed search
of the literature. However, it seems that the desirability of
physically separating code from data in a manner similar to the
one described above has been perceived by others before me.
Unfortunately, the idea seems to have been dismissed as impossible
or impractical as an antivirus measure, on purely theoretical
grounds and without practical investigation. But the design of
hardware systems cannot be logically derived from purely symbolic
considerations, which seems to be what some earlier proponents
tried to do.)
Returning to the practical aspect, it's also interesting that:
1. Such machines may be built at extremely low premium
over the cost of a comparable conventional microcomputer
and
2. existing MS DOS microcomputers can usually be easily,
quickly and inexpensively converted to the new design.
3. The one-time cost of such modification compares favorably
with the long-term cost of software protection, which is
also much less effective.
4. This type of machine is useful not only in standalone
applications, but in multi-user file servers as well.
:-)
Since the machine is vulnerable to virus attack only during very
short and clearly identified periods, it is much easier to carry out
thoughtful profilaxis. Additional security may be achieved
automatically to a very large, if not absolute degree, by use of
firmware or other restrictors that would allow copy but not
execution while the machine is in unprotected state. When the
machine is restored to its "protected state", it is invulnerable
to virus attack AND to virus propagation by MS DOS viruses. Such
additional security during the unprotected state is slightly more
expensive.
Fred (W.)
[email protected]
------------------------------------------------------------------
Now, a *hardware virus*, that would be a little more difficult...
------------------------------------------------------------------
------------------------------
Date: Sun, 06 Oct 91 12:27:21 -0700
>From:
[email protected] (Rob Slade)
Subject: Help! Viruses infecting only floppies (PC)
[email protected] (HAWKINS, WILLIAM DARYL) writes:
> Does anybody out there know of a virus which affects only floppy drives,
> and not hard drives? Whenever I try to read, write, or format a floppy
> disk in either a 5 1/4" 1.2 MB or a 3.5" 1.44 MB drive, I get errors
> ranging from data errors to track 0 bad..... I am cuurently running
Given that you are seeing these problems on HD floppies, it may be a
result of the Stoned virus. Many early versions overwrote portions of
the system areas of HD floppies. However, your posting really gives
very little information. Have you tried checking your system with
FPROT or SCAN?
=============
Vancouver
[email protected] | "If you do buy a
Institute for
[email protected] | computer, don't
Research into CyberStore | turn it on."
User (Datapac 3020 8530 1030)| Richards' 2d Law
Security Canada V7K 2G6 | of Data Security
------------------------------
Date: Sun, 06 Oct 91 12:06:25 -0700
>From:
[email protected] (Rob Slade)
Subject: New NOVELL virus? (NOVELL) (PC)
[email protected] writes:
> Today, a network under NOVELL 3.11, was hit by a unknown virus, at
> least in our environment, the virus only affects the server, when you
> issue the command "load monitor", few minutes later, the screen clears
> and a worm composed by block characters showing different levels of
> gray begins to run across the screen, the creature disappears when you
> press the ESC key.
Actually, there is little in the details that you have provided to
indicate that what you are seeing is coursed by a virus at all. The
fact that the display is seen only in relation to one program would
indicate that it is not spreading, and that would suggest that you
have a trojan (unlikely, since you don't mention any damage) or a
prank. Have you checked for a SERVER.COM or SERVER.BAT file, possibly
hidden? Have you tried reinstalling SERVER.EXE? Have you checked the
SERVER.EXE file size, date and image against the original?
> We're checked the server under DOS with CPAV v 1.0, and installed the
> VSAFE.SYS program in memory, then run the program SERVER.EXE, issue
> the "load monitor" command, and few minutes later, the worm appears on
> the screen, and the VSAFE program says nothing, the CPAV program
> doesn't say anything, and the worm continue to run across the screen.
CPAV and VSAFE, as used by most, check for known viri. My memory
being what it is, I don't recognize this beast from the description.
That isn't proof, but maybe you *do* have a new virus. In that case,
you should use the option for change detection that CPAV provides, and
see if any files are changing size or image. The other possibility is
that you have some type of boot sector infector. You can test that by
"feeding" the suspect machine with new floppies, and checking the boot
sector before and after with DEBUG. Alternately (and my own
preference) would be to check the partition boot record of the server
with something like FPROT's F-PBR. (You will have to get an older
version of FPROT: F-PBR is not shipped with version 2.00.)
=============
Vancouver
[email protected] | "If you do buy a
Institute for
[email protected] | computer, don't
Research into CyberStore | turn it on."
User (Datapac 3020 8530 1030)| Richards' 2d Law
Security Canada V7K 2G6 | of Data Security
------------------------------
Date: Sun, 06 Oct 91 19:25:37 -0600
>From: Jesus Miguel Garcia <
[email protected]>
Subject: Info on Solomon's A-V? (PC)
Anyone has Tryed Dr. Solomon's Anti-Virus?
How is it? I Heard about its great. How can i get it?
Here in Mexico, i think that we dont have a store for buy it. Should
i go to Usa for buy it? :)
Thanks? Write me Mail.
Regards,
Miguel.
*************************************************************************
*************************************************************************
* M T C *
* O H R J. Miguel Garcia Rodriguez *
* T E U Apartado Postal 2399-J *
* L E 64841, Monterrey, N.L. *
* E M E X I C O *
* y ...
[email protected]. Mx *
*
[email protected] *
* *
*************************************************************************
*************************************************************************
------------------------------
Date: 07 Oct 91 10:03:35 +0000
>From:
[email protected] (Vesselin Bontchev)
Subject: Re: Why Bulgaria?
ROsman%ASS%
[email protected] writes:
> I have noticed that a large number of viruses are listed with Bulgaria
> as their origin. Does anyone have a notion why? Is it that the
> Bulgarians aren't on the net to defend themselves? A twisted sense of
Indeed, the Bulgarians are not on the net... There are -very- few
Internet sites in Bulgaria and I guess that they do not read
comp.virus...
> national pride? A single prolific and perverted programmer? What?
In short: (1) a lot of very qualified and low paid young programmers
(2) total lack of legislature concerning the virus problem; (3)
incorrect public oppinion; (4) easy access of information of a
particular kind; (5) perverted wish for fame...
All these are result of a combination of particular social, economical
and political conditions, described in my paper.
Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev Universitaet Hamburg, FB Informatik - AGN
[email protected] Schlueterstrasse 70, D-2000 Hamburg 13
New address after October 1, 1991: Vogt-Koelln-Strasse 30, D-2000, Hamburg 54
------------------------------
Date: 07 Oct 91 09:00:35 +0000
>From:
[email protected] (Vesselin Bontchev)
Subject: Re: Bulgarian virus writers (PC)
[email protected] (Anthony Appleyard) writes:
>f these two disastrously productive virus writers are operating openly, as
>eems from the above, can't the government or law courts of Bulgaria act against
>hem?? like the USA courts did with Morris and his Internet worm that time.
Nope. According to the Bulgarian legislation, there is no such thing
as ownership of computer information (or copyright either). If I go
and destroy somebody's computer information, s/he cannot sue me unless
I physically damage his/her computer. Also, the creation and wilful
spread of computer viruses is not regarded as a crime in Bulgaria -
yet. That's one of the reasons why virus writing is so popular there.
I spoke with two people's representatives from the Parliament and they
both showed good understanding of the problem and promised to help,
but until now nothing has been done... :-((
> [Ed. This message is closely related to Rich Osman's
> (ROsman%ASS%
[email protected]) question in today's digest.
> Vesselin Bontchev presented his paper, "The Bulgarian and Soviet Virus
> Factories", at last month's Virus Bulletin conference. The paper
> addresses both of these questions.]
Several people requested this paper. May I make it publicly available?
I mean, does this break any copyright laws? As far as I understood,
the authors of the papers, presented on the VB conferense retain full
copyright on their respective articles. Besides, the version of the
paper that I have is a slightly improved version of what has been
printed in the proceedings. So, maybe it is possible to provide it?
Ken?
[Ed. We're working on this and hope to have the file available shortly.]
Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev Universitaet Hamburg, FB Informatik - AGN
[email protected] Schlueterstrasse 70, D-2000 Hamburg 13
New address after October 1, 1991: Vogt-Koelln-Strasse 30, D-2000, Hamburg 54
------------------------------
Date: 07 Oct 91 09:23:38 +0000
>From:
[email protected] (Vesselin Bontchev)
Subject: Re: New Virus Warning (PC)
[email protected] (Mark Aitchison, U of Canty; Physics) writes:
> Am I safe in assuming that just looking at the directory entries, and at
> absolute sectors on the disk (or even via int 25h) will not cause a virus
> to infect a file that wasn't infected before? (Other than the boot sector
)
> For that matter, any tips on "safe" simple tests would be appreciated
> (yes, I've already thought of the 6-byte method).
It is my understanding that we're speaking about the Dir II virus. In
this case - yes accessing the directory via INT 25h will cause
infection of all directory entries that belong to COM and EXE files,
which can be found in the accessed directory sector. If the virus is
resident in memory, of course. Besides, this virus does not infect the
boot sector - you probably mean the last cluster of the disk. If this
virus is resident and active in memory, there are no safe tests. Any
disk access will cause the virus body to be written to the last
cluster, and any directory access will infect all directory entries
that are contained in the directory.
> While I'm on the scrounge for information... has anyone tested those
> programs that automatically squash data on your disk (Stacker &
> DrDOS's SuperStore) to see what various viruses do. My guess is that
> file infectors either won't work or will totally mess up the whole
> compressed partition, but even more I'm worried about disinfectant
> programs ruining the disk. I do have SuperStore, a few viruses, but
> not enough nerve to risk my data on the tests!
I use only STACKER, so I can supply information only about it. Stacker
is completely transparent to the DOS file functions (and even to the
sector access functions), so most viruses spread without problems on a
stacked volume. Especially Dir II won't infect anything on such a
volume, since it doesn't infect partitions that are accessed through a
loadable device driver.
There is, however, another danger. Consider a destructive virus (like
the Dark Avenger), which causes destruction by bypassing all programs
which have intercepted INT 13h and writing a sector on a random place
on the disk. This will have the same effect on a stacked volume, as
changing a few random bytes in the middle of a ZIP archive.
Fortunately, the STACKER package contains a powerful equivalent of
PKZIPFIX - it is called SCHECK. However, I also didn't tested how well
it is able to repair a stacked volume, if a whole disk sector has been
modified.
Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev Universitaet Hamburg, FB Informatik - AGN
[email protected] Schlueterstrasse 70, D-2000 Hamburg 13
New address after October 1, 1991: Vogt-Koelln-Strasse 30, D-2000, Hamburg 54
------------------------------
Date: Sun, 06 Oct 91 22:37:43 -0700
>From:
[email protected] (Rob Slade)
Subject: Overwriting viri
FUNPIV2.CVP 911006
Viral code insertion
There are four ways to attach code to an existing program:
overwrite existing program code, add code to the beginning of
the program, add code to the end of the program and not add code
to the existing program.
Overwriting viral programs are a very simplistic answer to the
problem of how to add code to an existing program without
changing the file size. By simply overlaying code which is
already on the disk, the original size remains unchanged. There
are a few problems with this approach.
The first is the problem of how to get the virus "called" when
the infected program is run. If the code is just inserted
anywhere, it may not be in a part of the program that gets used
every time the program is run. (Every programmer is aware of
the Pareto Principle's application here: 20 percent of the code
does 80 percent of the work. Some code never gets called at
all.) It is possible, by an analysis of the code of the target
program, to find an "entry point" which is used extensively. It
is also possible, and a lot easier, to place a jump at the
beginning of the program which points to the viral code.
The second problem is much more difficult to deal with. If the
virus code overwrites existing portions of the program code, how
do you know the loss of that program code is not fatal to the
target program? Analysis of this type, on the original code,
would be very difficult indeed. "Successful" overwriting viri
tend to be short, and to look for extensive strings of NUL
characters to replace. (The NUL characters tend to be used to
"reserve" stack space, and thus are not vital to the program.)
Even if the original code is not vital to the program, it may,
if replaced, cause the program to exhibit strange behaviours,
and thus lead to detection of the viral infection.
Thus, while overwriting viri solve the problem of file size,
they bring with them some inherent problems which appear, at
this time, to severely limit their effectiveness "in the wild".
To this date, while many overwriting viri have been written,
none have enjoyed great "success", or become a widespread and
major problem.
(The Zen-like nature of the opening paragraph will be explained
in future columns.)
copyright Robert M. Slade, 1991 FUNPIV2.CVP 911006
=============
Vancouver
[email protected] | "If you do buy a
Institute for
[email protected] | computer, don't
Research into CyberStore | turn it on."
User (Datapac 3020 8530 1030)| Richards' 2d Law
Security Canada V7K 2G6 | of Data Security
------------------------------
Date: Sun, 06 Oct 91 22:36:30 -0700
>From:
[email protected] (Rob Slade)
Subject: File infectors
FUNPIV1.CVP 911006
File infecting viri
File, or program, infecting viral programs, while possibly not
as numerous as boot sector infectors in terms of actual
infections, represent the greatest number of known viral
strains, at least in the MS-DOS world. This may be due to the
fact that file infectors are not as constrained in size as BSIs,
or that file infectors do not require the detailed knowledge of
system "internals" which may be necessary for effective boot
sector viri.
File infecting viri spread by adding code to existing executable
files. They have the potential to become active when an
infected program is run. Whereas boot sector infectors must be
memory resident in order to spread, file infecting programs have
more options in terms of infection. This means that there is
greater range in the scope for writing file infecting viri, but
it also means that there may be fewer opportunities for a given
virus to reproduce itself.
File infecting viral programs must, of necessity, make some kind
of change in the target file. If normal DOS calls are used to
write to it the file creation date will be changed. If code is
added to it, the file size will change. Even if areas of the
file are overwritten in such a way that the file length remains
unchanged, a parity, checksum, cyclic redundancy or Hamming code
check should be able to detect the fact that there has been some
change. The Lehigh and Jerusalem viri, the first to become
widely known to the research community on the Internet, were
both initially identified by changes they made to target files
(the Jerusalem being widely known by its length as "1813".)
"Change detection", therefore, remains one of the most popular
means of virus detection on the part of antiviral software
producers.
Because change detection is a means of virus detection that
requires no sophisticated programming (in some cases, no
programming at all), virus writers have attempted to camouflage
changes where they can. It is not a difficult task to avoid
making changes to the file creation date, or to return the date
to its original value. It is possible to "overlay" the original
code of the program, so that the file is not increased in size.
Most recently, virus authors have been using "stealth"
programming: a means of "shortcutting" the operating system, and
returning only the original, unchanged, values at any request
for information.
copyright Robert M. Slade, 1991 FUNPIV1.CVP 911006
=============
Vancouver
[email protected] | "If you do buy a
Institute for
[email protected] | computer, don't
Research into CyberStore | turn it on."
User (Datapac 3020 8530 1030)| Richards' 2d Law
Security Canada V7K 2G6 | of Data Security
------------------------------
Date: Fri, 04 Oct 91 15:08:41 -0600
>From: Chris McDonald ASQNC-TWS-R-SO <
[email protected]>
Subject: Update to Product Test on Norton AntiVirus, version 1.5
*******************************************************************************
PT-28
February 1991
Revised October 1991
*******************************************************************************
1. Product Description: Norton AntiVirus is a virus protection utility for
the IBM PC and its compatibles. The product includes virus detection,
disinfection, and protection. This revision addresses version 1.5.
2. Product Acquisition: Norton AntiVirus is available from Symantec
Corporation, Peter Norton Group, 10201 Torre Avenue, Cupertino, CA 95014-2132.
The retail price is $129.95; but there are numerous secondary sources with
single copy prices that have ranged from $78.00 to $83.00 in trade publication
advertisements. Site licenses are also available.
3. Product Testers: Chris Mc Donald, Computer Systems Analyst, White Sands
Missile Range, NM 88002-5506, DSN: 258-4176, DDN:
[email protected]
or
[email protected].
[Ed. The remainder of this product review is available by anonymous
FTP on cert.sei.cmu.edu in the pub/virus-l/docs/reviews directory.]
------------------------------
End of VIRUS-L Digest [Volume 4 Issue 184]
******************************************
Downloaded From P-80 International Information Systems 304-744-2253
