To:	   VIRUS-L@LEHIGH.EDU
Subject:   VIRUS-L Digest V6 #13
--------
VIRUS-L Digest   Thursday, 28 Jan 1993    Volume 6 : Issue 13

Today's Topics:

Re: on the definition of virus
Re:Viral Code Access [Yaron .. Goland]
Re: Heuristic Scanners
Re: Internet Worm Functions - part 2 (CVP)
Re: How to measure polymorphism
Re: What is a virus ?
Re: Good use of (possible bad) viruses [V-L v6 #3]
Measuring polymorphism
protecting the checksum file
Re: Infection question (was: Viral Based Distribution System)
Re: on the definition of virus
Thanks to Symantec (PC)
False Alarms (was: Cansu...) (PC)
Any know virus/trojan with the following results? (PC)
V-Sign on printer diskettes (PC)
Re: Virus Simulator MtE (PC)
696 Virus? (PC)
Possible new virus: Dudley! (PC)
Stoned_NSW; New boot sector virus (PC)
False positives, disk buffers, and IO.SYS (PC)

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.  (The complete set of posting guidelines is available by
FTP on cert.sei.cmu.edu or upon request.) Please sign submissions with
your real name.  Send contributions to VIRUS-L@LEHIGH.EDU.
Information on accessing anti-virus, documentation, and back-issue
archives is distributed periodically on the list.  A FAQ (Frequently
Asked Questions) document and all of the back-issues are available by
anonymous FTP on cert.org (192.88.209.5).  Administrative mail
(comments, suggestions, and so forth) should be sent to me at:
<krvw@CERT.ORG>.

   Ken van Wyk

----------------------------------------------------------------------

Date:    Thu, 21 Jan 93 00:10:23 -0500
From:    fc@turing.duq.edu (Fred Cohen)
Subject: Re: on the definition of virus

	I am gratified at the wonderful discussions going on about
definitions of the term virus.  Two particular writers were especially
lucid, and I thought I would respond to them - even though I cannot
include their postings in my response due to circumstances beyond my
immediate control.

	The linguistic definition could use some work.  Part of the problem
is that the mathematical definition of a virus is `a member of a viral set'.
So what is a viral set?  Well - you might try reading `Computer Viruses'
for the real details, but I'll try anyway.  The real equation (taken
from that text) is (in abbreviated form):

	   M
	v ===> V

which means (loosely) that any virus v which is a member of the viral
set V for machine M, when run on machine M, writes a, possibly different
element of V somewhere else on the Turing machine tape at a subsequent
time.  This definition makes `evolution' an inherent part of the virus
definition.  Another way of stating this is:

	(M,v) => (M,V)

	As to `worms' being a subset of `viruses', I agree.  In fact, I
recently published a journal article with a formal definition of worms.
In this definition, worms are a subset of viruses, and several properties
of worms were shown.  I am not certain that my definition captured the
meaning that is commonly held for worms, but in essence, it called a worm
a virus where at least one of the replicas is guaranteed to `run' after
it is written.  This leads to all sorts of things, but perhaps I should
see your definitions.

	The idea of partial viruses is indeed covered by restrictions on
the environment - but perhaps this leads to interesting classification
schemes.  Many viruses run on a very large number of different M, but
perhaps we can look for the necessary and sufficient conditions on M
and use that to classify the viruses.

	One of the side effects of the mathematical definition leads us
to the issue of polymorphism.  Without debating the definition of that
term, it seems sensible from a mathematical view to classify viral sets
in terms of their sizes and perhaps other things of interest.  Singleton
sets are obviously not polymorphic.  Finite sized sets with a few
billion varieties might be classified in terms of the complexity
required by an algorithm to detect members of the set.  A viral set of
which any member can be detected with a polynomial time algorithm is
easily classified.  This also leads rather directly to the figure most
people are interested in - scanning time.  Most current polymorphic
viruses are probably constant time - and the rest are almost certainly
sub-linear.  For larger sets (i.e.  potentially infinite sets), we can
use other measures of complexity.  You might read one of my recent
papers in Computers and Security that (very weakly) classifies some
evolutionary techniques in terms of complexity. 

	Mathematical definitions have their advantages, but one of their
(dis?)advantages is that you have to think about all of these issues
BEFORE you have an even marginal mathematical definition.  One of the
issues that I had to think about was how to differentiate programs from
other information using Turing's model of computers.  Of course I could
not because there is no difference.  Information only has meaning in
that it is interpreted - and on a Turing machine, there are potentially
infinite numbers of different interpretation mechanisms.  This is one of
the reasons that the definition encompasses so-called companion viruses,
boot sector viruses, et.  al.  A good mathematical definition should serve
you well for a very long time - at least a few thousand years!

	For the reader interested in even more of this stuf, I have
written several books on the subject.  For additional information, you
might FAX me.  Which reminds me - I am just finishing a new book you might
be interested in titled:

				It's Alive!!!

	Those who object to revealing the source code of viruses will
probably not want to read it - it shows some viruses written in `Life'
and RedCode!

__________________________________________________________________________
8:30AM-2PM Eastern		Protection		2PM-8:30PM Eastern
US+412-422-4134			 Experts		   US+907-344-5164
	FAX US+412-422-4135 -OR- 907-344-3069 24 hours - 7 days
__________________________________________________________________________


------------------------------

Date:    Thu, 21 Jan 93 18:37:19 +0100
From:    brunnstein@rz.informatik.uni-hamburg.dbp.de
Subject: Re:Viral Code Access [Yaron .. Goland]

Yaron (The Jester) Goland complains that some institution which he
asked for virus code was not willing to send any; he moreover asks
whether "..this (is) 'open and free exchange of information' ".

As a university teacher and researcher, I absolutely believe in "Free
Exchange of Information", and I have often given arguments against
principles of "Secur- ity by Obscurity". We follow FEI principles as
long as no serious obstacles request less-open, more-restrictive
policies. Virus Test Center of the Faculty for Informatics of Hamburg
University has therefore always been open to inform users about
potential damage (see Computer Virus Catalog) and related problems.

Regarding the *transfer of malicious code*, there are restrictions
which also a university lab must observe. In German law (Penal Code),
it is a crime "to endanger a dataprocessing unit which is essential
for the work for an enterprise, as state agency or any individuum". It
is also a crime to attempt such damage, as it is a crime to assist in
the attempt or in the establishment of a damage.

Though there have not been much court cases here (I contributed
expertise in few cases myself), we must assume that installation of a
virus,willingly or unknowingly, may constitute such a crime ("Computer
Sabotage", section 303b, German Penal Code). If a virus infection
would follow from any virus-infected medium which originates from VTC,
we may be prosecuted for assistance. Though I have only referred to
German law, legislation in other countries either exists or is being
developped which directly or indirectly adresses virus infections as a
"illegal activity" (not to use the term "crime" here).

In this situation, even university people must reduce the degrees of
freedom in the "free flow of information". In order NOT to reduce this
to ZERO, we have agreed that we understand the situation as follows:
if a person whom we know as trustworthy (=on whose ability to avoid
damages to other systems we can rely), then we may transfer to her/him
viruses as no offense against a legal code may result with sufficient
probability; also in such cases, we apply proper safety measures, such
as encryption. In this context and in rare cases, VTC has helped
people to improve the quality of methods (we have regarded this as our
duty to protect the broad user community from inadequate AV
behaviour).

Sorry for vasting the bandwidth, but the community has any right to
know why even university people believing in "Free Flow of
Information" sometimes have to restrict access.

Klaus Brunnstein, University of Hamburg, Germany (January 8, 1993)

PS: within the International Federation for Information Processing (IFIP),
   there is one Working Group (WG 9.6) which works on Harmonization of Computer
   Crime Legislation (including virus problems). There will be a 1st conference
   in August 1993, on a ship plying between Stockholm and St.Petersburg. 
   Information available from me.

------------------------------

Date:    Thu, 21 Jan 93 18:15:22 +0000
From:    antkow@sis.uucp (Chris Antkow)
Subject: Re: Heuristic Scanners

>Yeah...thanks....
>
>Anybody who knows anything at all about heuristic scanning (like myself)
>is almost certainly not interested in helping you - after all, the only
>people that could benefit from the software you might develop would be
>virus authors.
 
 ...or anyone who wants to develop a better heuristic scanner! Gee
you're paranoid...

 Chris
 antkow@eclipse.sheridanc.on.ca


------------------------------

Date:    Fri, 22 Jan 93 11:43:24 +0000
From:    cowboy@trans.csuohio.edu (Joe Rosenfeld)
Subject: Re: Internet Worm Functions - part 2 (CVP)

Olivier MJ Crepin-Leblond (o.crepin-leblond@ic.ac.uk) wrote:
: >Date:    Thu, 07 Jan 93 16:51:07 -0800
: >From:    rslade@sfu.ca

: [...]

: [...stuff deleted...] 
:  
: The worm used to check if it had already infected the remote computer
: and if it indeed had, then it would not infect it again. However, in
: order to curb any attempt by system managers to "inoculate their
: machine by running a similar process", each after each 10
: interrogations, a machine would return a negative answer, thus letting
: the worm re-infect it. RTM's BIG mistake was that number. He greatly
: underestimated the speed of the internet. For a lower probability of
: detection of his worm, he would have had to use a number at least 100
: times bigger !

: When he came back from a break after having released the worm, the
: internet had been brought to a near standstill.

Anyone know whatever happened to RTM?  I read _Cyberpunk_ which was
very interesting, and despite the woes he unleashed onto the internet
and all of us, I more or less felt sorry for him

Regards-
Joe

| Joe Rosenfeld			  cowboy@trans.csuohio.edu
| CSU Law Library                joer@inca.law.csuohio.edu
|         "We look for things ... to make us go!"

------------------------------

Date:    Fri, 22 Jan 93 11:15:27 -0500
From:    "David M. Chess" <chess@watson.ibm.com>
Subject: Re: How to measure polymorphism

> From:    ncoast!arnold@usenet.INS.CWRU.Edu

>ncase You Have Not Tried It TPE 1.1 Is Very Very Good..I have not
>Found a Pattern That Can be scanned with a simply Wild Card Scanner
>Yet..I think it is better than MTE..And I believe it is totaly
>Polymorphic..

I suppose we all have our own definitions of "good"!  *8) We've
completely analyzed TPE (1.0-1.3).  It's roughly comparable to MtE;
simpler in some ways and more complex in others.  You won't find a
pattern of bytes and wildcards that will reliably detect infected
files; like the MtE, it takes an algorithm.  Various approaches are
possible, but none are as simple as a signature or two.

- - -- -
David M. Chess                           For Best Results,
High Integrity Computing Lab                Consume Before Above Date
IBM Watson Research


------------------------------

Date:    22 Jan 93 17:50:34 +0000
From:    Sam Wilson <ercm20@festival.edinburgh.ac.uk>
Subject: Re: What is a virus ?

I'm following up Pagett's posting just because the Subject seems
particularly apposite for the following not because I actually want to
comment on or add to what he says.

In this week's 'Computing' (a UK weekly trade paper, and usually
fairly well informed) is an article, reproduced below without any
permission at all.  It seems as though people may now be writing
'cause: probable virus' in operations reports instead of 'cause:
unknown'.  Also the headline and summary seem to bear little relation
to the actual text - the report cited may be a lot more sensible than
this rather misleading (so far as I can tell) article.

Sam Wilson
Network Services Division
Computing Services, The University of Edinburgh
Edinburgh, Scotland, UK
- -----------------------------------------------


Mainframes hit by epidemic of viruses
=====================================

Mainframe systems are more at risk from viruses than from any other form
of computer disaster.
- ------------------------------------------------------------------------

   Users across Europe and North America have reported an alarming increase
in the frequency of virus attacks.  And, according to research carried
out by UK analyst Xephon, viruses accounted for over half of all
computer diasters last year. 
   A survey of 816 European and North American mainframe sites showed
that 35.5% of users had reported disasters, 60% of which had been due to
viruses.  The figures, published last month, show a marked increase on
1991, when viruses accounted for 44% of disasters.  In 1990 the figure
was just 23%. 
   'Although the number of virus attacks has increased sharply since
1990, the number of incidents of hacking has remained relatively
constant.  It seems the antisocial element in the computer fraternity
now favours the use of viruses, which incur little risk of detection and
little expense,' Xephon said. 
   Fault-tolerant computer manufacturer Tandem suffered an embarrassing
set-back last year when many of the its sytems were brought to a halt by
a software bug.  A Tandem spokesman said the bug was probably caused by
a virus. 
   Crime proved the most costly disaster in the Xephon sample, followed
by fire and viruses.  However, the average cost to victims of viruses
halved last year, indicating that users had become more adept at dealing
with them. 
   For example, British Airways armed 90 field engineers with anti-virus
disks last November to run health checks on its 9,000 PCs in preparation
for a possible Friday the 13th virus ('Computing,' 12 November). 
   The average cost of a disaster in 1992 was $17,800 (pounds sterling
11,560), a little over half the 1991 figure.
   IBM's VM operating system chalked up the biggest tally of disasters,
proving especially prone to hacking.
   The breakdown by region showed the UK to be the most disaster-prone,
being particularly subject to flooding and hacking.

------------------------------

Date:    Fri, 22 Jan 93 14:16:41 -0500
From:    "Tom Zmudzinski" <DISALAN.ZMUDZINT@mailhub.ims.disa.mil>
Subject: Re: Good use of (possible bad) viruses [V-L v6 #3]

In V-L v6 #3, Suzana Stojakovic-Celustka (celustka@sun.felk.cvut.cs) says:

>                                             [...] If such virus *by
> accident* escape from my lab I already have a response and there is no
> ethical problem at all.

WRONGAMUNGO!  While this could be argued at great length [somewhere
else], let's cut to the chase:  even if your planned response is 100%
safe, effective, universally available and free [fat chance!], you would
still have to "make whole" the victims of your *accidental* escapee.
Otherwise you will have done damage (regardless of degree) to persons
who did not accept (co-)responsibility for your actions.

>                           [...] There is slight similarity in this
> idea with reaction of human immunity system. Anyone has ethical
> problem with her/his own immunity system ?

The question sets up a meaningless strawman.  One of the definitions
of "ethical" is "conforming to accepted and esp. professional standards
of conduct".  Setting theology aside, the human immunity system wasn't
designed by a person so there are can be no standards of conduct and
thus, no ethics.  Now if you want to talk [again, somewhere else] about
MODIFYING the human immunity system, you can (and must) get into ethics.

Tom Zmudzinski               Internet: ZmudzinT@CC.IMS.DISA.MIL

Disclaimer: Well, what do you expect from a Global Village Idiot?

------------------------------

Date:    Fri, 22 Jan 93 19:07:05 -0500
From:    Jerry Leichter <leichter@lrw.com>
Subject: Measuring polymorphism

Before defining "polymorphism", I suggest it's important to decide WHY
we want a definition.  What property of "highly polymorphic" viruses
are we trying to capture?  I'll suggest two very different definitions
that illustrate why this is an essential first step.

1.  Polymorphic viruses can appear in many different forms; the more
possible forms, the more polymorphic the virus.

Of course, these allows for trivial polymorphism: Any virus can be
made highly polymorphic by simply appending 16 random bits to it.  So,
we could try saying, well, the virus is K bits long, let's look at the
fraction of all possible K-bit strings that the virus could appear as.
Unfortunately, this fraction can be made to take on any value you like
by adding a lot of random bits, or a lot of fixed but irrelevant bits.

The next step is to ignore the "irrelevent" bits.  For example, define
the kernel of a program to be those bits in the program text which can
actually be executed as code in some execution of the program (for all
possible inputs, such as values of the date/time).  Computing this is
very nontrivial in general, though in most particular cases it's
fairly easy.  If we then measure either the number of bits in the
kernel of a virus, or the density of the kernel among all possible bit
strings of the appropriate length, we will have a measure that at
least says something about the program, rather than about noise.

One interesting property of this definition is that it ignores text
strings, which is probably appropriate.  Then again, if the question
you want your "polymorphism" measure to answer is "In how many
distinct ways can the virus APPEAR to an end user", then every
different set of displayed text strings presents a different
appearance.

2.  The only reason that polymorphism was introduced by virus writers
is to make life hard for virus scanners.  Definition 1 is purely
"intrinsic": It looks at the virus itself, not how it interacts with
scanners.  Suppose we wanted to capture the notion that a virus was
"hard to scan for".  It's easy enough to look at how hard it is for
particular existing scanners to find it, but that gives you a poor
definition; what we really want to capture is the notion that highly
polymorphic viruses make life hard for ANY POSSIBLE scanner.

It turns out there is a notion in the theory of computation which can
be used to get at this idea; in mentioning randomness, Declan Malone
started out on the right path.  Kolmogorov-Chaitin complexity theory
(I'll just call it KC from now on) defines a way to measure the
complexity of a string of symbols.  The idea is really simple: The
complexity (or, equivalently, randomness) is defined as the length of
the shortest program that will produce the particular string as its
output.

In KC theory, we don't care how long the program will take to produce
the output, or how much scratch space it uses; we care only about the
length of the program.  Of course, to have a notion of "length", we
have to settle on a machine model first.  In K-C theory, you choose a
universal Turing machine, and provide it with a program on its input
tape; the length of the machine description is the length of the
program.  While different universal TM's may give you different
lengths, it turns out that this has no significant effect on the
resulting measure, except for a finite number of special cases.  (You
can hard-code some strings into your TM, but only finitely many.)

I suggest that the polymorphism of a virus be similarly measured as
the length of the shortest program (with respect to any fixed
universal TM) which can reliably detect the virus in all its forms,
without error.

As a purely mathematical definition, I think that's what we really
have in mind under the notion of "hard for a scanner to detect".  As a
PRACTICAL measure, however, it's pretty useless.  First of all, it's
impractial to compute it.  Beyond that, "length of program" is not the
only significant measure.  If a short program can detect a virus, but
it requires huge amounts of time to do so, that program will not make
a useful detector.  On the other hand, a quite large, but fast
table-driven program might be very practical.  Or one might want to
relax the requirement of "total correctness" and allow some small
fraction of false positives (or, in some circumstances, even of false
negatives).  Such changes could lead to a very different measure of
the polymorphism of some viruses - though I have no idea whether for
practical polymorphic viruses it would really make much diffference.

BTW, it would be nice if there were KC theory that looked not just at
program length but also, say, at running time.  Unfortunately, if you
add such additional measures, the mathematics of KC theory breaks
down, and the resulting measure is no longer independent of the
details of the model in any useful way.  That doesn't mean that one
can't find a PRACTICAL KC-like measure with respect to some particular
set of models and measures, though.

							-- Jerry

------------------------------

Date:    Fri, 22 Jan 93 21:13:12 -0500
From:    fc@turing.duq.edu (Fred Cohen)
Subject: protecting the checksum file

Bontechev writes:

>> 	I think that an alternative to off-line checksums is access
>> control. This has worked in IT for several years, and defeats all of the
>> other attacks against the crypto-checksum I am aware of. 
>
>I disagree, for several reasons:
> ...
>2) Wasn't it you who has proven that discretionary access controls are
>unable to stop the virus spread, unless they limit the sharing or the
>transitivity of the information flow? They can at most slow down the
>spreading of the virus, or limit to a cluster of users (if POSets are
>implemented)...

	The point I was trying to make is that access controls can stop
the corruption of the checksum file and prevent users from examining or
modifying the integrity key used to generate checksums.  For these
functions, we can isolate the integrity maintenance area, as is done
in IT, without otherwise impacting operations.

>
>3) Access controls do not prevent at least one of the virus attacks
>against integrity checkers I can thin of. They are unable to stop the
>slow viruses. In fact, the first slow virus was developed exactly as
>an attack against monitoring programs and only afterwards it was
>noticed that it is also very effective against integrity checkers...
>

	You are right of course - so against slow viruses, you need
additional defenses.  Specifically, you need to protect the operating
system from participating in the infection - then you can use the
techniques described in the Computers and Security Paper which defined
integrity shells.  Somewhere in there, there was a `one process at a time
assumption' - watch out for it - it's a bit tricky.

... AND on the definition of viruses:
>
>Well, consider the following example:
>
>Program: XCOPY.EXE
>
>Proper environment: 
>	a) MS-DOS computer, which is turned on, contains the file 
>XCOPY.EXE in the current directory on the current drive and has a
>formatted empty diskette in drive A:
>	b) user, typing XCOPY XCOPY.EXE A:
>
>Under this "proper environment" the program XCOPY.EXE always
>reproduces itself. So - is the program XCOPY.EXE a virus in this
>environment?

It is not a virus - because, to be a virus, the replica must also
replicate in the environment - as must it's replicas, etc., ad-infinitum. 
All of the replicas (as described above) are on the `A:' drive.  When
you the run `Xcopy Xcopy.Exe A:' from the A: drive to get the replica to
replicate, I don't think it will work right (i.e.  make an additional
copy at a different place on the A: disk) - although I haven't tested
it.  Furthermore, to call Xcopy a virus in this environment, it must
ONLY be used in this way - the alternative uses mean that it does not
ALWAYS replicate.

	I have no doubt that you can eventually find an environment
where Xcopy is a virus because it has the capability of replication -
given a proper environment.  Consider now the difference between your
example with Xcopy and my example with backups.  Backup programs are
rarely used for more than one function (i.e.  backups - there's usually
a separate program for restores).  The defaults for backups usually
include the backup program in the copy.  Backups done to network drives
are on-line and can be run easily from the backup media.  Backups
typically overwrite previous information as they are created - so they
are dangerous.  Thus, we have a replicating program that has a large
class of available environments in which it operates. 

	Consider this from the standpoint of what we commonly see in
malicious viruses.  Most malicious viruses are written to operate in a
very large portion of the existing environments (e.g.  all DOS machines,
all PC's with similar BIOS's, all MacIntosh's, etc.).  Viruses that only
operate in a limited number of systems are commonly called `buggy' by
the virus defense industry.  The Internet virus was directed to spread
only in a particular subset of the Unix machines it entered.  But
perhaps these viruses are just directed at a finer subset of the
available machines.

	Nowadays, a virus writer may be more successful by writing a
virus that infects fewer machines (particularly types of machines that
the defenders don't have lying around), because fewer defenders will
bother looking for viruses that don't work in their machines.  Imagine a
very well designed slowly mutating virus that doesn't replicate in your
machine until the 100,000the replica.  You will likely not even call it
a virus, and you may not want to bother figuring out how to detect all
of the mutations.  Many people may never bother to scan for it.  Now
suppose it has no obvious side effects for 18 months.  It may spread
throughout the world mutating slowly, and be a pandemic before anyone
ever takes it seriously.

	Now consider how to make safe viruses for benevolent purposes. 
All you have to do is make the environments in which they are viral
suifficiently restricted, and they are no threat to other environments. 
For example, have them replicate with a system call that requires that a
`Viral Computing Environment' be installed.  This is what is done when
we use the computer simulation called Life, or Core War, and this is how
I make most of my benevolent viruses safe.  You don't seem to object to
Dawkins's evolutionary environment that runs on a MacIntosh.  These are
not only viruses, but are intended to explore the nature of evolution in
biological systems.  You wouldn't want them spreading all over the
world, but you should be happy to see them in systems where the user
installs the proper environment.

------------------------------

Date:    Sat, 23 Jan 93 00:08:46 -0500
From:    hutchinson@wrair-emh1.army.mil
Subject: Re: Infection question (was: Viral Based Distribution System)

bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) writes:
> the currently existing types of viruses on the IBM PC. These viruses
> (boot sector infectors, file system infectors, companion viruses) do
> not match even Dr. Cohen's natural-language definition of the term
> "virus", unless you define "program" and "attach" too broadly. And

Then maybe "program" is the wrong word.  Maybe it should be something
like "function" or "process" instead.  F'rinstance, a boot sector
infector doesn't exactly attach itself to any program.  But it *does*
attach itself to the boot *Process*.

> IF you define them broadly enough, a "worm" will fit in the definition
> of the term "virus" too. They are essentially one and the same thing,
> from the mathematical point of view... Nevertheless, for reasons of
> convenience, we prefer to differentiate between them in practice.

I've been thinking about this one lately.  Is there a really good reason
why worms must be considered entirely separate?  I think the distinction
is based not so much on the definition of a virus, but on a popular
notion of what a virus is (or was).  A few years ago the difference was
fairly clear because our notion of a virus was relatively limited.  But
some of these newfangled viruses are changing that notion somewhat.
These days, we speak of, i.e., companion "viruses", even though they are
completely different beasts than the viruses of yore.  Why, then, aren't
worms considered just another type of virus?

  -Hutch

- --------------------------------------
Bob Hutchinson                            
Walter Reed Army Institute of Research
(hutchinson@wrair-emh1.army.mil)

------------------------------

Date:    Sat, 23 Jan 93 00:08:58 -0500
From:    hutchinson@wrair-emh1.army.mil
Subject: Re: on the definition of virus

fc@turing.duq.edu (Fred Cohen) writes:
> 	In a recent virus-l, someone wrote that they liked Alan Solomon's
> redefinition of a `real virus' as `a program that replicates without the
> user's awareness and cooperation' (p602 V11N7 Computers and Security).
> 
> 	There are some minor problems with this definition that I would
> like to point out.
> 
> 1) If a user is aware of the `Brain' virus on a floppy disk, and inserts
> it anyway and boots, it is a virus? According to Solomon's definition it
> is NOT a virus because the person was:
> 
> 	a) aware
> 	b) cooperative
> 
> 	HOWEVER - If another user does exactly the same thing without
> knowing that the disk contains a virus, then it IS a virus!

[Much more deleted than I think I should've had to...]

> 	Maybe Solomon's product is very good - but his definition isn't.

Then allow me to make a minor adjustment: `A program CAPABLE of
replicating without the users awareness and cooperation'.  Would that
sit any better?

    -Hutch

- --------------------------------------
Bob Hutchinson                            
Walter Reed Army Institute of Research
(hutchinson@wrair-emh1.army.mil)

------------------------------

Date:    Thu, 21 Jan 93 12:55:51 +0000
From:    Paul.Gronke@lambada.oit.unc.edu (Paul Gronke)
Subject: Thanks to Symantec (PC)

Just wanted to note that Symantec Tech Support sent me a uuencoded file
with updates to NAV 2.0 virus definitions.  (Thanks to the other user
who sent one along as well).  Thanks for responsive tech support, Symantec.
- --
   The opinions expressed are not necessarily those of the University of
     North Carolina at Chapel Hill, the Campus Office for Information
        Technology, or the Experimental Bulletin Board Service.
           internet:  laUNChpad.unc.edu or 152.2.22.80

------------------------------

Date:    Thu, 21 Jan 93 13:46:43 +0000
From:    gerald@vmars.tuwien.ac.at (Gerald Pfeifer (Prak Gusti))
Subject: False Alarms (was: Cansu...) (PC)

ianst@qdpii.comp.qdpi.oz.au (Ian Staples) writes:

>Does anyone *know* how this virus works?  If you simply read the
>directory of an infected floppy and then run McAfee's SCAN (version
>99), you will get a warning "Virus active in memory" - which sure
>scares folk!  

Well, both McAfee Scan (99) and Frisk's F-Prot (2.06 or 2.06a) suffer
from this problem, while TBAV (TBScan 5.0x) does not.

REASON: If you issue a DIR for a floppy disk, that floppy's boot sector 
- -in this case containing a virus- is read into one of DOS' (sector) buffers.
These buffers reside in memory, scanners scan memory -> False Alert.

SOLUTION: Please McAfee, Frisk,... scan these buffers only for viruses 
known to install themselves there (when active!)! 

Hope I put it right, no flaming please!

Gerald

PS: F-Prot's warning message, however, is less scaring and per se correct,
    as it just says "signature of ... found in memory" (or similar), not 
    "Virus active in memory".
    But it does also say "power down" (or similar) what is of no use
    in this case!

............................................................................
. Gerald Pfeifer (Jerry)              Technical University Vienna, Austria .
. gerald@kongo.vmars.tuwien.ac.at     Home: Mondweg 64, 1140 Wien, Austria .
............................................................................
. Sorry, I'm not a native speaker (flames to /dev/null)                    .
............................................................................

------------------------------

Date:    21 Jan 93 18:24:30 +0000
From:    leoh@hardy.hdw.csd.harris.com (Leo Hinds)
Subject: Any know virus/trojan with the following results? (PC)

I have 3 PC's (two at home & 1 at work) and all three have developed
similar symptoms & I was wondering if it was a coincidence or the act
of some malignant code:

Power on - (use vshield 99) nothing reported 
Access floppy a couple of times - no problem
access floppy (either drive) with something like xcopy that re-reads multiple 
	times to read all the data & the initial access is fine, but when it 
	comes back for the second time, it complains that there is no floppy 
	in the drive.
On one machine the floppy is accessible via DOS, but windows believes there 
	is no disk in the drive.

Any thoughts?

- -- 
leoh@hdw.csd.harris.com         	Leo Hinds       	(305)973-5229
Gfx ... gfx ... :-) whfg orpnhfr V "ebg"grq zl fvtangher svyr lbh guvax V nz n
creireg ?!!!!!!? ... znlor arkg gvzr

------------------------------

Date:    Thu, 21 Jan 93 18:36:52 +0100
From:    brunnstein@rz.informatik.uni-hamburg.dbp.de
Subject: V-Sign on printer diskettes (PC)

Shortly before Christmas, Virus Test Center of Hamburg University and
MicroBIT Virus Center of Karlsruhe Technical University were asked to
assist in the analysis of 4 diskettes (out of 6) which FUJITSU Germany
distributed to customers with boot sectors infected with V-Sign virus
(called CANSU by McAfee's SCAN).

It was verified that 4 diskettes were infected with V-Sign which is
"mildly polymorphic": the "oligomorphic" part is 38 bytes long, with 3
MOV instructions being circularly rotated and 2 other instructions
interchanged, thus resulting in n=6 different generations. Depending
on some mask (value=1F implying 32 repetitions, value=3F implying 64
repetitions), "Victory" sign will appear on the screen (for details:
see Computer Virus Catalog entry in next CVC edition). While the first
3 diskettes were infected on an English MSDOS 3.3 system, the 4th
diskette was infected on some German MSDOS 5.00 system.  The diskettes
were infected while in drive B:.

Fortunately, there is a bug in the virus. Due to this bug, all
diskettes infected in drive B: are trying to load the second part of
the virus body from that drive. Therefore, the only way to become
infected by such a diskette is to have two infected diskettes WITH THE
SAME DENSITY in both drives A: and B: and accidentally try to boot the
computer. If there is no other infected diskette in drive B: (or if it
is not the same kind of diskette), the virus will hang the machine,
without infecting the hard disk. All the 4 infected diskettes
distributed by Fujitsu have been infected in drive B:...

Following strong "suggestions" of the German Information Security
Agency, GISA, Fujitsu warned its customers, and it sent a press
release to some media.  This press release was prepared by some
marketing people who said that "the virus which sits of these
diskettes and which can only be detected with the most recent
antivirus programs, was inactivated with expensive security methods":
this is the first bug which I have seen cited as "security method"!

Klaus Brunnstein (VTC, Univ Hamburg, January 11, 1993)

------------------------------

Date:    Wed, 20 Jan 93 20:38:33 -0500
From:    as194@cleveland.Freenet.Edu (Doren Rosenthal)
Subject: Re: Virus Simulator MtE (PC) 

     E-mail as@cleveland.freenet.edu (Doren Rosenthal)
 
     Doren Rosenthal                   voice Phone 1 805 541-0910  
     Rosenthal Engineering
     3737 Sequoia   
     San Luis Obispo, CA USA 93401
 
     A  new Virus Simulator supplement, to be used as a  training 
     aid  that  enables users to better  understand  and  protect 
     themselves   from  computer  viruses,  is  currently   under 
     development.
 
     This  new Virus Simulator supplement is expected to  receive 
     wide  distribution  in government,  business,  industry  and 
     education. 
 
     Producers  of anti-virus products, publications or  services 
     are   encouraged   to  please  contact  me.   Comments   and 
     constructive criticism would be greatly appreciated. 
 
     Thank you
 
     Doren Rosenthal

------------------------------

Date:    Thu, 21 Jan 93 19:36:29 +0000
From:    mark@walt.CS.MsState.Edu (Mark Rauschkolb)
Subject: 696 Virus? (PC)

A co-worker just told me that his home machine is heavily infected by
the 696 virus (according to McAfee SCAN).  I looked for 696 in the
VSUM "program" but could not find it.

He said that when he ran clean on his PC, it ran for a while, then
told him to turn off the system.  (He didn't know if it gave a reason
why, he just turned it off and left it off)

Any hints?

Thanks

Mark Rauschkolb
mark@cs.msstate.edu

------------------------------

Date:    22 Jan 93 04:10:43 +0000
From:    j.laidman@cowan.edu.au (Jeremy Laidman)
Subject: Possible new virus: Dudley! (PC)

We've been given an infected program from an infected site.  Scan v99
and F-Prot v2.06a miss the virus.  This virus infects COM and EXE
programs differently each time, with a file size increase of around
1200 bytes.  The first three hundred bytes of the loader code decrypt
the code following, for a count of 481h bytes.

In the decoded virus one can see the string "<[Oi Dudley!][PuKE]>"
which can be used to find it in memory.  McAfee's scan can be given
the following signatures to find it:
	
# Dudley string: <[Oi Dudley!][PuKE]>
"3C 5B 4F 69 20 44 75 64 6C 65 79 21 5D 5B 50 75 4B 45 5D 3E" Dudley-Unencrypte
d
# Encrypted Dudley - decryption code
"B9 81 04 *(30) 31 *(30) FE C0 *(30) FE CC *(20) E2" Dudley-Encrypted

The virus hooks INT 21h, checking for functions 5454 (for self
detection), 4B00, 3D, 56 and 6C (all hex).

After the first infected program is executed, the virus decreases the
size of the free memory block by 1200h bytes (exactly), where it puts
itself (in the last 1200h bytes of 640k).  It attempts to infect
COMSPEC, whatever it points to.  From here, it infects every program
that is executed or copied.

To avoid signature detection the decryption code is sprinkled
liberally with various code sequences that effectively do nothing,
such as JO $+2.

If this is a new virus, I'd be grateful to find out who's being
infected.

Cheers
- ---------------------------------------------------------------------
Jeremy Laidman, Analyst Programmer
School of I.T. and Mathematics                 Phone: (61 9) 370 6648
Edith Cowan University                         Fax:   (61 9) 370 2910
Perth, Western Australia                       j.laidman@cowan.edu.au

------------------------------

Date:    Fri, 22 Jan 93 02:35:12 -0500
From:    "Roger Riordan" <riordan@tmxmelb.mhs.oz.au>
Subject: Stoned_NSW; New boot sector virus (PC)

We have just received samples of a new boot sector virus from two
sites in NSW.  The virus itself is very unremarkable; it has no
messages, and no warhead.  However it is likely to cause considerable
alarm, as it is identified by Scan 8.9V97 as "ExeBug".

ExeBug rewrites the CMOS RAM, with the intention of preventing you
from booting from a clean disk, and may be able to achieve this on
some PCs.  Thus it is potentially very serious, and it is unfortunate
that this relatively trivial virus is identified as it.

F-Prot 2.06a reports "Possibly a new varient of Stoned"  

Dr. Solomon's Toolkit 6.07 (19/11/92) does not find it.

Unlike Stoned, the virus starts with a relative jump.  The MBR is
saved at sect 7, and floppy boot sectors are saved at head 1, sect 3
or 14, depending on size.  It is stealth, and will divert any attempt
to read or write the boot sector to the good copy.

The virus can be found with the signature:

A1 13 04 B1 06 48 A3 13 04 D3 E0 8E C0 A3 86 7C at offset 5B in the 
boot sector.

We have tentatively named this virus Stoned_NSW.  VET 7.114, released
today, will detect it in memory and disable it, and will remove it
from infected floppies & hard disks.

Roger Riordan                 Author of the VET Anti-Viral Software.
riordan.cybec@tmxmelb.mhs.oz.au

CYBEC Pty Ltd.                                 Tel: +613 521 0655
PO Box 205, Hampton Vic 3188   AUSTRALIA       Fax: +613 521 0727

------------------------------

Date:    Fri, 22 Jan 93 16:40:10 -0500
From:    padgett@tccslr.dnet.mmc.com (A. Padgett Peterson)
Subject: False positives, disk buffers, and IO.SYS (PC)

>From:    ianst@qdpii.comp.qdpi.oz.au (Ian Staples)

>Subject: Cansu virus plague! (PC)

>An  outbreak of the Cansu virus (boot sector) was discovered  at 
>one  of  this organisation's centres today.  It  apparently  had 
>been around for awhile and was really only discovered because it 
>(or  something else, fortuitously?) was interfering with  32-bit 
>disk access under Windows 3.1 on one machine.  

32BitDiskAccess  does  provide a good warning  of  *any*  program 
which  is  intercepting disk access at the BIOS  level  (viruses, 
access control  programs, disk compression routines). The  reason 
is that MS-DOS at present requires the PC to be in "real" mode to 
be  used  for disk access. Since switching  from  "protected"  to 
"real" and back is a time consuming process, Windows 3.1 gains  a 
significant  improvement to its speed (or reduction of  the  lack 
thereof)  by  using its own "protected" mode  routine  (32Bit...) 
when  possible.  To do so, Windows makes a number  of  checks  to  
determine  exactly  what the disk access method is  and  posts  a 
warning   when  confused.  Since  the  default  installation   is 
"32BitDiskAccess=FALSE", few people have encountered this.

>Does anyone *know* how this virus works?  If you simply read the 
>directory  of  an  infected floppy and then  run  McAfee's  SCAN 
>(version 99), you will get a warning "Virus active in memory"  - 
>which sure scares folk!  

I have been running some tests on this effect and there seems  to 
be   certain criteria: When DOS 5.0 accesses a disk,  two  things 
happen: 

1) The  Boot Record (logical sector 0 of the partition or floppy) 
     is  read  into  memory at a location  contained  within  the 
     resident  portion of IO.SYS (IBMIO.COM) in segment 0.  Since 
     this  is  overwritten every time a disk is  changed  current 
     viruses cannot use this space for residency. However, if the 
     disk  had an infected boot record, this code is now  in  the 
     this buffer.

2)  On access, the root directory is read into the disk  buffers. 
     How many sectors are read seems to depend at least partially 
     on how many buffers DOS has allocated. 

     If DOS 5.0 is loaded "high" one of the things that DOS tries 
     to put in the High Memory Area (segment FFFF)  are  the disk 
     buffers.

Note that this only happens if *DOS* accesses a disk (e.g. with a 
DIR)  just changing the default does not seem to trigger a  read. 
Further,  if  the  disk  is  read  by  some  other  driver  (Disk 
compression  routine e.g. SuperStor, removable media driver  such 
as for a Bernoulli, DMDRIVER) then the last DOS access remains in 
the buffer. (This caused me some confusion at the beginning since 
my  test  machine has SuperStor partitions and  I  only  observed 
floppy DBRs in the buffer despite intervening C: & D: access).

I have run some tests using SCAN (v95 and v100) and F-Prot  (2.05 
and  2.06a)  and in each case if a DIR was done  of  an  infected 
(STONED)  floppy prior to scanning, a positive indication of  the 
"virus in memory" was generated. If a DIR was done on a clean DOS 
partition thereafter (without reboot) memory came up clean.

Next  I  tried  the following: did a DIR on an  infected  disk  - 
infection  warning was generated. Used debug to clear the  IO.SYS 
buffer  in  memory (again without reboot) -  scans  now  reported 
system OK. This was proof to me as to what was being detected.

In no case was there any indication that the signature was  found 
in  low  memory  (segment 0000, first 64k)  rather  each  scanner 
finished its examination of memory and then reported the virus. 

For  some  time  we  have been  thinking  that  somehow  a  virus 
signature was being introduced into the disk buffers but the lack 
of repeatability caused much confusion. In no case in my  testing 
did  I  ever  find  a DBR in the  buffers,  only  root  directory 
entries.  However in every case following floppy disk  access  as 
described above, the DBR was found in the IO buffer in segment 0.

Just as a suggestion to a-v developers: since I have not observed 
any ill effects from clearing this buffer other that a reload  on 
the next floppy access and it is a source of false positives, why 
not just clear the buffer before starting a memory scan ?


					Warmly,

						Padgett


------------------------------

End of VIRUS-L Digest [Volume 6 Issue 13]
*****************************************
