VIRUS-L Digest Monday, 26 Feb 1990 Volume 3 : Issue 49
Today's Topics:
Request for anti-virus sw (Mac)
NYT Bestseller!
Virus signatures & IBM virus scanner (PC)
Book - Computer Virus Handbook
Scan 3.0V58 uploaded (PC)
Re: anti-virus procedures (Mac)
The 1554 (NOT 1559!) virus (PC)
$1000 for breaking this Manipulation Detection Code (MDC)
Viruses and Copyrights
Virus Conference Info
How the 1554 virus recognizes infected files (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. 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: Fri, 23 Feb 90 02:49:36 +0000
From:
[email protected] (Craig Woods)
Subject: Request for anti-virus sw (Mac)
Situation:
Our site has WDEF (I think): our Mac is virtually useless - font's are
messed up, the machine crashes regularly when {leaving applications |
copying files | using scrapbook}, and the printer and modem regularly
disconnect from Fleetwood (the Mac). We do not have ResEdit or other
tools to analyze the System/desktop file/resources so we have no way
of knowing whether this is WDEF or not. (I sure hope this IS WDEF,
otherwise our system is REALLY messed up :-)
I've seen some questions/references to re-building the desktop as a
way of (temporarily?) combating the virus, but this has no effect on
the Mac's reliability.
We have sent for a Virex upgrade to combat the virus; Unfortunately,
we sent for it via U.S. Snail mail, so it may take weeks to get here.
As an emergency shortcut, I am submitting the following...
Plea:
1) Are the products Gatekeeper 1.1.1, Gatekeeper Aid 1.0.1,
Disinfectant 1.6 public domain software?
2) If so, would someone please mail them to me? (We are not on the
Internet, so I can't FTP from anywhere (can I?))
3) If someone does mail this software, could you include some
instructions for unpacking software from the Net? Our UUguru recently
left the company, so no-one here knows anything about unpack, unshar,
unhex, and all those other un-holy sciences. This task is complicated
by the fact that the mail will be received on a Vax, FTP'ed to a Sun,
and converted to Mac format via TOPS.
I am hoping to be able to get the Mac up over the weekend so that we
can publish our software manual next week. Mail explaining the
impossibility of any of the above steps will be appreciated, if anyone
can stop laughing long enough to reply (You want to do WHAT!?!?). :-)
Many thanks in advance.
Craig Woods
Systems Manager
Software Leverage,Inc.
..uunet!sli!craig
craig%
[email protected]
------------------------------
Date: Thu, 22 Feb 90 15:01:31 -0500
From:
[email protected] (Cliff Stoll)
Subject: NYT Bestseller!
Greetings to the Virus-L gang...
The Cuckoo's Egg has made it onto the NY Times bestseller list.
I'm amazed that so many people would be interested
in our computer networks, viruses, and nasty animals in our systems.
Many people on Virus-L directly helped with the book - each of you
knows who you are. At least as important: throughout writing it,
I read Virus-L to keep up to date.
And so, to all who have contributed to this lively forum, my thanks
to you for spreading the good word. Especially, thanks to Ken van
Wyk, who's put long hours into creating a fast moving, well moderated
conference.
-- Cliff Stoll
[email protected]
------------------------------
Date: Fri, 23 Feb 90 10:51:11 -0500
From:
[email protected]
Subject: Virus signatures & IBM virus scanner (PC)
With regard to Gerry Santoro's question about the IBM virus scanning
program, the author, Bill Arnold, is constantly updating the program,
improving its performance and including new viral signatures. The
current version is 1.37 which scans for 58 different signatures and I
assume that if you have an older one you can get an update from IBM.
There is a facility in the program that gives you the ability to add
new viruses to be scanned for by constructing a text file
(ADDENDA.LST) containing the signatures of new viruses. However, I do
not know of any central place where these signatures can be obtained.
While it is a valid concern that posting signatures may cause virus
authors to change them to create undetectable mutant viruses, I think
this is offset by the need to be able to update a scanning program
rapidly when a new virus is found. (It is also possible to choose
signatures that cannot be changed without rewriting the whole virus
program.)
Is there in fact a publicly accessible system where new virus
signatures can be found? If not, it seems that this digest would be a
good place to post such signatures as long as they come form a
reputable and verifiable source. What do others think?
[Ed. There are a few problems with posting virus signatures. First,
many developers choose, and indeed prefer, to use in-house developed
signatures. Second, some viruses cannot be detected by "traditional"
signature scans. There are more problems, I'm sure. Still, I'm not
at all opposed to people posting virus signatures, just as long as
everyone realizes the limitations of these signatures.]
_________________________________________________________
| |
| Kevin Haney, Computer Specialist |
| Division of Computer Research and Technology |
| National Institutes of Health |
| BITNET -
[email protected] |
|_________________________________________________________|
------------------------------
Date: Fri, 23 Feb 90 11:55:45 -0500
From:
[email protected] (lance hoffman)
Subject: Book - Computer Virus Handbook
I just obtained COMPUTER VIRUS HANDBOOK, by Harold Highland, published
by Elsevier Advanced Technology, Mayfield House, 256 Banbury Road,
Oxford OX2 7DH, United Kingdom. It has approximately 370 pages (8 1/2
x 11) of material in a hard binding, ISBN 0-946395-46-2. It boasts a
foreword by Bill Caelli, Director of the Information Security Research
Center, Queensland University of Technoloby, Brisbane, Queensland,
Australia, and ten chapters:
1. Basic Definitions and Other Fundamentals
2. The Application of Epidemiology to Computer Viruses (by William H.
Murray)
3. A History of Computer Viruses
Introduction
The Famous Trio (Brain, Lehigh, Israeli)
Another Trio (Alameda, Ping Pong, Marijuana)
Three Special Viruses (Macro, Vienna, Batch)
Other Known and Reported Viruses (Datacrime, Icelandic, Autumn
Leaves, Fu Manchu, Traceback, others)
4. Reports from the Virus Hunters
U. of Delaware and the Pakistani Computer Virus (by Anne E.
Webster)
Lehigh Virus (by Ken van Wyk)
Israel PC Virus (by Yisrael Radai)
5. Evaluation Protocol and Test Methodology
Virus Test Centers, Evaluation Sites, Anti-virus products
...
6. Testing an Anti-Virus Product (by Jon David)
7. Product Evaluations
(includes reports on Antidote, Data Physician, Disk Defender,
Disk Watcher, Dr. Panda Utilities, Flu Shot +, Immunize, Mace
Vaccine, Ntivirus, Softsafe, Vaccinate, Vaccine [Certus], Vaccine
(Sophos Ltd.), Vaccine (Worldwide Software), VirAlarm 2000 PC,
Virus-Free, Virusafe, Vir-X, V*Screen, XFICheck) [addresses of
manufactures are in back of book]
8. Viruses - A Management Issue (by Harry B. de Maio)
9. Procedures to Reduce the Computer Virus Threat
10. Conceptual Foundations of Computer Viruses
includes five reprinted papers from Computers & Security
Quite a bit of the material has appeared before in Computers & Security
(the journal published by Elsevier) but a good deal is new. Especially
interesting are the test results of anti-viral products.
Lance J. Hoffman
The George Washington University
------------------------------
Date: Fri, 23 Feb 90 12:15:08 -0600
From: James Ford <
[email protected]>
Subject: Scan 3.0V58 uploaded (PC)
Sorry, the files were:
SCANV58.ZIP - SCAN 3.0V58 (not 1.4V58)
SCANRS58.ZIP - SCAN 3.0V58 (not 1.4V58) (tsr)
Sorry for any inconvience the error may have caused.
- ----------
James Ford -
[email protected],
[email protected]
------------------------------
Date: Fri, 23 Feb 90 11:47:00 -0800
From:
[email protected]
Subject: Re: anti-virus procedures (Mac)
We are currently investigating possible proposals for PREVENTING
virus infections in our Mac/PC labs. If anyone has a procedure they
are using or have seen (including necessary hard/software), I would
appreciate a brief description of policies as well as procedures.
I am working with a colleague on this and if you could send any
replies to me directly and CC: my colleague
(
[email protected]) we would be forever grateful...
Thanks.
Sam Cropsey, Microsystems Manager
Pomona College
Internet:
[email protected]
Bitnet: SAM@POMONA
------------------------------
Date: 23 Feb 90 20:53:00 +0700
From:
[email protected]
Subject: The 1554 (NOT 1559!) virus (PC)
Gonzalo M. Rojas Costa <
[email protected]> writes:
> This virus only copies itself to the address 9800h:0000. It don't
>installs resident with INT 27 or the function 31H. If I execute a big
>program (that ocupies the segment 9800h), this program erase the virus
>from memory and a crash will occurr.
Sorry, this is a misunderstanding, due to my poor English. What I did
mean was not that the virus is a TSR program, but that once you run an
infected application, it will stay in memory permanently (until the
next reboot, of course :-) ). I call such a virus memory resident,
since it's resident in the memory all the time. What I do *not* call a
memory resident virus is a virus which gets its code executed only
when one executes an infected application.
>For that reason I don't find appropriate the name 1559 for this
>virus. Besides, the size of the virus is 1554 bytes. Then I don't
>find the reason for that name.
Agreed. So let's call it the 1554 virus. (John McAfee?)
>The 32 bytes overwritten can be found at offset (14,15)*16+1271 on
>the infected program that I disassembled. (It seems that the offset
>where the bytes overwritten are located is (14,15)*16+number, and
>number depends of the size of the program being infected).
Nope. The number is hard coded in the virus body. Here is the relevant
portion of the code:
org xxx
push ds
push cs
pop ds
lea si,[4F7h]
mov di,100h
mov cx,20h
rep movsb
This code restores the original bytes into their place. It is executed
just after the virus has performed a jump at cs+[0Eh]:0. Therefore the
full address of xxx is (cs+[0Eh])*10h. The instruction
lea si,[4F7h]
actually loads SI with the number 4F7h (1271 decimal).
rep movsb
moves 20h (32 decimal) bytes from DS:SI to ES:DI. And we have DS ==
CS (push cs; pop ds). Therefore, the bytes are got from (full address)
(CS+[0Eh])*10h+4F7h. To eliminate the value of the CS register, just
remember that the file was loaded at address CS:100h (i.e., the full
address is CS*10h+100h). I speak here only for the .COM files.
Now, if we subtract the two values, we'll get
(CS+[0Eh])*10h+4F7h-CS*10h+100h = [0Eh]*10h+3F7h
from the beginning of the file. And 3F7h is just 1015 decimal --- the
number I stated in my previous posting.
I repeat, this is true only for the .COM files.
BTW, has someone of the other antivirus researchers produced a program
which is able to disinfect the files from this virus? And even to
restore their original size? I spoke with David Chess and he told me
that he prefers the "delete the infected file and restore them from
backups" method. But have in mind, that guy from Taiwan (was he from
there?) is in trouble --- and may not have the appropriate backups.
(We all miss them just when we need them :-).)
Vesselin
------------------------------
Date: Fri, 23 Feb 90 15:28:00 -0600
From: Pete Klammer 303/556-3915 <
[email protected]>
Subject: $1000 for breaking this Manipulation Detection Code (MDC)
[Ed. From the CERT-Tools mailing list.]
"Re-posting of this announcement to appropriate groups is encouraged."
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
From:
[email protected]
Subject: Snefru algorithm for checksumming
Date: Wed, 21 Feb 90 13:39:59 EST
A few days ago, I wrote a message suggesting that CRCs were
inappropriate for security uses, and that Snefru or MD4 might be
better. Several people wrote back asking where they could obtain
them. Ralph Merkle -- the author of Snefru -- has posted the
following note; as per the permissions at the end of the note, I am
resending it to this list.
--Steve Bellovin
[email protected]
- ------- Forwarded Message
Date: Tue, 20 Feb 90 14:06:50 PST
From: Ralph Merkle <
[email protected]>
Subject: $1,000 reward for breaking Snefru 2.0
The following was posted to sci.crypt:
- - --------------------------------------
The one-way hash function, Snefru 2.0, is available
by anonymous FTP from arisia.xerox.com in directory
/pub/hash. It is available for use by anyone interested.
A $1,000 reward is offered to the first person to break it.
General: Snefru 2.0 is a one-way hash function. One-way
hash functions have also been called manipulation detection
codes (MDC's), message digests, cryptographically secure
checksums, cryptographically secure hash totals, and sometimes
fingerprints.
One way hash functions do not involve use of a secret key
or any secret information. They are used to authenticate
information, and to verify that the information has not
been tampered with. One-way hash functions have the
following properties:
1.) Given any input of any size (a file, for example) it is
easy to compute the output of the one-way hash function. If
the one-way hash function is designated H, then
output = H(input)
is easy to compute (takes time linear in the size of the input).
2.) Although the input might be very large, the output is
relatively small and of fixed size. In Snefru 2.0, the output
can be either 128 or 256 bits (selectable by the user).
3.) It is computationally infeasible to find two inputs x and
x' that produce the same output. That is, finding x and x' such
that:
H(x) = H(x')
is infeasible. Finding such a pair of inputs is known as
"cracking" or "breaking" the one-way hash function.
4.) Given an output, it is computationally infeasible to
find an input that produces that output. (This property
is not always used).
One-way hash functions are not the same as Message Authentication
Codes, or MAC's, which involve the use of a secret key.
History of Snefru:
Snefru version 1.0 was designed and made public over a year ago.
No significant security flaws were found then or since in Snefru 1.0,
but several improvements were suggested. Most significantly, the
tables used in Snefru 1.0 were not generated in a publicly verifiable
fashion.
Snefru version 2.0 uses a set of tables generated from publicly
known random information: "A Million Random Digits with
100,000 Normal Deviates" by the RAND Corporation, published
by the Free Press in 1955. In addition, the algorithm used
to derive the tables is also publicly known (and available
for anonymous FTP along with Snefru 2.0).
During the redesign, the basic algorithm was made simpler
and some features of modest utility which increased the
complexity of the design were eliminated. The revisions
for Snefru 2.0 were completed in July. The C source for
Snefru 2.0 was made available by anonymous FTP in November
of 1989.
Security of Snefru:
The security of one-way hash functions can (at present) only
be assessed by making them widely available for review and
attack. At the present time, Snefru has undergone some internal
review at Xerox and has been subjected to two separate and
independent reviews by two outside consultants hired
for the purpose. No security problems have been uncovered.
During the past decade, however, many one-way hash functions
have been proposed and then broken. The security of any particular
one-way hash function should therefore be viewed with caution.
And, of course, Xerox Corporation makes no representations
concerning either the merchantability of Snefru or the suitability
of Snefru for any particular purpose. It is provided "as is"
without express or implied warranty of any kind.
Various groups not connected with Xerox have begun to examine
the security of Snefru since it was made publicly available.
It will probably be a while before these groups develop an
opinion about its security.
To encourage examination of Snefru, a reward of $1,000 is offered
to the first person who shows they have broken it. A "break"
is defined as providing two different inputs that produce the
same output. The output size will be 128 bits, and the "security level"
parameter will be set at 2 (these are the default settings).
(Note that a more secure setting for the security level parameter (4)
and a larger output size (256 bits) are available in Snefru 2.0
as options).
Fine print: Xerox employees cannot enter. The winner must send his
name, address, and social security number (if available) along with the
inputs x and x' that produce the same output. It is expected that
other relevant information (the nature of the algorithm used, the
hardware, etc) will also be sent, though this is not required. Any
taxes are the responsibility of the winner. We reserve the right
to decide ties (multiple entries on or about the same date) and our
decision will be final.
Implementations:
Snefru 2.0 is a C version. Snefru 2.1 is identical algorithmically,
but is partially implemented in assembly language to improve
performance. The two implementations produce the same result,
which increases the belief that both are correct. Snefru 2.1 is
now also available for anonymous FTP. The assembly language version
hashes slightly over 8 megabits per second (slightly over 1 megabyte
per second) on a SUN SPARC station 1 when I/O time is not included
(the actual execution time of the hash algorithm by itself is measured).
The same version hashes at slightly over 6 megabits per second
when the I/O time is included. The C version of Snefru 2.1 hashes
at 4 megabits per second (including I/O time).
Free Availability:
Anyone who wishes to use Snefru can do so without charge.
The following notices appear in the source, and are the only
restrictions on the use of Snefru:
Copyright (c) Xerox Corporation 1989. All rights reserved.
License to copy and use this software is granted provided
that it is identified as the "Xerox Secure Hash Function"
in all material mentioning or referencing this software
or this hash function.
License is also granted to make and use derivative works
provided that such works are identified as "derived from
the Xerox Secure Hash Function" in all material mentioning
or referencing the derived work.
Xerox Corporation makes no representations concerning either
the merchantability of this software or the suitability of
this software for any particular purpose. It is provided
"as is" without express or implied warranty of any kind.
Re-posting of this announcement to appropriate groups is encouraged.
Ralph C. Merkle
[email protected]
Xerox PARC
3333 Coyote Hill Road
Palo Alto, CA 94304
- ------- End of Forwarded Message
**CERT-Tools Information:****************************************************
* Submissions :
[email protected] *
* Address additions/deletions/changes :
[email protected] *
* Moderator :
[email protected] *
*****************************************************************************
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
/** --poko " I'm half Estonian, which makes up for the other half. "
Pete Klammer /(303)556-3915 FAX:(303)556-4822
[email protected]
CU-Denver Computing Services / Campus Box 169 BITNET: PKLAMMER@CUDENVER
1200 Larimer St NC2506 / Denver CO 80204-5300 UU:!boulder!pikes!pklammer **/
------------------------------
Date: Fri, 23 Feb 90 21:40:50 -0500
From:
[email protected]
Subject: Viruses and Copyrights
[Ed. A number (!) of people sent in other contributions to the ongoing
discussion debating whether or not the AIDS Trojan was a copy
protection scheme. While each and every one of these raised valid
concerns, in the interest of reducing net volume, I've not included
them all in this digest (bulk posting for you Usenet readers...). If
anyone feels strongly against this, just let me know. I'll gladly
continue posting related messages if it is felt that there are further
points to be raised.]
I have read (and heartily recommend) the third edition of _How to
Copyright Software_ by attorney M.J. Salone and would like to post a
few points from it:
1) The United States is a member of the Berne Convention as of March
1, 1989; which means that works published on or after that date do not
need a copyight notice (Copyright 1990 John Doe) in order to be
entitled to copyright protection. A notice is required to be included
in works published before that date or else they will lose protection
unless:
a) Only a relatively small number of copies of the work exist without the
notice. This, of course, will not be the case with viruses since they
are designed specifically to replicate themselves.
OR
b) The copyright is registered with a copyright office within five years of
publication AND the notice is included in copies that are not yet in the
hands of the public. A virus author isn't likely to register, even if
a pseudonym is listed in the copyright notice, since the author's real
name is needed in order to actually sue in court for damages. Admitting
in court that he/she wrote a virus and waiving a copy of the registration
around will be all the evidence needed to convict the author of breaking
the law. (Since the confession was made during a civil suit filed by the
author I don't think "self-incrimination" regulations would protect the
author.)
OR
c) The author licensed or authorized another party to handle the work and the
notice was not included due to the negligence of that party, unless the
author did not specifically require the party to include the copyright
notice. This probably wouldn't apply to virus writers since other parties
could later become witnesses against the author. Most virus writers get
pleasure of creating a virus on their own.
Because of the length involved I will break up my contribution
into a few smaller postings. Next time I'll mention how derivative
works come into play; this relates to cases where a person copyrights
a disassembly of a virus written by someone else.
DISCLAIMER: The above interpretations are mine - I'm not a lawyer! Please
do not take this posting to be complete truth!
------------------------------
Date: Fri, 23 Feb 90 21:07:00 -0500
From:
[email protected]
Subject: Virus Conference Info
Verified lack of info at 800 number, reported same to conference
sponsor, was told that as of next Monday (2/26) full info would be
available to callers, and those with FAX numbers could get immediate
detailed hard copy. (Those of us still relying on mail for hard copy
would immediately be sent appropriate materials, complete with many
pictures!!!)
The sessions are $275 for one day, $375 for both. Two decent hotels
will be providing rooms at $89 per nigtht, but there are no special
airline setups. (I got this info when they returned my call.)
Sessions go for the full day both days. I'm too feeble to type in a
full list of speakers, so call the 800 number (800/835-2246) if you
want additional info. (If you want to sign up, they take
MC/VISA/AMEX.)
The 800 number is provided by some 800 general service - I expect that
the conference will be run much more professionally.
Jon David
------------------------------
Date: 25 Feb 90 19:37:00 +0700
From:
[email protected]
Subject: How the 1554 virus recognizes infected files (PC)
Hi!
Since this was not mentioned yet (I hope, I receive the digests with
some delay), I would like to point out how the 1554 virus recognizes
which files are infected by him.
For .COM files:
If the contents of the word at offset 02 in the file is 12Eh,
then the file is infected. This means that the contents of the bytes
at offset 02 and 03 are 2Eh and 01h respectively. Offsets are counted
from 0, i.e. the first byte of the file is at offset 0.
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.
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.
Vesselin Bontchev
------------------------------
End of VIRUS-L Digest
*********************
Downloaded From P-80 International Information Systems 304-744-2253
