VIRUS-L Digest Thursday, 1 Mar 1990 Volume 3 : Issue 51
Today's Topics:
Possible Virus (PC)
Virus spread (PC)
Memory Scans for Viruses (PC)
Memory Scanning Addendum (PC)
Disinfecting vs. backups & virus signatures (PC)
Virus Catalog February 1990 Edition
RE: Israeli virus strains vs. Novell? (PC)
Re: How the 1554 virus recognizes infected files (PC)
Viruses and Copyrights (Part 2)
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
LEHIIBM1.BITNET for 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: 27 Feb 90 20:20:16 +0000
From:
[email protected] (werner.baumgartner)
Subject: Possible Virus (PC)
I recently down-loaded a file from a local BBS called MEGASPUP.ZIP
which is flagged by SCAN58 as containing 2 viruses, 1701/1704 Ver B
and Vacsina. This program is supposed to decrease disk access time,
according to the documentation. Does anyone have any information about
this file, such as its origin etc. Also, now what do I do with it,
should I send it somewhere to be analysed ?
------------------------------
Date: Tue, 27 Feb 90 20:05:00 -0500
From:
[email protected]
Subject: Virus spread (PC)
Is Jerusalem-B spread an indicator of the future?
Jerusalem-B (Israeli variant) was apparently shipped about 1 week ago
in a PC AT clone from one of the smaller companies. It was on a
formatted hard drive with MS-DOS 4.01 installed. The company
confirmed that they had been having a problem with that virus when
contacted by the upset owner. An earlier contact with the company had
resulted in a denial of a virus problem, and a claim of shipping 300
systems per day.
The new owner, being innocent in the ways of viruses, had, within an
hour, infected his master copies of Microsoft Works and an income tax
program, and now has ordered replacements.
This is the same virus shipped by the Census Bureau several weeks ago to
about 300 users, according to published reports.
There have been detection tools for this virus for months, rather than
weeks, as in the case of some of the newer and "better" viruses.
So far, indications from my experience and surveys are that most
companies and users wait to learn from personal experience about
viruses, rather than learning from others.
Are these infections (with an old virus) an indication of what will
happen when the large number of new viruses have had time to spread far
enough?
Or will the increasing availability of virus scanning tools and
self-checking programs (like MS Works) intersect the "infected systems
curve" soon?
I don't recall seeing an "average rate of adoption" study for techniques
to counter new classes of threats to information systems, but it appears
that it may be in the 10%/year range or lower, at least initially.
Charles M. Preston 907-344-5164 Information Integrity MCI Mail 214-1369
Box 240027 BIX cpreston cup.portal.com
------------------------------
Date: Tue, 27 Feb 90 17:47:32 -0800
From:
[email protected]
Subject: Memory Scans for Viruses (PC)
This is a forward from John McAfee
=================================================================
Nino Margetic raised a good point yesterday that I have not
seen discussed yet. His question was - "why would a virus be detected
in memory when there is no indication of the virus in any of the
system's files?". A very good question.
To begin with, as Nino pointed out, the system was infected
and then disinfected. Herein lies the mystery. In the disinfection
process files are read in through the DOS internal buffers,
disinfected and written back out -- again passing through the DOS
internal buffers.
DOS has a very peculiar habit of insisting that all file
creations occupy a full cluster, whether you need it or not, and
rather than zeroing out the remainder of the cluster, DOS further
insists on padding the remainder with whatever is currently hanging
out unused in the buffer area. Why it does the I do not know --
perhaps a sense of nostalgia for what was once useful code -- who
knows, but in any case this is what it does.
When a file is disinfected then, and written back as a clean
file, everything beyond the end of file mark is residual from whatever
has passed through the DOS buffers. Inevitably, pieces of the
original virus will end up in the buffer area, located just at the end
of the disinfected program. These virus pieces are then written to
the disk as filler for the remainder of the cluster. This process is
not unique to disinfecting. Any file creations performed while a
system is infected may have this end result.
Now, whenever the file is scanned, DOS reads to the end of the
file mark and passes the information to the scan routine. SCAN sees a
clean file, as indeed it is. However, in the process of scanning the
file, DOS had to read the entire cluster into the internal buffers
(God knows why -- perhaps, again, from some sense of nostalgia for
lost data) and in the process it may bring pieces of the virus into
its buffers. A memory scan will then detect this. The virus is of
course not functional or harmful at this point.
It is possible, of course, to design a memory scan that could
differentiate between a live and a dead virus. But this would cause
weaknesses in the memory scan function due to possible modifications
of the virus by unknown hackers that would fool the scan. It's easy
to relocate code. Not so easy to re-code the segments that being
scanned for (assuming the hacker does not know the segments being used
as the I.D.). In any case, that's neither here nor there. The causes
of Nino's observations are hopefully exposed. ....
------------------------------
Date: Tue, 27 Feb 90 17:57:50 -0800
From:
[email protected]
Subject: Memory Scanning Addendum (PC)
Another forward from John McAfee:
========================================================================
I think that I forgot to answer the implied question in Nino
Margetic's posting -- "If, after a disinfection, t file scan says I'm
clean but the memory scan flags the virus, what do I believe?"
Believe the file scan. Except for the following viruses - 4096, 512
and EDV. If it happens with any of these three then give us a call.
408 988 3832.
John MKcAfee
------------------------------
Date: 28 Feb 90 21:10:00 +0700
From:
[email protected]
Subject: Disinfecting vs. backups & virus signatures (PC)
Hi!
John McAfee (in vol. 3, issue 50) writes:
> the process of disinfecting a
>file always leaves an element of uncertainty in the system.
> For example, the Jerusalem virus uses information in the EXE
>header record to determine how to infect. Often this header record
>is inaccurate, causing the virus to overlay part of the EXE file,
>and also causing the virus to update the header record incorrectly.
Often? How often? I know about a version of WordPerfect and that's
all.
>The virus has, in effect, destroyed part of the EXE file, and this
>destruction is often not noticed immediately by the user. The
>corrupted area might be seldom referenced, or in a program function
>area that is bypassed in normal processing. If this is the case,
>removal will leave a program that will at some point cause
>inconsistencies, data corruption, or system crashes when the erased
>area is referenced. There is simply no way to recover the file
>because there is no way (short of using the original uninfected
>program) to determine what was in the file before it was
>overwritten.
Well, the file was *already* destroyed when it was infected. If you
disinfect it you won't cause more damage (besides the false sense of
security). If you don't have the appropriate backups (or the
originals, of course), you have only two possibilities --- to leave
the file destroyed but infected and to leave it destroyed but *not*
infected. I prefer the second solution, since the first will continue
to spread the infection. Of course, you can also completely delete the
file.
> The Jerusalem is not alone in causing these problems. There
>are numerous EXE infectors and some COM infectors (405, Vienna)
>that cannot be successfully recovered in all cases.
Ooops! Files, which are *infected* by the Vienna virus can *always* be
recovered. In all cases. You cannot recover the files *destroyed* by
this virus (with their first 5 bytes overwritten), but this is the
case with all files destroyed by a virus. (They know well how to
destroy our data, these nasty things :-).)
> To get back to my point, I would strongly suggest that
>infected files be overwritten in their entirety and then deleted
>if at all possible. Only as a last resort, where backups or
>original diskettes are unavailable, should disinfection be used.
OK, OK! I agree that it is better to have backups. But it is *best* to
have *both* backups and a disinfector. If this was not true all the
work done by the antivirus researchers would be useless. This forum
would be useless too. It is relatively easy (if you have non-infected
backups, of course) to recover from any virus attack --- even if it
was performed by the most sophisticated virus. You have only to follow
a set of computer hygiene rules, which fin on a half page. Even that
dumb fool --- the so-called average user can be teach to follow
them.... Hmmm, can he? :-)
- --------------
John Sangster (
[email protected]) writes:
>Possibly a useful approach to posting virus scan patterns would be
>for virologists to extract one or more segments of the virus code of,
>say, 1K bytes (that's a fairly reasonable 12 lines at 80 bytes per
>line).
>Of course, viruses can be constructed which alter themselves at each
>replication, making any search with a fixed string futile, or at
>best, "challenging" to design.
CAN BE?! Whey *were* constructed. The 1701/1704 virus contains only a
small piece of code which can be scanned for --- all the rest is
encrypted. The virus uses the file length as an encryption key ---
therefore the encrypted part is always (well, almost always)
different. And there exist much more clever viruses like the 4096 and
the 1260 viruses, in which even the (small) part which is not
encrypted and which is used to decrypt the rest of the virus, even
this small part is somewhat different for every infected file. (Well,
I think so, I have no examples of these viruses.)
And it is also possible to design a virus (hey, catch that virus
writer who is reading this behind your back :-)), which will be
impossible to be recognized --- in the file. The virus itself will not
be able to say if a file is already infected. Eventually, there will
be two (or more) copies of the virus in the file. But when the file is
run, the virus will figure out that there is something after it and
will strip it off the file. It is hard to implement such a thing, but
once someone gets the idea, it will be much easier --- remember the
problem "write a program which outputs its own source".
Vesselin
------------------------------
Date: 28 Feb 90 17:16:00 +0100
From: Klaus Brunnstein <
[email protected]>
Subject: Virus Catalog February 1990 Edition
=======================================================================
== Computer Virus Catalog Index ==
=======================================================================
== Status: February 15, 1990 (Format 1.2) ==
== Classified: 15 MSDOS-Viruses (MSDOSVIR.A89): Nov.15,1989 ==
== +17 MSDOS-Viruses (MSDOSVIR.290): Feb.15,1990 ==
== 24 AMIGA-Viruses (AMIGAVIR.A89): Nov.15,1989 ==
== 6 Atari-Viruses (ATARIVIR.A89): Nov.15,1989 ==
== Next edition planned: April 1990 ==
=======================================================================
== To minimize problems with network restrictions (some of which ==
== limit e-mail to packages of less than 100 kBytes), the list of ==
== totally 30 MS-DOS viruses is partitioned, due to the first pub- ==
== lication, in 2 partitions (indicated at each entry): ==
== October 1989: Document MSDOSVIR.A89: 1.138 Lines, 62 kBytes ==
== + February 1990: Document MSDOSVIR.290: 1.163 Lines, 67 kBytes ==
=======================================================================
== List of classified MS-DOS Viruses: =Doc=
== ---------------------------------- = =
== + 1) Advent Virus =290=
== 2) Autumn Leaves=Herbst="1704"=Cascade A Virus =A89=
== 3) "1701" = Cascade B = Autumn Leaves B = Herbst B Virus =A89=
== 4) Bouncing Ball = Italian = Ping Pong= Turin Virus =A89=
== + 5) Dark Avenger =290=
== + 6) DATACRIME Ia = "1168" Virus =290=
== + 7) DATACRIME Ib = "1280" Virus =290=
== + 8) dBase Virus =290=
== + 9) Denzuk = "Search" = Venezuellan Virus =290=
== + 10) Do Nothing = Stupid = 640k Virus =290=
== 11) "Friday 13th" = South African Virus =A89=
== + 12) Fu Manchu Virus =290=
== 13) GhostBalls Virus =A89=
== + 14) Hello (1A) Virus =290=
== 15) Icelandic#1 = Disk Crunching = One-in-Ten Virus =A89=
== 16) Icelandic#2 Virus =A89=
== 17) Israeli = Jerusalem A Virus =A89=
== + 18) Lehigh Virus =290=
== 19) MachoSoft Virus =A89=
== + 20) Marijuana = Stoned = New Zealand Virus =290=
== 21) Merritt = Alameda A = Yale Virus =A89=
== + 22) MIX1 = Mixer1 Virus =290=
== + 23) Ogre = Disk Killer 1.00 Virus =290=
== 24) Oropax = Music Virus =A89=
== 25) Saratoga Virus =A89=
== 26) SHOE-B v9.0 Virus =A89=
== + 27) sURIV 1.01 Virus =290=
== + 28) Swap = Israeli Boot Virus =290=
== + 29) SYSLOCK Virus =290=
== 30) VACSINA Virus =A89=
== 31) Vienna = Austrian = "648" Virus =A89=
== + 32) Zero Bug = ZBug = Palette Virus =290=
== ==
== Remark: The following 25 MSDOS-Viruses are presently examined, ==
== classification will be published in next edition (April,1989): ==
== ==
== .) AIDS Virus ==
== .) Amstrad Virus ==
== .) Ashar Virus (Pakistani Virus Strain)==
== .) Brain A = Pakistani A-Virus (Pakistani Virus Strain)==
== .) April 1st Virus (Jerusalem Virus Strain)==
== .) DATACRIME II = Columbus Day Virus (DATACRIME Virus Strain)==
== .) Devils Dance Virus ==
== .) Ghost Boot Virus ==
== .) Lisbon Virus (Vienna Virus Strain)==
== .) Pentagon Virus ==
== .) Perfume Virus ==
== .) Silvia Virus ==
== .) SURIV 2.01, 3.00 Viruses (Jerusalem Virus Strain)==
== .) Traceback = "3066" Virus ==
== .) Typo (Link) = Fumble Virus ==
== .) Vcomm Virus ==
== .) W13 (Variants A,B) = Polish Viruses ==
== .) Yankee Doodle Virus ==
== .) Yankee Bulgarian Virus ==
== .) "405" Virus ==
== .) "1260" Virus ==
== .) "1702" Variant (Autumn Leaves Virus Strain)==
== .) "4096" Virus ==
=======================================================================
== The list of 24 AMIGA viruses is divided into 2 partitions (as ==
== indicated at each entry): ==
== October 1989: Document AMIGAVIR.A89: ==
== November 1989: Document AMIGAVIR.B89: ==
=======================================================================
== List of AMIGA Viruses: ==
== ---------------------- ==
== 1) AEK-Virus = Micro-Master Virus (SCA Virus Strain) =A89=
== 2) BGS 9-Virus =A89=
== 3) Byte Bandit Virus =A89=
== 4) Byte Bandit Plus Virus (Byte Bandit Virus Strain) =A89=
== 5) Byte Warrior#1 Virus = DASA-Virus (Byte Warrior Strain) =A89=
== 6) Disk Doctors Virus =A89=
== 7) Gaddafi-Virus =A89=
== 8) Gyros Virus =A89=
== 9) IRQ-Virus =A89=
== 10) LAMER (Exterminator) Virus =A89=
== 11) LSD Virus (SCA Virus Strain) =A89=
== 12) NORTH STAR I Antivirus-Virus (NORTH STAR Virus Strain) =A89=
== 13) NORTH STAR II Antivirus-Virus (NORTH STAR Virus Strain) =A89=
== 14) Obelisk Virus =A89=
== 15) Paramount Virus=Byte Warrior#2 Virus (Byte Warrior Strain)=A89=
== 16) Pentagon Antivirus-Virus =B89=
== 17) Revenge 1.2G Virus =B89=
== 18) SCA-Virus =B89=
== 19) System Z 3.0 Antivirus-Virus (System Z Virus Strain) =B89=
== 20) System Z 4.0 Antivirus-Virus (System Z Virus Strain) =B89=
== 21) System Z 5.0 Antivirus-Virus (System Z Virus Strain) =B89=
== 22) Timebomb 1.0 Virus =B89=
== 23) VKill 1.0 Virus = Camouflage Virus =B89=
== 24) WAFT-Virus =B89=
== ==
== Remark: the following 8 AMIGA-viruses are presently analysed,clas-=
== sified and will be published in the next edition (April,1990): ==
== .) BUTONIC 1.1 Virus ==
== .) JOSHUA Virus ==
== .) LAMER EXTERMINATOR Virus 1.0, 2.0, 3.0 ==
== .) SYSTEM Z 5.1, 5.3 Virus ==
== .) WARHAWK Virus ==
=======================================================================
== Document ATARIVIR.A89 contains the classifications of the ==
== following 6 viruses (375 Lines, 21 kBytes): ==
=======================================================================
== List of Atari Viruses: ==
== ---------------------- ==
== 1) ANTHRAX = Milzbrand Virus =A89=
== 2) c't Virus =A89=
== 3) Emil 1A Virus = "Virus 1A" =A89=
== 4) Emil 2A Virus = "Virus 2A" = mad Virus =A89=
== 5) Mouse (Inverter) Virus =A89=
== 6) Zimmermann-Virus =A89=
== ==
== Remark: the following 2 Atari-viruses are presently analysed,clas-=
== sified and will be published in the next edition (April,1990): ==
== .) BPC Virus ==
== .) Ghost Virus ==
==
== We have problems to get Atari viruses, as many users wish to ex- ==
== change their viruses (like stamps) against our's, which we gene- ==
== rally refuse: the Virus Test Center's ethical standard says, that ==
== we do not help to spread viruses! Please send infected programs ==
== without preconditions; we may only then continue our work. ==
=======================================================================
=======================================================================
== For their outstanding support and continued help, we wish to ==
== David Ferbrache (Edinburgh), Christoph Fischer (Karlsruhe), ==
== Yisrael Radai (Jerusalem) and Fridrik Skulason (Rejkjavik). ==
== Critical and constructive comments as well as additions are ==
== appreciated. Especially, descriptions of new viruses will be of ==
== general interest. To receive the Virus Catalog Format, containing==
== entry descriptions, please contact the above address. ==
=======================================================================
== The Computer Virus Catalog may be copied free of charges provided ==
== that the source is properly mentioned at any time and location ==
== of reference. ==
=======================================================================
== Editor: Virus Test Center, Faculty for Informatics ==
== University of Hamburg ==
== Schlueterstr. 70, D2000 Hamburg 13, FR Germany ==
== Prof. Dr. Klaus Brunnstein, Simone Fischer-Huebner ==
== Tel: (040) 4123-4158 (KB), -4715 (SFH), -4162(Secr.) ==
== Email (EAN/BITNET):
[email protected] ==
=======================================================================
== This document = INDEX.290: 164 Lines, 12 kBytes ==
=======================================================================
------------------------------
Date: Wed, 28 Feb 00 19:90:25 +0000
From: Gonzalo M. Rojas Costa <
[email protected]>
Subject: RE: Israeli virus strains vs. Novell? (PC)
Hi...
Otto Stolz (RZOTTO%
[email protected]) writes:
>> ** the "Friday 13th" will cause Novell Networks to hang every time an
>> infected program is invoked;
Yes. Novell Networks use function E0 of int 21h for the print
spooler. For that reason, if I execute an infected program, the server
and the stations hangs. (On the server, before it hangs, the LAN
manager prints a message that an interrupt vector was try to changed).
>> ** so will probably other Israeli strains do.
I tested versions B and B-2 of the Jerusalem virus and the two
versions produce the same efect (hangs the stations and server).
>> IMMUNE and similar virus-watchers will probably suspect Novell of
>> being a virus, and alert the user about it;
>> VIRCHECK and similar virus-checkers will cause Novell to hang,
>> as well.
I didn't tested IMMUNE on a Novell Network. But any program that
try to detect the Jerusalem Virus through function E0 int 21h, hangs
the computers on a Novell Network.
In a Novell Network or other LAN you can use John Mcaffe's
NETSCAN to search infected programs. (This program is on SIMTEL20 in
the directory PD:<MSDOS.TROJAN-PRO>).
Disclaimer: The views expressed are my own! I do not speak for, nor do
I represent any other person or company.
Gonzalo M. Rojas Costa
BITNET: LISTVIR@USACHVM1
ARPA: LISTVIR%
[email protected]
Owner of ASSMPC-L
Antiviral Research Group
Technical Support Unit
Universidad de Santiago de Chile
------------------------------
Date: Wed, 28 Feb 00 19:90:57 +0000
From: Gonzalo M. Rojas Costa <
[email protected]>
Subject: Re: How the 1554 virus recognizes infected files (PC)
Hi...
Vesselin Bontchev (
[email protected]) writes:
>> For .COM files:
>> If the contents of the word at offset 02 in the file is 12Eh,
>> then the file is infected.
No. The file isn't infected if the contents of the word at offset 02
in the file is 12Eh. (i.e. If I have an infected program, this always
have the word 12Eh at offset 02, because this word is part of an
instruction of the virus).
>> For .EXE files:
>> If the contents of the word at offset 02 in the file is equal
>> to the negated contents of the word at offset 12h, then the file is
>> infected.
No. If the contents of the word at offset 02 (Number of bytes
contained in last page) is equal to the negated contents of the
word at offset 12h (negative sum of all the words in the file),
then the program ISN'T INFECTED.
(In the process of infection, the virus negates the number of bytes
contained in the last page of the EXE program, and this value it
puts at offset 12h of the header (i.e. as the negative sum of all
the words in the file).
>> Unfortunately, this does not give us a method for file vaccination,
>> since the contents of the bytes mentioned above is used. For .COM
>> files, the byte at offset 02 is usually (not always!) the third
>> byte of a JMP instruction. For .EXE files the situation is
>> easier --- the word at offset 12h contains the so-called checksum,
>> which is never used and can be modified.
I completely agree with you.
Disclaimer: The views expressed are my own! I do not speak for, nor do
I represent any other person or company.
Gonzalo M. Rojas Costa
BITNET: LISTVIR@USACHVM1
ARPA: LISTVIR%
[email protected]
Owner of ASSMPC-L ("Assembly for the IBM-PC")
Antiviral Research Group
Technical Support Unit
Universidad de Santiago de Chile
------------------------------
Date: Wed, 28 Feb 90 21:08:43 -0500
From:
[email protected]
Subject: Viruses and Copyrights (Part 2)
This is to continue my earlier posting on copyrights and viruses,
based upon _How to Copyright Software_ by M.J. Salone. This posting
is in regards to derivative works; for example, a disassembly of a
virus made by someone other than the virus author.
Congress defines the term 'derivative work'as "a work based upon
one or more pre-existing works." [17 USC Sec. 101] A virus disassembly
would probably fall under this definition because the opcodes are
presumably from the actual virus even though the descriptive comments
are the creative input of the person disassembling it. The above
definition is likely to apply if a disassembly is considered to be a
translation of the virus. The question then becomes "Is the
disassembly author required to get the permission of the person who
holds the copyright (usually the author) before publishing the
disassembly?" The answer is, technically, yes.
However, the absence of a copyright notice could be a legitimate
excuse for assuming that the virus is public domain; this is backed up
by the fact that viruses are designed to replicate themselves without
consent of the user. Items within the public domain are free to be
used and distributed in any way. Derivative works of public domain
items can be copyrighted as long as the new material is substantial
enough to be considered original. As far as disassemblies are
concerned, the aforementioned descriptive comments are original
material and can thus be copyrighted (i.e. the whole disassembly).
Of course there is the question of whether-or-not a virus is
considered to be properly copyrightable anyway, as other contributors
to Virus-L have noted. Viruses install themselves into other
programs, thus creating aunauthorized derivative works in the process!
Please note that, if the above is untrue, then the disassembly
can not be published without the consent of the virus' copyright
holder. The copyright holder of a work solely has the right to
publish derivative works based upon his/her original publication
during the duration of the copyright.
In my opinion the disassembly is copyrightable because the virus
is in the public domain (since copyright notices are not normally
found in viruses; not to mention that viruses may themselves be
somewhat illegal). I I doubt that a virus author would sue for
infringement because, as I said in my previous posting, that the virus
author is likely to incrimminate himself by doing so.
[Ed. For what it's worth, I believe that some versions of the Brain
virus included a copyright notice in the ASCII header.]
My next posting will contain a discussion on what rights are
protected by a copyright.
DISCLAIMER: The above are my opinions. I'm not a lawyer :-) Please do
not take this material to be the law.
------------------------------
End of VIRUS-L Digest
*********************
Downloaded From P-80 International Information Systems 304-744-2253
