VIRUS-L Digest Monday, 8 Jan 1990 Volume 3 : Issue 6
Today's Topics:
re: comment by William Hugh Murray
Re: Spafford's Theorems
Gatekeeper Privileges (MAC)
Questioning ethics at computing sites
The Amstrad virus (PC)
Re: Where to Get Mac Anti-Virals
Jerusalem B problem (PC)
Re: Authentication/Signature/Checksum Algorithms
Re: Virus Trends (and FAXes on PCs)
Alternative Virus Protection (Mac)
Murray's Theorems (Was Re: Spafford's Theorems)
Implied Loader 'Pack' Virus (Mac)
Re: Virus Trends (and FAXes on PCs)
Re: Viruses Rhyme And Reason
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., and sent to
[email protected] (that's
LEHIIBM1.BITNET for BITNET folks). Information on accessing
anti-virus, document, 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: Thu, 04 Jan 90 23:01:00 -0500
From: "Gerry Santoro - CAC/PSU 814-863-4356" <
[email protected]>
Subject: re: comment by William Hugh Murray
In V3 N1 of Virus-L Digest, William Hugh Murray wrote:
>2. The press speculation about the DATACRIME virus was much more
>damaging than the virus.
For the sake of academic argument I would dispute this. I agree that the
actual damage from Datacrime (or Oct 13 or whatever) was minimal, and
virtually nonexistent on our campuses, and I would also agree that there
was mucho media hype. However, I really think that there was a major
benefit to all of this.
As Mr. Murray correctly pointed out, much more users damage their own
data than are damaged by 'nasty' software. The Oct 13 scare made our users,
who number in the tens of thousands, FINALLY listen to our pleadings
to make backup copies of their software and data.
The situation is similar to that with seat belts. Few of us are actually
in an accident, but if we see one (or the effects) it may cause us to wear
the belts, which *may* save our lives. In the case of the Oct 12 virus
we had one grand chance to get people to listen to our message regarding
making backups and preparing for the chance of disaster, whether by
accident, ignorance, hardware failure or 'nasty' software.
-
-------------------------------------------------------------------------------
| | gerry santoro, ph.d. -- center for academic computing | |
| -(*)- penn state university --
[email protected] --
[email protected] -(*)- |
| | standard disclaimer --> "I yam what I yam" | |
-
-------------------------------------------------------------------------------
------------------------------
Date: Fri, 05 Jan 90 04:46:06 +0000
From:
[email protected] (John Campbell)
Subject: Re: Spafford's Theorems
[email protected] writes:
> 1. The amount of damage to data and availability done by viruses to date
> has been less than users do to themselves by error every day.
OK, OK. True enough, though we don't often like to be reminded of
this.
> 4. Viruses and rumors of viruses have the potential to destroy society's
> already fragile trust in our ability to get computers to do that which
> we intend while avoiding unintended adverse consequences.
This is the most worrying aspect of virus/trojan/worm infections.
We have a population which has no intrinsic immune system which
leaves itself open to such attack. Vectors now consist of
communications networks (BBS and other means) as well as physical
media. Since we are moving towards a networked future we will
need immune systems in our computers- society (all of us) are
currently subject to these terrorist acts (like the tylenol
scare). Remember- any linchpin/choke point in technology, be
it transportation, food delivery, water supply, communications
is subject to interruption by killers. Set some of these loose
in a Hospital and the virus writer is _at least_ as dangerous
as the individual who slips cyanide into food and drug products.
> 5. We learn from the biological analogy that viruses are self-limiting.
We also learn that when the population is large enough for the
entity to take advantage of, an entity will attempt to take
hold. Once we had standard PC's (and Macs, Amigas, etc) we
then had a "fixed" cellular mechanism to subvert. S-100 systems
which lacked such standardization were not subject; even the
"standard" S-100 systems did not constitute a large enough
population to invite attack...
> Clinically, if you catch a cold, you will either get over it, or you
> will die. Epidemiologically, a virus in a limited population
> will either make its hosts immune, or destroy the population. Even in
> open population, a virus must have a long incubation period and slow
> replication in order to be successful (that is, replicate and spread).
Point taken. A virus, since it _does_ act in the system as
non-invasively as possible (beyond spreading its "genetic code"
wherever possible) will be fairly successful. Subtlety pays
off. Of course, these viruses are much like the HIV will eventually
kill the host...
- --
John R. Campbell ...!uunet!lgnp1!penrij!soup (
[email protected])
"In /dev/null no one can hear you scream"
------------------------------
Date: Fri, 05 Jan 90 07:57:45 -0500
From:
[email protected]
Subject: Gatekeeper Privileges (MAC)
Hi,
Before I install Gatekeeper, I was wondering if anyone knows
the set of privileges required by the TextPac and PublishPac software.
We are using a Dest page scanner in our public access lab. The device
is configured SCSI in order to talk to the MAC II so I think I'm correct
in assuming that in order to scan text and pictures the software will
need to do all sorts of low level stuff.
Anyone else out there with Gatekeeper and a Dest scanner installed?
Andy Wing
Senior Analyst
Temple University School of Medicine
------------------------------
Date: Fri, 05 Jan 90 09:28:30 -0500
From:
[email protected]
Subject: Questioning ethics at computing sites
I write this commentary on ethical issues concerning the dissemination
of information about the existence of viruses and how to get rid of
them as both an employee of the University of Michigan and as a
concerned member of the UM community. The following scenario
describes the events leading up to my questioning the ethicality of
the procedures (or more appropriately, the lack of procedures) here.
Finally, I ask for comments and suggestions (e.g. how informing the
public is done at your institution) with hopes that the UM policy
makers are listening.
I recently joined the ranks of the many computer experts employed at
the University of Michigan. About 1 month after I started working
here, I became familiar enough with downloading Mac files from a
public file to notice that there was a new version of Disinfectant. I
downloaded it and noticed the report of the WDEF virus. I checked my
personal disks as well as the school owned disks in my public lab ---
all were infected with the WDEF virus. I sent an e-mail message to
the online_help people (most of which are student "consultants"),
asking them what was to be done. It was apparent from the response,
that the virus had been here such a short time (a few days?) that no
one was doing anything yet. I expected a public announcement of some
sort informing users that they may be infected and that they run the
risk of being infected when they use the UM public facilities. No
announcement was made. Furthermore, as a specialist employed to
preside over a public computing facility (most of the computers are
Macs), I expected to be both informed that there was a new virus as
well as instructed what to do about it I heard nothing. Two weeks
after the WDEF virus hit UM, most users were still not aware of it. I
sent an e-mail message to my most immediate contact in the Information
Technology Division expressing my concerns. "Shouldn't the public be
informed," I asked. I expected a response from him and hoped that he
would forward the message on to the appropriate policy makers if he
was not in the position to deal with it himself. I have not received
a response to my message nor have I heard any public mention of the
WDEF virus. Users continue to infect the disks in my lab and be
infected by the disks in my lab and, as far as I know, other public
facilities at the Universtiy of Michigan. The virus persists here.
What should be done to rid UM of the WDEF virus or of any virus for
that matter? How does the bureaucracy at your institution handle it?
I question the ethicality of a laissez-faire attitude on viruses at
any institution.
Jeff Spitulnik
------------------------------
Date: Fri, 05 Jan 90 12:13:27 +0000
From:
[email protected] (Fridrik Skulason)
Subject: The Amstrad virus (PC)
I mentioned the Amstrad virus in a recent posting, saying that "..it
has nothing to do with Amstrad computers...". It now appears that it
does.
The original (unmodified) version of the virus contains an
advertisement for Amstrad computers. This text was replaced by a
short message to John McAfee, when the virus was first uploaded to
HomeBase. The name appearing in my original note about the virus is
therefore not the name of the author, but instead the name of a
respected professor in Portugal.
- -frisk
------------------------------
Date: 04 Jan 90 19:04:45 +0000
From:
[email protected] (Brian Gordon)
Subject: Re: Where to Get Mac Anti-Virals
[email protected] (Joe McMahon) writes:
>Hi, Mike.
>
>We've set up an automatic distribution service here at Goddard. You
>can sign up by sending mail containing the following text to
>
[email protected]:
> [...]
Assuming this is available to those of us on usenet, not just bitnet, can you
post a path to "scfvm.gsfc.nasa.gov"? It doesn't appear to be findable from
my maps. Thanks.
[Ed. I believe that ...!uunet!scfvm.gsfc.nasa.gov would do the trick.]
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Brian G. Gordon
[email protected] (if you trust exotic mailers) |
| ...!sun!briangordon (if you route it yourself) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
------------------------------
Date: Fri, 05 Jan 90 18:24:23 +0000
From:
[email protected] (Andreas Pikoulas)
Subject: Jerusalem B problem (PC)
Can someone tell me how do I get rid of the Jerusalem B virus
without getting rid of the infected program too?
I remember someone told me that i have to edit some specific sectors of the
disk in order to deactivate the virus.
Thanks in advance
A n d r e a s
Andreas Pikoulas| UUCP :{uunet|watmath|utai|garfield}!cs.dal.ca!aucs!861087a
TOWER 410 | E-MAIL :
[email protected]
WOLFVILLE-NS | Phone(voice) : (902) 542-5623
CANADA B0P 1X0 | ------- IF YOU CAN'T CONVINCE THEM, CONFUSE THEM. --------
------------------------------
Date: 05 Jan 90 17:26:20 +0000
From:
[email protected] (RSA Data Security)
Subject: Re: Authentication/Signature/Checksum Algorithms
In response to Y. Radai's post:
To protect against viruses, the best protection can be obtained by
using a fast hashing algorithm together with an assymetric
cryptosystem (like RSA). This is also by far the most cost-effective
(based on compute-time) approach.
A good "message digest" should be a one-way function: it should be
impossible to invert the digest and it should be computationally
infeasible to find two useful messages producing the same digest in
any reasonable amount of time. The algorithm must read every bit of
the message. Therefore, the best one is the fastest one deemed to be
secure. This should not be left to individual users to develop as
Jeunemann and Coppersmith, among others, have shown that this is not
a trivial undertaking. Let's use Snefru and MD2 (Internet RFC 1113)
as examples of good ones.
The digest attached to a program or message should then be encrypted
with the private half of a public-key pair. What is the
computational cost of enhancing this process with public-key?
Since RSA can be securely used with small public-key exponents such
as 3 (see Internet RFC's 1113-1115 and/or CCITT X.509) a small number
of multiplies is required to perform a public-key operation such as
*signature verification*, where one decrypts an encrypted digest with
the public key of the sender (and then compares it to a freshly
computed digest). Therefore, the "added" computational cost of using
RSA on an AT-type machine is approximately 80 milliseconds (raising a
512-bit number to 3 mod a 512 bit number) REGARDLESS of the size of
the file being verified (the digest is fixed, and less than 512 bits,
requiring one block exponentiation). Of course the 80 ms gets
smaller on faster machines like Suns. I think anyone would agree
that that is a fair tradeoff for signer identity verification. Since
one "signs" files only once, this "cost" is irrelevant. The cost of
verifying, over and over, is what is important.
So what do you get for your milliseconds? You always know the source
of the digest (and you get non-repudiation, providing an incentive to
signers to make sure programs are clean before signing them). No one
can change a program and recalculate the digest to spoof you. If
schemes like this became widespread, the lack of signer
identification would be a hole people would quickly exploit. You
also get a secure way to *distribute* software over networks. Pretty
hard to do if everyone "does their own thing". The Internet RFC's,
if widely adopted, provide a perfect mechanism for this.
Regardless of the hashing algorithm employed, there are powerful
benefits available if RSA is used with it. And the computational
cost is negligible.
It may be true that simpler methods are adequate for some people.
That determination requires a risk analysis, and people will make
their own decisions. It has been shown, however, that if a system
can be defeated, it will be. Certainly secure software distribution
requires something more than an unprotected hash, since keys will
presumably not be shared. This is where public-key has the most
value.
Using X9.9 is OK if (1) you trust DES (2) can live with its speed,
and (3) don't need to distribute trusted software in a large network.
X9.9 key management becomes a serious problem in a network like the
Internet. It does have the advantage of being a standard, but it was
developed for a relatively small community of wholesale banks, not
large networks. Note aboput standards: RSA was named as a supported
algorithm in the NIST/OSI Implementor's Workshop Agreements (for
strong authentication, in the Directory SIG) of December 1989.
Jim Bidzos
RSA Data Security, Inc.
------------------------------
Date: 05 Jan 90 20:07:02 +0000
From:
[email protected] (Kelly Goen)
Subject: Re: Virus Trends (and FAXes on PCs)
[email protected] (Ralph A. Shaw) writes:
>
[email protected] says:
>
>> - A FAX message is a bitstream interpreted by an interpreter at
>> the receving end. Could it be induced to do something interesting
>> through the use of illegal bit patterns? Group III is probably too
>> simple to be attacked, but group IV? Imagine a message which
>> causes a FAX machine to send an extra copy of transmitted documents
>> to another location.
>
>Something that has come to the attention of security paranoids here
>lately is that some manufacturers of PC FAX boards have added a
>feature that allows the FAX modem to be used as a bisync modem to
>communicate with the PC directly, rather than transmitting just FAXes.
>
>I assume the PC would have to be running some software to enable it
>and reassign the console (requiring local intervention), but a
>networked PC could then prove to be a leak onto the corporate network,
>(or at least, for handy distribution of the Trojan-of-the-month program).
>Added to this is the promise that at least one FAXboard vendor
>promises that both async and bisync modem capability will be available
>in the future.
- -I would have clipped more of this but this is a complex subject that merited
serious consideration unlike the infamous modem virus scare of 1988....
actually while a receiving process has to be available on the machine to
be infected(i.e. either the legitimate file transfer program
or a masquerading process
using this as a means to load further extensions of itself)...the important
point to remember here is that g-3 and g-4 fax formats are from what some of
techs have told me on alt.fax are internally, modified dialects of HDLC
so in this case it is possible that a sufficiently sophisticated infectious
process could use this as a pipeline to load further updates to code...
(i.e. new ways to defeat anti-viral nostrums) I will post ISBN numbers
on the protocol definitions when they finally arrive...as to whether this is
a probable scenario... who knows
cheers
kelly
p.s. AS I dont want to cause anyone unecessary worry let me remind all
once again that a receiving process HAS to be on the receiving machine
if it is not the legitimate File XFER program then it is illegitimate
in any case....the point that I am trying to clarify that while
an infectious process could use this as a conduit to an ALREADY EXISTING
infected host... unless there is a way to force execution of the received
code then your virus will lay dormant(i.e.nonexecutable) because of some
fax type file extension on msdos...typically something like .FAX .PIC .PCX
etc....get the picture??? on *nix type systems the problems faced
by the theoretical COMPUTER/FAX-MODEM infectious process are simpler in some
ways but require even more cooperation from receiving processes...
------------------------------
Date: Fri, 05 Jan 90 17:12:07 -0500
From: "Chris Khoury (Sari's Son)" <
[email protected]>
Subject: Alternative Virus Protection (Mac)
Is there any alternative virus protection, detection init/cdev
besides vaccine and gatekeeper? I need to save space on my disk, so
gatekeeper is too large, but vaccine does not protect me disk from
the other virus's besides Scores and nVir. Any suggestions? I would
prefer that the program is shareware/PD.
Chris Khoury
Acknowledge-To: <3XMQGAA@CMUVM>
------------------------------
Date: 03 Jan 90 22:59:29 +0000
From:
[email protected] (Edwin Wiles)
Subject: Murray's Theorems (Was Re: Spafford's Theorems)
[email protected] writes:
>
>1. The amount of damage to data and availability done by viruses to date
>has been less than users do to themselves by error every day.
Granted. However, self-inflicted damage is generally recognized much sooner,
and is often much easier to repair. Perhaps more time consuming, but easier
because the user generally needs no special tools that he does not already have