VIRUS-L Digest Thursday, 4 Jan 1990 Volume 3 : Issue 4
Today's Topics:
Virus biological analogy.
Where to Get Mac Anti-Virals
WHM on Spaffords Theorems
re: Virus Trends
Re: Shrink-wrap Licenses
Re: Anti-virus programs (Mac)
Re: Gatekeeper problems (Mac)
Disk Killer/ Ogre virus
re: The missing viruses (PC)
Spafford's and WHMurray's "Theorems"
8290 & Happy Birthday Jossie VIRUS
DES program (PC)
AIDS note (PC)
Re: Authentication/Signature/Checksum Algorithms
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: Wed, 03 Jan 90 14:28:55 +0000
From: "Pete Lucas" <
[email protected]>
Subject: Virus biological analogy.
The 'biological' analogy of a computer virus provides a useful model for
computer viruses: As a biologist who computes (rather than a computer
person) there are various things to consider::
1) Disease vector - diskettes, networks, cartridges, WORM disks etc.
2) Incubation period - how long between initial 'infection' and the symptoms
becoming noticeable.
3) Latency period - how long between infection and the infected machine becomin
g
able to pass on the infection to another machine.
4) Contagion - how rapidly does the virus spread once it has become activated
5) Damage - what is the severity of infection once it has been activated.
6) Reservoir of infection - the diskettes locked away in your drawer
for six months, that you 'thought' were clean!!
In biological terms, a 'successful' parasite (since that is what a
virus is) can adopt several strategies. It can be highly infective (so
it gets spread to many new hosts) but have a long latency period (so
the host shows no symptoms until it has been infected for a long
time), or it can be of low infectiveness with a short latency (so if
you catch it, you suffer immediately, but the chance of you catching
it in the first place is low anyway). Similarly, the harmfulness can
vary. Any parasite that is immediately fatal to its host is going to
get noticed, but if it has been able to pass on the infection before
it 'kills' the host, it will survive - similarly if the virus remains
infective after the host has died, it may still spread.
Computer-viruses we have seen so far tend either to be massively
infective, or have long latencies, or both. This leads them to be
noticed, and people write anti-virus software to combat them. A virus
that has a very long latency and low infectivity (so it spreads
slowly, unnoticed and unexpected because nothing untoward is
happening) but has a high damage-causing ability when triggered, is
probably the worst thing to contemplate, since it could become
established in a large population of machines unnoticed, then trash
the lot. I am thinking here of something with a latency of years -
what about a virus that triggers only on February 29th? The virus
that remains infective even after the 'death' of the host is with us -
your PC may have been crashed, but your diskettes may also be infected
and spread the infection to other machines even though you have
'disinfected' the originally infected machine. Diskettes will always
act as a reservoir to re-infect otherwise 'clean' machines.
Pete Lucas
[email protected]
------------------------------
Date: Wed, 03 Jan 90 09:35:09 -0500
From: Joe McMahon <
[email protected]>
Subject: Where to Get Mac Anti-Virals
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]:
PW ADD yourpassword
AFD ADD VIRUSREM PACKAGE PW=yourpassword
GET VIRUSREM PACKAGE
This will sign you up for updates and will send you the current
version of the package.
--- Joe M.
P.S. "yourpassword" should be 4 to 8 characters.
------------------------------
Date: Wed, 03 Jan 90 09:46:00 -0500
From:
[email protected]
Subject: WHM on Spaffords Theorems
In referring to my comments on Gene's theorems, Brian Piersel asks:
>What about infected programs uploaded to a BBS? If someone else downloads
>that program and uses it, their system will be infected with the same
>virus. In this case, the media has _not_ moved, which would indicate
>that programs are also a vector for viruses.
The operative words in my comment were "current vector." While there
always has been a potential for viruses to spread via BBSs, and while
one should be careful when using programs from such sources, that is not
what is happening NOW (examples to the contrary notwithstanding).
In one sense programs are always the vector. However, it is the sharing
behavior that creates the exposure. From a behavioral point of view, it
is the media that is being moved around. While the motive is to move
data, often but not always programs, the particular data to be shared is
incidental to the process of contamination. If the only spread that we
had to be concerned about was that which resulted from the deliberate
intent to share a particular infected program, we would be in good shape.
While all of the media hype refers to BBSs, they have not been a
significant vector. Much of the hype also talks about contamination of
vendor shipments. While there have been a few notable cases, this has
not been the major source of spread. Even where shrink-wrapped media
has been infected, it was usually after shipment and involved
distributors re-wrapping media that had been returned after use in an
infected machine.
It is important that we know what is really happening, as opposed to
hype, speculation, and potential.
William Hugh Murray, Fellow, Information System Security, Ernst & Young
2000 National City Center Cleveland, Ohio 44114
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840
------------------------------
Date: Wed, 03 Jan 90 09:05:51 -0500
From: "W. K. (Bill) Gorman" <
[email protected]>
Subject: re: Virus Trends
>> 2. The press speculation about the DATACRIME virus was much more
>> damaging than the virus.
>
>I don't think so.
I wonder how much such media slobbering tended to encourage subsequent
atrocities, such as the AIDS diskette? Quite a bit, I suspect.
------------------------------
Date: Wed, 03 Jan 90 12:59:56 -0500
From:
[email protected]
Subject: Re: Shrink-wrap Licenses
Recent discussion of the AIDS disk trojan has mentioned licenses that
come with software. I thought it relevant to post an excerpt (without
permission) of _How to Copyright Software_ by attorney M.J. Salone (3rd ed.
1989 Nolo Press, pages 12/2 - 12/3):
- ---------------------------------------------------------------------------
Software publishers often attempt to use a so-called "shrink-wrap
license" for the purpose of restricting rights of the purchaser. If you've
bought software over the counter, you'll be familiar with the sort of license
agreement that's printed on, or enclosed in, the packaging that says something
to the effect that if you break the package seal, you've agreed to the terms of
the license, which limits your rights to use the software. One common
restriction prohibits modifying the software in any way, even for your own use.
A federal court of appeals struck down a Louisiana statute that authorized this
type of provision on the ground the statute impermissibly conflicted with the
U.S. Copyright Act.*
Another way software publishers try to restrict the use of over-the-
counter software is to provide an "up-date" or "warranty" card with the
software. If you sign it, you not only qualify for the warranty
protection or update service offered, but simultaneously agree to the
terms of the "Software Licensing Agreement" included with the package.
This sort of agreement is not likely to be binding in a court of law.
The warranty offered is often required by law anyway, and the
"updates" are commonly not really updates, but error corrections which,
if uncorrected, would justify your requesting a full refund, or perhaps
even suing the publisher for negligence.
* Vault Corp. v. Quaid Software, 847 F.2d 255 (5th Cir. 1988).
- -------------------------------------------------------------------------
I wonder how many people know that they may be entitled to FREE
bug fixes or a refund when the software they buy is defective (i.e.
when the product does not perform as advertised).
In addition to the fact that the licenses may conflict with other
legislation I'd like to point out that many of those "agreements" are
probably not enforceable anyway, since the agreement is inside the box -
prohibiting you from reading it before allegedly agreeing to it.
David R. Brierley
[email protected]
------------------------------
Date: Wed, 03 Jan 90 15:09:59 -0500
From: "Chris Khoury (Sari's Son)" <
[email protected]>
Subject: Re: Anti-virus programs (Mac)
Reply to Mike on obtaining Gatekeeper, etc. You can get
Gatekeeper and a lot of other virus programs from
sumex-aim.stanford.edu if you have FTP access. Or thru the listserv on
bitnet, MACSERVE@PUCC, just type: TELL MACSERVE AT PUCC DIR ALL for
the whole directory if files. If you have any other questions feel
free to ask.
Chris Khoury
Acknowledge-To: <3XMQGAA@CMUVM>
[Ed. Also, the monthly information on how to access the comp.virus
archive sites will be sent out shortly.]
------------------------------
Date: Wed, 03 Jan 90 15:14:52 -0500
From: "Chris Khoury (Sari's Son)" <
[email protected]>
Subject: Re: Gatekeeper problems (Mac)
Reply to Sean Nolan on Gate Keeper Aid problems:
I had this problem recently too. The problem is in GateKeeper aid, it
locks up the finders resource so the finder can't access it (i think).
Anyways, there are to choices. You can try Eradicate'em, which does
the same thing, or GateKeeper Aid 1.0.1. This fixes that bug. Hope
this helps.
Chris Khoury
Acknowledge-To: <3XMQGAA@CMUVM>
------------------------------
Date: 03 Jan 90 22:12:47 +0000
From:
[email protected] (Brett G. Person)
Subject: Disk Killer/ Ogre virus
Had this little sucker hit my boss' computer yesterday and we don't
know how it got there. I got a report today from the local technician
who was trying to trace it down that it was even on the masters for
some of the software that was installed.. Neither one of us knows
anything about this thing. Could someone send me a tech doc on it?
Thanks
Brett G. Person North Dakota State University
uunet!ndsuvax!ncperson |
[email protected] |
[email protected]
------------------------------
Date: 03 Jan 90 00:00:00 +0000
From: "David.M..Chess" <
[email protected]>
Subject: re: The missing viruses (PC)
The "Falling Letters Boot Virus" is the name that we use around here
for the boot-sector virus that's also known as "the Israeli Boot Virus"
and "the Swapping Virus". Hope that clears that one up!
I've heard the name "Palette" used to refer to the 1536 or "Zero Bug"
virus. I've never been sure where that name came from; I think the
first infected file found was a palette utility, or something like
that?
Vaguely, DC
------------------------------
Date: 03 Jan 90 00:00:00 +0000
From: "David.M..Chess" <
[email protected]>
Subject: Spafford's and WHMurray's "Theorems"
Shouldn't these really be called "Hypotheses", or something along that
line? They've certainly not been proven! *8)
William Murray suggests some more, including:
> 6. The current vector for viruses is floppy disks and diskettes, not
> programs. That is to say, it is the media, rather than the programs,
> that are moving and being shared.
That's not particularly true, I don't think. Both disk/ette based
and program based viruses are spreading at the moment. The most
widespread virus in the PC area is the 1813 ("Jerusalem"), which is
program-based; its vector is program files (generally .EXE or .COM),
not media.
DC
------------------------------
Date: 04 Jan 90 02:39:48 +0000
From:
[email protected] (Balaji Pitchaikani)
Subject: 8290 & Happy Birthday Jossie VIRUS
Hi,
Has anyone heard about "8290" and "Happy Birthday Jossie" virues.
These virus are very popular in India. If you have any info on them
please post me details. I will summarize to the net, if there is
enough interest.
Thanks in advance,
Balaji
(
[email protected])
------------------------------
Date: Thu, 04 Jan 90 10:36:18 +0000
From:
[email protected] (Fridrik Skulason)
Subject: DES program (PC)
[email protected] (Timo Kiravuo) writes
> As to what this has to do with viruses, I don't know, but I think
> that a public DES implementation might be interesting enough to
> many people in the virus field, so maybe the moderator will be
> nice and let this pass.
There is a W-German DES program available for PC compatible computers.
It is called PC-DES, and is distributed as "charityware". It is
currently used by a number of people, including myself, when we have
to send "live" viruses in E-mail.
If anybody is interested, I can E-mail copies of it (xxencoded PKARC
file). Since I am located in Iceland, I am of course not restricted
by US regulations. Just be careful - if somebody in the USA receives
a copy, it is probably illegal so send a copy back out of country.
- -frisk
------------------------------
Date: Thu, 04 Jan 90 10:57:12 +0000
From:
[email protected] (Fridrik Skulason)
Subject: AIDS note (PC)
As far as I know, only one company has received the AIDS diskette here
in Iceland. The name of that company was not obtained from any of the
mailing lists already mentioned.
This company is the Toshiba computer distributor here in Iceland. The
name of this company appears in various ads from Toshiba, where it
contains one (minor) error. The label contained the same error, so it
is safe to assume that those ads were the source used. I assume that
other companies mentioned in the Toshiba ads also received the trojan.
And yes - They had thrown the envelope away, but said it had been
posted in Panama.
- -frisk
------------------------------
Date: Thu, 04 Jan 90 13:01:04 +0200
From: Y. Radai <
[email protected]>
Subject: Re: Authentication/Signature/Checksum Algorithms
In V2 #258 Ralph Merkle referred to previous discussions in this
group on authentication algorithms, and suggested his own one-way
hash function Snefru which has the advantage of not requiring secret
information and which has better performance than a DES-based system.
It's my understanding that the advantages of Snefru are its much
faster software implementation and possibility of larger key size than
DES, and several ways of choosing between greater security and greater
speed.
So Ralph Merkle recommends Snefru and Bob Bosen recommends the DES-
based X9.9 (he also mentions ISO 8731-2). And going outside of this
forum we find that Fred Cohen recommends an RSA-based algorithm, Ro-
bert Jueneman recommends his Quadratic Congruential MDC, Prof. Rabin
recommends the CRC algorithm using a randomly selected irreducible
polynomial, and so forth. Interestingly, none of these authors seems
to give any argumentation why his algorithm is any better than the
others (except for Merkle's comparison of Snefru with DES).
Bob Bosen says in Issue 265 that a sophisticated authentication al-
gorithm is clearly better than some programmer's guess at an authenti-
cation algorithm (he now adds the condition that both implementing
programs are well-written and convenient and "apply the algorithm
across all program code without exception").
I can't say that this is incorrect, but even with this addition, I
still don't share his emphasis on sophistication of the algorithm.
The added sophistication of (say) X9.9, compared to CRC with a person-
ally chosen generator, may be well worth the added time in the case of
authentication of bank transfers and other conventional applications.
But have you considered the possibility, Bob, that this sophistication
may be wasted when dealing with viruses?
If we were to try to draw a graph showing sophistication on the X-
axis and security on the Y-axis, I think everyone would agree that the
curve "levels off", i.e. there is a certain point, beyond which making
the algorithm more sophisticated has negligible value in increasing
security. The difference between the positions of Bob, Ross Green-
berg, and myself is partly where we think the curve levels off. Bob's
position is that this happens only at a late stage of sophistication,
while Ross seems to think it happens at a very early stage. My opin-
ion is that for *anti-viral purposes* this point is reached much ear-
lier than for more ordinary uses of authentication algorithms, though
not quite as early as Ross believes.
The reason I think the anti-viral situation is special is that in
this environment there are considerations which probably have no coun-
terpart in ordinary message authentication. For example:
(1) A virus must perform all its work, including circumvention of
anti-viral protection (e.g. forging of checksums) if that's what its
author desires, on the computer which it's attacking and in a very
short time (short enough so that it will not be noticed by the user).
(2) By its very nature, a virus is designed to attack a large per-
centage of the users of a particular system. From the point of view
of the virus writer, any technique which results in circumventing the
anti-viral protection of only a single user (or a very few users) is
not worthwhile, since if that were what he desired, he could achieve
the same thing much more easily by means of an immediate-acting Tro-
jan, and against that *no* alteration-detecting program, no matter how
sophisticated, can warn us in time.
(3) Ordinarily, a virus writer is not in a position to know what
checksum algorithms may be in use on the computers on which his virus
is unleashed. And any technique for forging the checksums of one al-
gorithm will probably not work against any other checksum algorithm.
Therefore a checksum-forging technique would increase the percentage
of disks infected by only a very small amount, making it a waste of
time and effort from his point of view. (An exception would occur if
the virus author is satisfied with attacking an environment which is
sufficiently limited so that most computers in it use the same check-
sum program.)
Taking these conditions, mainly (1), into account, it seems to me
that a checksum algorithm, expressed as a function F on files, will
provide sufficient security for anti-viral purposes if the following
two conditions are satisfied:
(A) For any given file f, F(f) is (in general) different for each
computer. (This condition amounts essentially to requiring a key
unique to each computer.)
(B) Given a file f, it is computationally infeasible (without know-
ledge of the key) to construct a file f' from it containing the de-
sired addition of (or replacement of ordinary code by) viral code such
that F(f') = F(f).
In making this claim, it is assumed that the checksum base, key and
program are kept offline (i.e. not located on an accessible disk or in
memory while a virus may be active), thus preventing discovery or com-
putation of the user's key or circumvention of the checksum program.
If the above opinion is correct, then I think that all the algori-
thms mentioned in the second paragraph of this posting are adequate
for anti-viral purposes, including the relatively unsophisticated CRC
algorithm if the generator is selected randomly or personally, and
hence the added sophistication of algorithms such as X9.9 is wasted in
view of the extra run time which they require.
Concerning speed, it can be argued that we shouldn't exclude slower
algorithms, since the more algorithms which are in use, the less
worthwhile it will be for anyone to try checksum-forging techniques.
On the other hand, if one algorithm has a clear superiority over the
others in speed, users are hardly likely to choose a slower algorithm
because of such an argument. And when speed is the issue it seems to
me that CRC, because of its greater simplicity, is better than any of
the more sophisticated algorithms satisfying conditions (A) and (B).
It's possible, of course, that I'm wrong on one or more opinions ex-
pressed above: Perhaps Dr. Merkle or some other crypto-expert can
show that conditions (A) and (B) are not sufficient even in the viral
environment expressed by (1)-(3) above, so that CRC, even with a ran-
dom generator, is insecure. Or that I'm wrong in assuming that such
a CRC satisfies these conditions. Or perhaps some other algorithm is
faster than CRC and no less secure. But what is needed is evidence
and argumentation relative to the *viral environment*, and this I
have not yet seen in Bob's writings.
I now come to Ross Greenberg's posting in Issue 266. Now I fully
agree with him that sophisticated checkers may go unused because of
the time required. But Ross implies that users will always prefer a
"good enough" fast checker like that of FluShot+ over a slow sophisti-
cated one. But can we be so sure that FluShot+ is really good enough?
How many of its users have the slightest idea how its security com-
pares with that of other programs? I don't know whether his algorithm
satisfies condition (B) above, but it certainly does not satisfy (A),
i.e. for any given file all users will get the same checksum, and
that's a potential security hole, at least in the "limited environment"
situation mentioned at the end of (3) above. But since this hole can
be plugged very simply and at no cost in speed, why not do so, Ross?
One final remark. Bob Bosen writes:
>In his mailing of Dec 07 '89, Y. Radai seems to be taking the position
>that since I am in favor of sophisticated authentication algorithms, I
>must be against sophisticated program implementations. Nothing could
>be further from the truth.
Such a position may indeed be far from the truth. But so is the no-
tion that I was taking such a position! I was not assuming that you
were *against* sophisticated program implementations; I was merely
concerned by your not having *mentioned* the need for very careful im-
plementation in a given system. That's a big difference.
Y. Radai
Hebrew Univ. of Jerusalem, Israel
[email protected]
------------------------------
End of VIRUS-L Digest
*********************
Downloaded From P-80 International Information Systems 304-744-2253
