Received: from fidoii.CC.Lehigh.EDU by abacus.hgs.se (5.65c/1.5)
	id AA13970; Wed, 27 Jan 1993 21:38:45 +0100
Received: from  (localhost) by Fidoii.CC.Lehigh.EDU with SMTP id AA22761
  (5.67a/IDA-1.5 for <mikael@abacus.hgs.se>); Wed, 27 Jan 1993 15:26:34 -0500
Date: Wed, 27 Jan 1993 15:26:34 -0500
Message-Id: <9301271940.AA16908@barnabas.cert.org>
Comment: Virus Discussion List
Originator: virus-l@lehigh.edu
Errors-To: krvw@cert.org
Reply-To: <virus-l@lehigh.edu>
Sender: virus-l@lehigh.edu
Version: 5.5 -- Copyright (c) 1991/92, Anastasios Kotsikonas
From: "Kenneth R. van Wyk" <krvw@cert.org>
To: Multiple recipients of list <virus-l@lehigh.edu>
Subject: VIRUS-L Digest V6 #11
Status: RO

VIRUS-L Digest   Wednesday, 27 Jan 1993    Volume 6 : Issue 11

Today's Topics:

Re: Yes, but is it a virus?
Re: Export restrictions of anti-virus software?
Re: On the definition of viruses
Re: January LAT
Good and bad viruses (was FC on virus creation)
Re: os2-stuff (OS/2)
DOS Viruses under HPFS (OS/2)
Re: PKZIP V2.04C (PC)
Re: Vshield vs Virstop (PC)
Re: Wanted: info about Dos 5.0 virus (1578?) (PC)
windows virus (PC)
Re: Monkey [Mon] and Multi-2 [M12] viruses (PC)
Cansu virus plague revisited (PC)
Re: Known virus that tweaks PC date function? (PC)
Re: Vshield vs Virstop (PC)
Re: Untouchable (PC)
Re: Untouchable (PC)
new PKZIP problems? (PC)
New Virus (PC)
Internet Worm - Media (CVP)

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:    Fri, 15 Jan 93 16:37:27 -0700
From:    martin@cs.ualberta.ca (Tim Martin; FSO; Soil Sciences)
Subject: Re: Yes, but is it a virus?

ygoland@edison.SEAS.UCLA.EDU (The Jester) writes:

>If Dr. Cohen is speaking of viruses to other experts in the field
>then his comments regarding Beneficial Viruses and such are
>appropriate and will be understood. I doubt anyone who understands
>his comments would disagree with his assertions.

The interesting point that Dr. Cohen made, though, in his first (?)
article, was that it is precisely those one would expect to understand,
the academics and the anti-virus software writers, who get most
upset with his definitions.  According to Dr. Cohen, his customers,
who are non-experts, are not bothered about whether his protection
software is using viral techniques to install itself on their systems,
as long as the installation works efficiently.

I call this the interesting point because I think (as an academic)
that it is an interesting commentary on the nature of academia
today.

Tim

 -------------------------------------------------------------
  Tim Martin                   *
  Spatial Information Systems  *   These opinions are my own:
  University of Alberta        *      My employer has none!
  martin@cs.ualberta.ca        *
 -------------------------------------------------------------


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

Date:    Fri, 15 Jan 93 17:20:52 -0700
From:    martin@cs.ualberta.ca (Tim Martin; FSO; Soil Sciences)
Subject: Re: Export restrictions of anti-virus software?

>From postings by Vesselin, Aryeh, and Frisk, I am informed 
that it would be against Canadian Law for me to "export" anti-
virus "shareware".

The Monkey virus, which originated in Canada, has been found in 
the US and in England.  The Killmonk program, an embarassingly
simple little snippet of code, also written in Canada (I haven't
been out of the country for months, something we Edmontonians notice
mid-winter), is one of few "convenient" ways of removing the Monkey
virus from a hard disk.  Killmonk is "freeware".  The entertaining
question of my week is "Am I breaking my country's Law by 
distributing Killmonk to persons and ftp sites outside Canada, 
to help them get rid of a virus that exported itself to them
from Canada?"   :)

Nothing like a little legal mirth to warm the winter spirit.

Tim.

 -------------------------------------------------------------
  Tim Martin                   *
  Spatial Information Systems  *   These opinions are my own:
  University of Alberta        *      My employer has none!
  martin@cs.ualberta.ca        *
 -------------------------------------------------------------


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

Date:    Mon, 18 Jan 93 10:06:10 -0500
From:    Y. Radai <RADAI@vms.huji.ac.il>
Subject: Re: On the definition of viruses

  Albert Lunde writes:
> Fred Cohen can point with justified pride to the mathematical theory
> of viruses.  At the same time, I think it is perfectly understandable
> that people will use more relative, subjective critera based on a
> perception of risk and intention. This is especially the case since
> one of the consequences of the mathematical theory is a proof that a
> general "unknown virus" detector is impossible!

You don't need Fred's mathematical theory to show that.  It's also a
consequence of any reasonable informal (natural-language) definition
of "virus", as Fred himself has shown.  Since his informal proof has
been presented on Virus-L/comp.virus at least five times, I won't
bother restating it here.  However, I'd like to present an argument
which I thought of a couple of years ago, which demonstrates (at least
for all practical purposes) the undecidability of whether a given
program contains a virus, in a completely different way from Fred's
proof (the one based on the proof of the undecidability of the Halting
Problem on a Turing Machine), a way which seems to me far more intui-
tive, even if it's not quite as conclusive.
  Suppose a program contains code for replication, but only within a
statement of the form "If <condition> then <replicate>", where
<condition> is something which depends on the run-time environment,
e.g. on the input which a user supplies.  Can a detection program
discover whether the program actually does replicate?
  To illustrate the generality of the situation, I'll even offer a
choice between three reasonable informal definitions of "virus":
(a) a virus is a sequence of instructions which replicates on *every*
    execution;
(b) a virus is a sequence of instructions which replicates on *at
    least one* execution;
(c) A sequence of instructions is a virus in a given run-time environ-
    ment if and only if it replicates in that environment.
  If the decision is to be made by appearance of the program alone,
then the simplest case is (c), for suppose that the program asks the
user to supply two numbers, x and y, and <condition> is "x < y".  Then
it is completely obvious that fulfillment of this condition cannot be
determined without actually running the program, hence whether the
program is a virus is undecidable by appearance of the program alone.
Note that this argument does not require the assumption that the
computer has an infinite amount of storage, as Fred's proof does.
  If the definition is (a) or (b), then we can do even better: we can
show that in some cases the question cannot be decided even by running
the program any finite number of times.  For example, suppose the
program asks the user to input four positive integers i, j, k, n
(where n must be > 2).  If you choose definition (b), I shall take
<condition> to be "i^n + j^n = k^n".
  Now for all anyone knows, it may be that this condition is *never*
actually satisfied.  (The statement that there are no such integers is
Fermat's "Last Theorem", for which he *claimed* he had found a proof,
but he didn't produce it and no mathematician since him has found
either a proof or a counter example.)  Not only can we not decide this
by appearance of the program, but even if we run this program a zil-
lion times and the program doesn't replicate, that doesn't prove that
it can *never* replicate; all one can say is that the program hasn't
replicated *so far*.
  If you choose definition (a) instead, I take <condition> to be the
negation of the above statement, and the same argument works.
  In any case, there are some situations in which you can't decide
whether a given program is a virus.  We can substitute for Fermat's
Theorem any other unsolved problem.  If you could write a program
which could decide whether the resulting programs are viruses, then
you would become famous for having solved all the world's heretofore
unsolved problems!!  (Well, at least those which can be expressed by a
computer program.)  Thus it is intuitively clear that the property of
virality is undecidable, at least for all practical purposes.
  Of course, one can take the position that it's just an historical
accident that these problems have not yet been solved, and that in
principle they may all be solved some day.  However, it can be shown
that there are infinitely many problems which can *never* be solved
(although that apparently requires use of one of those "paradoxical"-
type proofs which I've been trying to avoid here).
  Comments are welcome (especially Fred's).

                                     Y. Radai
                                     Hebrew Univ. of Jerusalem, Israel
                                     RADAI@HUJIVMS.BITNET
                                     RADAI@VMS.HUJI.AC.IL

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

Date:    Mon, 18 Jan 93 11:31:17 -0500
From:    Y. Radai <RADAI@vms.huji.ac.il>
Subject: Re: January LAT

  Bill Lambdin writes:

> I had hoped to test Search & Destroy From Fifth Generation
> Systems, but I haven't received it yet.

My understanding is that Search & Destroy is the same as UTScan + UTRes.
(Fifth Generation's answer to those who want a scanner without an integrity
checker.)

                                     Y. Radai
                                     Hebrew Univ. of Jerusalem, Israel
                                     RADAI@HUJIVMS.BITNET
                                     RADAI@VMS.HUJI.AC.IL


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

Date:    Sun, 17 Jan 93 12:12:00 +0000
From:    Amir_Netiv@f120.n9721.z9.virnet.bad.se (Amir Netiv)
Subject: Good and bad viruses (was FC on virus creation)

 Y. Radai writes in response to Suzana:

 > But it doesn't *have to* become a bad virus.  And if
 > it does become one, then by most people's definitions it probably
 > wasn't really a good virus to begin with.

I think the dabate concerning "goodness" of viruses, has gone out of
hand here... The question should not be if a virus is good or bad
according to our benefit (or losts) caused by it, but: does it's
behaviour and method of propagation comply with certain rules that
will make it hard to detect/clean/ prevent!

For example we concider a good virus as one that:
  - Does not reveal itself "easally" :-).
  - Uses "different" (unusual) stealth techniques.
  - Uses a special (prferably "new") method of hooking a program
(think about DIR-II). etc...

Most of the terms here can be subject to many intensive
philosophical dicussions.

So to my openion the question shold be: What are the rules ?

Regards

* Amir Netiv, V-CARE Anti-Virus, Head team.

- --- FastEcho 1.21
 * Origin: <<< NSE Software >>> Israel (9:9721/120)

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

Date:    15 Jan 93 06:04:18 +0000
From:    bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
Subject: Re: os2-stuff (OS/2)

chess@watson.ibm.com (David M. Chess) writes:

> >could infect them by mistake. How are the DLL and DRV files loaded in
> >OS/2? If they are not loaded using any INT 21h/AX=4Bxxh function, then
> >it is rather unlikely that any of the currently known viruses will
> >infect them...

> No, no OS/2 call does an INT 21 at all; that's one of the main
> reasons that no DOS virus runs in native OS/2.  Operating system
> calls in OS/2 are done using Protect Mode constructs like call
> gates (I forget the details again!), not using INTs.       DC

OK, but suppose that the user opens a DOS window. Suppose also that
s/he runs an infected DOS program in this window and the virus becomes
resident. Does OS/2 access some DLLs in order to handle the running of
a DOS program in a DOS window? Are those accesses visible to the
program running in the DOS window? If they are not, then none of the
currently existing viruses will infect a DLL file and there is no need
to scan such files...

Another possibility is a virus like Frodo, which (erroneously)
infects files with different extensions, because it thinks they are
COM or EXE. But Frodo's criteria for executable extension does not
classify "DLL" as such and I don't know other viruses which do the
same stupidity...

So, it seems that there is indeed no need to scan the DLL files,
right? Or am I missing something?

Regards,
Vesselin
- -- 
Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
Tel.:+49-40-54715-224, Fax: +49-40-54715-226      Fachbereich Informatik - AGN
< PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: bontchev@fbihh.informatik.uni-hamburg.de    D-2000 Hamburg 54, Germany

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

Date:    15 Jan 93 23:27:00 +0000
From:    bill.lambdin%acc1bbs@ssr.com (Bill Lambdin)
Subject: DOS Viruses under HPFS (OS/2)

Quoting from Chris Antkow to All About DOS Viruses under HPFS (O on 
01-15-93

CA>  Being a virus researcher myself, I find it sometimes suicidal to tes
CA> out and disassemble new stealth and polymorphic class viruses on my
CA> DOS based PC. I'm deathly paranoid that it's going to escape on one o
CA> my floppies and infect the rest of my house... Even though I know my
CA> ASM a bit better than the average Joe, who knows what might happen.

When I test viruses, I configure my CMOS to deactivate the hard drive, 
then I cold boot the computer from a write protected bootable diskette. 
Re-activate the hard drive.

Later i hope to get a laptop for research purposes. You might want to 
think of a dedicated virus test machine yourself.
 
Bill

- ---
 * WinQwk 2.0 a#383 * Hacked version of AutoMenu. 4.8
                                                                               
------------------------------

Date:    15 Jan 93 06:11:58 +0000
From:    bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
Subject: Re: PKZIP V2.04C (PC)

btf57346@uxa.cso.uiuc.edu (Byron "Bohr" Faber) writes:

> Just a note: With all the talk going around that pkzip204c is NOT
> infected with a virus, I'm not suprised somebody has really infected a
> copy and uped it.

Why? Most people -still- think that it is infected. Others have at
least heard the rumours and will be cautious...

> You might be able to fool a few to many people.  I think that the "anti-
> virus" community should be carefull of what they are telling people.

Well, we, the anti-virus people -are- careful. Unlike PKWare, who only
posted the size and the date of the file (something easily forgeable),
in my report I posted VALIDATE checksums of the file that I verified
to be virus-free. OK, it is possible to forge them too, but it
requires much more effort... Nevertheless, if somebody still does not
feel secure enough, I can post a MD5 digest of the archive that I
verified to be virus-free.

Besides, the new PKZIP/PKUNZIP is so horribly buggy, that I wouldn't
advise anybody to use it - data loss may occur and much more likely to
bugs than to a virus... :-)

Regards,
Vesselin
- -- 
Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
Tel.:+49-40-54715-224, Fax: +49-40-54715-226      Fachbereich Informatik - AGN
< PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: bontchev@fbihh.informatik.uni-hamburg.de    D-2000 Hamburg 54, Germany

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

Date:    15 Jan 93 06:23:44 +0000
From:    bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
Subject: Re: Vshield vs Virstop (PC)

ST29701@vm.cc.latech.edu writes:

> VSHIELD with the /CF option to check for a file validation information
> will not catch a file infecting virus like INTRUDER (very generic)
> untill after it has infected.  I would have hoped it could catch it
> while the infection was trying to occure.

Well, the /CF switch instructs VShield to use checksums of the
protected programs, stored in a separate file. This means that in this
particular case, VShield acts as a resident integrity checker. All
integrity checkers detect modifications, not viruses. Next, they can
detect the modifications only AFTER the modifications occur. Thus,
VShield with the /CF option will catch an unknown virus only after
this virus infects a protected file (i.e., causes a modification) and
you try to execute it (because VShield performs its checks on program
execution). There is no way an integrity checker can detect a virus
before any modification occurs...

Of course, it remains unanswered why the -scanner- component of
VShield does not detect the virus - at least SCAN 99 -is- able to
detect Intruder (although it reports it as two viruses - Sick [Sck]
and Intrud-B [Intr])...

Regards,
Vesselin
- -- 
Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
Tel.:+49-40-54715-224, Fax: +49-40-54715-226      Fachbereich Informatik - AGN
< PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: bontchev@fbihh.informatik.uni-hamburg.de    D-2000 Hamburg 54, Germany

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

Date:    15 Jan 93 06:34:02 +0000
From:    bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
Subject: Re: Wanted: info about Dos 5.0 virus (1578?) (PC)

lvandyke@balboa.eng.uci.edu (Lee Van Dyke) writes:

> I have just been informed of a virus in command.com (47,845 4-9-91) of
> Dos 5.0. Can anyone give me info on this?

Please, check you source of information, before spreading rumors like
that... We had enough of PKZ204C and definitively to not need the same
story repeated for DOS. Also, please read the FAQ, question F4, in
order to learn how to report suspected virus infections.

In your particular case:

1) Where do you have this information form? The local pirate BBS, an
unmoderated newsgroup, a friend, a newspaper, a computer magazine,
Microsoft's tech support?

2) What does the information say exactly? If it says nothing more that
COMMAND.COM in DOS 5.0 is rumored to contain a virus, then you can
safely ignore it. Rumors like that appear with every new DOS version.

3) What -facts- support the claim that there is a virus? Does any
scanner report it? Does it replicate?

4) Does your information source report a virus infection of a
particular site, of the system diskettes distributed by a particular
OEM vendor, of the diskettes distributed by Microsoft?

5) If there has been an official report about an infection from the
supplier, for which geographical area does it apply? The net
distributed your message all over the world.

6) At last, -which- DOS? MS-DOS, produced by Microsoft, or PC-DOS,
produced by IBM?

All in all, your message is either based on some local infection, or
(more likely) is just a rumor. Until it is confirmed (and I doubt that
it will ever be), just ignore it.

Regards,
Vesselin
- -- 
Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
Tel.:+49-40-54715-224, Fax: +49-40-54715-226      Fachbereich Informatik - AGN
< PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: bontchev@fbihh.informatik.uni-hamburg.de    D-2000 Hamburg 54, Germany

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

Date:    Fri, 15 Jan 93 11:50:14 -0500
From:    S.M.Baines@sheffield.ac.uk
Subject: windows virus (PC)

I am sorry to be a nuisance, but several users of Windows at Sheffield
appear to have been hit by a virus that isn't detected directly. Using
memory resident virus checkers only detect a write to a protected file
or disc, but not the name. Scanning the disc and memory also fails to
show up the 'virus'. It appears only to infect the Windows files, and
these fail to run. It has been caught trying to write to the kernel of
windows, and has also written to other windows programs. As this has
occured to 2 different users, not using the same computers, or
software to get the same fault within 2 days of each other seems very
odd. In both cases the only solution was to reinstall windows and all
other software (including non-windows software) and hope the problem
has gone away. The common link between the two was use of HENSA to
download software at terminals at the University of Sheffield. Has
this 'virus', if it is a virus, been reported before or is it just a
bug and an unhappy co-incidence?

Once again I appologise for disturbing you, but hope that someone can
shed some light on the problem, in the mean-time we are avoiding down-
loading files.

Stephen Baines
s.m.baines@howden.sheffield.ac.uk

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

Date:    Fri, 15 Jan 93 16:18:38 -0700
From:    martin@cs.ualberta.ca (Tim Martin; FSO; Soil Sciences)
Subject: Re: Monkey [Mon] and Multi-2 [M12] viruses (PC)

LIBBIE@pucc.PRINCETON.EDU (Libbie Counselman) writes:

>We have been using and supporting F-Prot 2.06a on campus, but have
>discovered 2 viruses that are not detected and not disinfected by
>F-Prot.

>The first one discovered was the Monkey [Mon] virus.  It affects the
>File Allocation Table.  SCAN discovers it, but does not disinfect, but
>Norton Disk Doctor will recover the clean FAT.

I've posted a lot of notes in the past, about Monkey, so you may
want to check the archives.  Monkey doesn't infect the FAT; nothing
does.  It infects the main boot record (MBR) of a hard disk, and
the boot sector of a floppy.  The main twists Monkey has that make
it different from Stoned are that 1. it doesn't keep the partition
table in place in the MBR, and 2. it encodes the MBR before it hides
it (in this case in sector 3 on the hard disk.)  Because the partition
table isn't in place, when you boot from a floppy you can't see the
hard drive partitions, so any attempt to change to drive C: for 
example results in a "invalid drive specification" error.  Because 
the MBR is encoded before it is hidden, general scanner/disinfector
packages can't find the proper partition table values to recover the
MBR properly. F-prot will find it on floppies, and call it "a new
variant of stoned", but will not clean it. 

It has other twists, such as stealth, as well. 

I would like to know what you mean when you say that Norton Disk Doctor
will recover the clean FAT.  The FAT was clean all along.  The problem
is not to recover the FAT but to find appropriate values for the 
partition table.  If NDD manages to do this, from a Monkey-infected
hard disk, I am impressed.  Actually one can take advantage of Monkey's
stealth to get the proper partition table values.  If you know a hard
disk is infected with Monkey, you can boot the computer from the 
hard disk, so the virus is active, and use Norton Utilities or some
such to see what the proper partition table values are.  While the
virus is active, a request to read the MBR sector (sector 1 of side 0,
cylinder 0) will return the MBR (sector 3), properly decoded, instead
of the virus sector.  Copy down the proper table values, reboot from
a clean floppy, use fdisk /mbr (with DOS 5.0) to reinstall the 
MBR executable code portion, and use Norton Utilities or whatever
to type in the correct partition table data.

>The second is known as Multi-2 [M12].  It has a predecessor called
>Multi [M-123], also not recognized by F-Prot.  This one infects .COM
>files, .EXE files, overlays and becomes memory resident.  CLEAN
>apparently disinfects it.

I don't know this one.

>Does anyone know any non-commercial packages (i.e. shareware or freeware)
>that can combat these viruses?

I have written a program called Killmonk that should get rid
of the Monkey virus.  Killmonk is at several of the ftp
sites, but let me know if you can't find it.

Tim.

 -------------------------------------------------------------
  Tim Martin                   *
  Spatial Information Systems  *   These opinions are my own:
  University of Alberta        *      My employer has none!
  martin@cs.ualberta.ca        *
 -------------------------------------------------------------


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

Date:    Sat, 16 Jan 93 11:37:36 +0000
From:    ianst@qdpii.comp.qdpi.oz.au (Ian Staples)
Subject: Cansu virus plague revisited (PC)

Further to my earlier post on this recent outbreak, a couple of other
questions have arisen:

When using CLEAN (v.99) to remove the Cansu virus from floppies things
normally work as you would expect.  BUT, every now and then a disk bobs
up (only with 5 1/4" in our experience) which CLEAN thinks it can't cure.

The message is something along the lines of "Cansu virus detected in
boot sector, can not be safely removed."

What gives?  Why do some (most) work okay but some don't?  Furthermore,
once this message appears CLEAN then thinks it can detect the virus in the
memory of the PC ("Warning: Virus active in memory.  Power down...etc.").

This seems to be the same "problem" that occurs with reading the directory
of an infected disk or with using SCAN (v.99) on an infected disk - the 
virus, or at least it's signature - is left in memory and the subsequent
CLEAN operation aborts as a result.

Incidentally, CLEAN also has a somewhat confusing message when it is being
run with the /MANY option.  If the virus is detected and removed on a floppy
and the next disk is in fact okay, CLEAN will give a message that it has
found one virus but that there is no virus on the new disk.  We eventually
worked out that it is probably just giving a cumulative count of what it
has found as you feed disks through the drive.  BUT, the first time you
see the message in an atmosphere charged with suspicion, concern, and
a great deal of ignorance, it is pretty bloody confusing!  I think McAfee
could do a bit better than that.

Any comments from people who know out there?


- -- 
Ian Staples                       | Internet : ianst@qdpii.comp.qdpi.oz.au
c/- P.O. Box 1054,                | Fax      : +61 (0)70 923 593
MAREEBA  Queensland  4880         | Voice    : +61 (0)70 921 555
Australia.                        | Home     : +61 (0)70 924 847

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

Date:    15 Jan 93 14:01:00 +0000
From:    pcb!amyleigh.clarke@batpad.lgb.ca.us
Subject: Re: Known virus that tweaks PC date function? (PC)

AMN@vms.brighton.ac.uk(Anthony Naggs) writes:

   >student, <vpcsc11@sfsuvax1.sfsu.edu> asks:
   >In the office where I work, we recently purchased a 286 clone..  
   >Over the past few weeks, the computer's internal clock has been losing
   > days.  [...]
   >
   > Has anyone heard of a virus that would produce these symptoms?  If
   > not, does anyone have any other ideas about how to fix the problem?

AN>
AN>I don't remember any viruses like that, the only time I've seen
AN>anything similar was on a 'true blue' IBM AT which needed a new
AN>battery for the clock.  If you bought this new then contact your
AN>supplier saying you have a clock problem, if it's previously been 
AN>used then just replace the battery.

I know that a lot of AT class (286) clones had this problem - it was 
really prevalent if a machine was left on all the time.  Sometimes it 
would miss a midnight rollover. If memory serves me correctly, it was a 
problem in the BIOS.

- ---
 . WinQwk 2.0b#0 . Unregistered Evaluation Copy
                                                                               
                    
- ----
////////////////////////////////////////////////////////////////////////
/////// This article originated at The Batchelor Pad PCBoard BBS ///////
// Long Beach, CA ///// 1200-14,400 V.32bis+HST ///// +1 310 494 8084 //
////////////////////////////////////////////////////////////////////////

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

Date:    15 Jan 93 23:39:00 +0000
From:    bill.lambdin%acc1bbs@ssr.com (Bill Lambdin)
Subject: Re: Vshield vs Virstop (PC)

Quoting from St29701@vm.cc.latech.edu to All About Re: Vshield vs Virstop 
(P on 01-15-93

S> VSHIELD with the /CF option to check for a file validation information
S> will not catch a file infecting virus like INTRUDER (very generic)
S> untill after it has infected.  I would have hoped it could chatch it
S> while the infection was trying to occure.

I may be wrong, but I thought the parameter was /CV. Its been a while 
since I used VShield.
 
Vshield can detect new and unknown viruses except for two types.
 
1. Stealth
2. Companion infectors.
 
When a stealth virus is running, It will disinfect infected files on the 
fly when they are opened for any reason, then re-infect the files when 
they are closed.
 
You could get Vshield to detect a stealth virus, but it would require two 
things.
 
1. a known clean write protected bootable diskette.
2. a known clean copy of Scan. Scan c: /CV. This compares the CRC of the 
   file against the CRC stored in the file.
 
Companion infectors do not infect files. They create small .COM files with 
the virus.
 
DOS always looks for a .COM file first, then goes back, and looks for the 
.EXE file.
 
The small .COM file with the virus is run first, then it loads the 
accompanying .EXE file.
 
Bill

- ---
 * WinQwk 2.0 a#383 * Intel sent Michelangelo on copies of LANSpool
                                                                               
------------------------------

Date:    15 Jan 93 23:06:00 +0000
From:    bill.lambdin%acc1bbs@ssr.com (Bill Lambdin)
Subject: Re: Untouchable (PC)

Quoting from Vesselin Bontchev to All About Re: Untouchable (PC) on 
01-13-93

VB> I has improved much since then. And I even don't have the latest
VB> version...

I had 1.1 myself, and FGS sent me an update notice, and I dowmloaded the 
1.13 upgrade from their BBS. All they updated in the 1.13 version was the 
TSR, and scanner.

VB> I have not seen a recent version of Victor Charlie, so I cannot
VB> comment on that. (I saw on a few years ago and it was very poor, but 
VB> have heard that the product has been completely redesigned.) Integrit
VB> Master is undoubtedly the best shareware integrity checker around, bu
VB> it is still MUCH worse that the integrity checker in Untouchable...

I have both the commercial, and share ware versions of Integrity Master 
5.0, and I found the Integrity checking to be pretty good. I would like it 
better if Victor Charlie stored the database of CRCs on a rescue diskette.
 
Personally; I like Integrity Master better than the integrity checking in 
Untouchable for the following reasons.
 
1. IM creates two CRCs per file
2. integrity Master creates can create CRCs for all files instead of just 
   the subset of executable files.

Granted Integrity Master can be improved. In fact I'm trying to talk 
Wolfgang into updating the scanner in IM to detect boot sector droppers.
 
Untouchable doesn't detect droppers either, and I consider them to be a 
fairly large security hole.
 
Prevention is always the best policy.
 
Bill

- ---
 * WinQwk 2.0 a#383 * JERUSALEM (Phenome) activates any Saturday

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

Date:    15 Jan 93 23:44:00 +0000
From:    bill.lambdin%acc1bbs@ssr.com (Bill Lambdin)
Subject: Re: Untouchable (PC)

Quoting from Y. Radai to All About Re: Untouchable (PC) on 01-15-93

YR> This was due to a bug in UTScan.  I'm told it will be fixed in Versio
YR> 27.

This is good to hear. Not that there was a bug, but that you are aware of 
the problem, and at work on a solution.

YR> UTScan (like the rest of the Untouchable package) is, as you probably
YR> know, developed in Israel.  Israeli subscribers automatically get
YR> updates at the beginning of each even-numbered month, so we have had
YR> Ver. 26 for over a month now.  I have no idea when updates reach the
YR> U.S. market, but I presume there's a delay of a week or more.


Yes: I knew that Untouchable was an Israeli product called UnVirus, and 
sold by BRM Technologies, then redistributed in the U.S. by Fifth 
Generation Systems under the name Untouchable.

Bill

- ---
 * WinQwk 2.0 a#383 * FATHER CHRISTMAS activates Dec 19 - Dec 31
       

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

Date:    Mon, 18 Jan 93 07:41:20 -0500
From:    HAYES@urvax.urich.edu
Subject: new PKZIP problems? (PC)

Hello.

Just received a lot of mail on the BBS where I moderate the virus
awareness sub-board, all related to the new PKware PKZIP/PKUNZIP, now
distributed as PKZ204C.EXE (self-extracting archive) and the update
files for Symantec Norton's ANTIVIRUS (two files).
  
Seems that the new PKUNZIP finds a virus, the _maltese amoeba_ and
then stops de-archiving.  I myself downloaded the two files, unzipped
them with no problems, and verified them with both McAfee's Scan
(v.99) and Frisk's F-prot.  No virus found by both AV programs.

Two questions:
a) Does anyone know which type of AV PKware now adds to their program?
b) Are there other reports of similar behavior from PKzip/PKunzip?

Thanks in advance,  Claude.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Claude Bersano-Hayes     HAYES @ URVAX                 (Vanilla BITNET)
University of Richmond   hayes@urvax.urich.edu     (Bitnet or Internet)
Richmond, VA  23173

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

Date:    Sun, 17 Jan 93 12:50:00 +0000
From:    Amir_Netiv@f120.n9721.z9.virnet.bad.se (Amir Netiv)
Subject: New Virus (PC)

Daphne Rosenhouse writes:

 > It looks like a variant of te WHALE, but larger, and
 > harder to remove

Whell, it could be as you say (a variant of the WHALE), but it would
be rather surprising, since the Whale is an old one and from a viral
point of view... an unsuccessful one.

I find it hard to believe that someone will use this as a base virus
for modifications. Did you considered the posibility that you have a
case of several viruses infecting togather or mabe one that infects
files more then once ?

Call me on voice sometime and I'll try to determine the nature of your
virus.

* Amir Netiv. V-CARE, Anti-Virus, Head team. *

- --- FastEcho 1.21
 * Origin: <<< NSE Software >>> Israel (9:9721/120)

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

Date:    Thu, 14 Jan 93 23:41:31 -0800
From:    rslade@sfu.ca
Subject: Internet Worm - Media (CVP)

HISVIRR.CVP   921215
 
                   The Internet Worm - the Media
 
Media coverage of viral programs, and major infestations, has been
consistently, and depressingly, inaccurate.  An enduring mystery
remains from the Internet Worm -- how did the media do so well at
reporting it, a record which has never been equalled, either before
or since?
 
Highly accurate newspaper reports on the Worm were appearing even in
regional newspapers as early as November 5th.  Although some errors
appeared in some stories, the errors tended to be minor.  Although
some very erroneous reports appeared, the ones that got printed
tended to be the more correct.  How did the information get out so
quickly, and how was the media able to discriminate between the
stories so well?
 
(Even the erroneous stories that were carried contained exceptional
information.   A story from the New York Times on Sunday, Nov. 6th
stated that Morris was able to track the progress of the Worm
because "[e]ach second each virus broadcast its location to a
computer named Ernie at the University of California".  While this
was not correct, it *was* true that the Worm was designed to have
packets sent to ernie.berkeley.edu.  The code which was to have done
this was faulty, but, had certain programming been in place at
Berkeley, it would have been possible to get rough estimates of
progress.)
 
John Markoff has come to be widely recognized for the excellence of
his reportage in technical matters.  An examination of his article
of November 8th, 1988 is very instructive.  While the technical
details of his report could not possibly rival that of Spafford, or
Eichin and Rochlis, the general concepts are present, clear and well
presented.  While experts could quibble over some of the details (he
describes the sendmail debug option as a "trapdoor", and is rather
free with assignment of motivation) I suspect they would have to
admit that the important points are all there.
 
Still, what contributed to this unprecedented, and so far
unequalled, media accuracy?  One of the factors is undoubtedly the
number of researchers who were involved.  Across the country, dozens
and perhaps hundreds of people were involved in a detailed
examination of the worm.  Very little other work was being done
until the problem was resolved.  (Let's face it, for many people
little work *could* be done until it was resolved.)  Even those who
were not actually engaged in research as to what the bug did were
following the developments closely so as to be able to disinfect
systems that they were responsible for.  At the same time, there was
not as much time for misinformation to spread via "friends of
friends" who had once seen a copy ...
 
copyright Robert M. Slade, 1992   HISVIRR.CVP   921215

===================
Vancouver          ROBERTS@decus.ca         | "Power users think
Institute for      Robert_Slade@sfu.ca      |  'Your PC is now
Research into      rslade@cue.bc.ca         |  Stoned' is part of
User               p1@CyberStore.ca         |  the DOS copyright
Security           Canada V7K 2G6           |  line." R. Murnane


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

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

