VIRUS-L Digest Tuesday, 13 Feb 1990 Volume 3 : Issue 40
Today's Topics:
RE: AIDS Trojan - self protection
The ethics of virus eradication
VSUM9002.ZIP (PC)
Copyrights
Many WDEF reports (Mac)
Re: The AIDS "Trojan" is a Copy Protection System
The AIDS "Trojan" is a Copy Protection System
Re: WDEF and AppleShare (Mac)
Re: Re universal detectors.
Re: Signature Programs
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: Tue, 13 Feb 90 09:49:01 -0500
From: woodb!scsmo1!don%
[email protected]
Subject: RE: AIDS Trojan - self protection
> 1. That all of the users who were adversely affected by this
> supposed trojan either (a) did not read the license
> agreement for the program which they were installing, or (b)
> they read it and ignored it. Either way, they must accept
> the consequences. The installation instructions first step
> tells you to read the agreement on the reverse of the sheet.
I agree, this is the most common practice. You get this great
software and you want to see it RIGHT NOW! Well, one DOES need to
read those agreements and take them at face value.
> I am stunned at the sheer volume of pointless garbage that this
> program has generated, and it makes me seriously doubt any other
> information received from these "experts". I would also point out
> that self-destructing programs are not new, but one has never caused
> such an outcry before.
Agree... but... Self-destructing programs should and generally only
destruct THEMSELVES! If you rent-to-own a tv from 'Bob's Rent-to-own'
and don't pay Bob anymore to use the tv, Bob HAS the right to come and
get his tv. But because you didn't pay for the tv, this does NOT give
Bob the right to take your whole house!
If this AIDS program was in the up and up he would have sent out
requests for the program. It would have saved him money, time and a
whole lot of headaches. His method WAS blackmail and he should get
all the jail time and penalties comming to him!
DON INGLI-United States Department of Agriculture - Soil Conservation Service
INTERNET:
[email protected] PHONEnet: 314!875!5344
UUCP(short): uunet!scsmo1!don UUCP(long): uunet!mimsy!woodb!scsmo1!don
These are my opinions. I represent myself.
Who do you think you are, Bjorn Nitmo? David Letterman '90 Catch Phrase
------------------------------
Date: Tue, 13 Feb 90 10:08:00 -0500
From: <
[email protected]>
Subject: The ethics of virus eradication
I am posting the story of this incident to VIRUS-L in order to elicit
your comments. Has anyone run into a similar circumstance?
This week (Feb 5th-9th, 1990) marked the first occurrence of PC
computer viruses on our campus. First our Library received the census
disk, which we were warned of, and secondly a faculty member was
infected by Jerusalem B. I was able to clean-up this system with some
effort in about an hour. This was the last thing I did on Thursday
afternoon. On Friday, I posted mail to all campus mainframe account
holders (most of our campus users since our PC network is just in the
beginning phase) about the two incidents, and how to avoid virus
infections. In this E-mail message, I was particularly careful not to
mention the name or department of the faculty member involved.
Well, that didn't work. The faculty member was extremely angry about
the E-mail message. I did mention the type of program that was the
supposed virus vector. He contended that anyone on campus would figure
out his identity from the type of program (fractals), since he was
teaching a continuing course on the subject. I won't go into the
details of the venom that was directed my way.
My questions are these - what should I have done? Kept the infection
secret? Are computer viruses a Social Disease? Are we physicians who
are supposed to swear some form of Computerized Hippocratic Oath of
confidentiality? Or, do we paint a Scarlet-V on the heads(or
terminals) of those unfortunate ( careless enough) to become infected?
I would like to hear of similar experiences and policies enacted to
deal with virus infections.
[^^^^^] [^^^^^] [^^^^^] [^^^^^] [^^^^^] [^^^^^]
[ ]______[ ]______[ ]______[ ]______[ ]______[ ]
[ Alan N. Federman, Computing and Data Processing, Indiana U.-Purdue U.]
[ 2101 Coliseum Blvd. E., Fort Wayne, IN 46805-1499 ]
[ FEDERMAN@IPFWCVAX <- BITNET (219)481-6199 ]
[----------------------------------------------------------------------]
------------------------------
Date: Tue, 13 Feb 90 09:52:58 -0600
From: James Ford <
[email protected]>
Subject: VSUM9002.ZIP (PC)
The following file has been added to MIBSRV.MIB.ENG.UA.EDU (130.160.20.80)
for access via anonymous FTP in the directory pub/ibm-antivirus.
VSUM9002.ZIP - Virus Information Summary List (February 03, 1990)
Text file (ZIPed) of virii known. Downloaded from
Homebase on 02/09/90
- ----------
James Ford -
[email protected],
[email protected]
[Ed. The unzipped version of this file, virussum.doc, is available on
cert.sei.cmu.edu (IP number 128.237.253.5) in pub/virus-l/docs.]
------------------------------
Date: Tue, 13 Feb 90 12:43:00 -0500
From: <
[email protected]>
Subject: Copyrights
It has been noted that the author of a virus has an implied copyright
on the work. However, this will only be of any significance if the
author enforces the copyright by suing anyone who distributes the source
code without permission. But -
1. Is the copyright enforceable if the author cannot be located with
a reasonable search?
2. Who would claim ownership of a "released" virus? There might be
a small benifit from suing over copyright infringement, but
but the author would be sued for a much larger amount for
writing the virus and releasing it.
Also, the benifits of distributing source code (so that anti-virals can
be written) would probably legally outweigh the copywrite ownership case.
------------------------------
Date: 13 Feb 90 00:00:00 +0000
From: "David.M..Chess" <
[email protected]>
Subject: Many WDEF reports (Mac)
Curious as to why we're seeing all these WDEF reports, and not similar
numbers of reports of other widespread viruses. Has it just become a
tradition to report WDEF on VIRUS-L, or is WDEF better at spreading?
If the latter, does anyone have a good feeling for what about WDEF
makes it so (um) virulent? DC
------------------------------
Date: 13 Feb 90 17:40:35 +0000
From:
[email protected] (David Legg)
Subject: Re: The AIDS "Trojan" is a Copy Protection System
[email protected] (Ian Farquhar) writes:
>For several weeks we have been monitoring the discussion in comp.virus
Quote of license agreement, summary of warning in same, and the
conclusion that this is merely an elaborate copy protection scheme
deleted for brevity.
I too have been following the discussion, and while Mr. Farquhar
presents a some reasonable comments, I think he should consider the
following.
A. The disks were unsolicited material.
In the US, that means the receiver owns them free and clear,
no matter what "agreement", invoices or other demand for
payment is made. What is the australian (and other target
countries) law in this regard.
B The "COPY PROTECTION" prevented all subsequent use of the entire
computer system, but only after it had been executed.
It would not prevent copying the master disks on an
unaffected system, nor would it have prevented the execution
of those copyied disks on other systems. Ususal copy protection
either prevents copying the master, or makes the copies useless
on other systems.
C For it to be "COPY PROTECTION" system, there must be something
real to protect, I have not seen any mention of anyone
finding any real programs or information on the disk.
(The survey program I saw mentioned seemed to be more
of a quick and dirty mockup than anything else.)
C This is not another instance of a program which will self-destruct
if used in an unlicensed environment. It effectively destroyed
the entire computer environment. As Mr. Farquhar states, this
might have been a recoverable event, we dont know if PC Cyborg
would have sent a fix-up disk in response to payment,
this is extortion.
If PC Cyborg was really interested in leasing software about aids, there
are well established methods for advertising, making demo versions, etc.
The sophistication of the methods they employed demonstrates the level of
skill and knowledge they have. The effects on the computer systems are
intentional, not the results of faults in the code as in the case of many
viruses.
The cost of mailing the disk was significant.
Therefore I think we can be sure that the authors knew exactly what they
were doing and expected a large financial return for thier efforts.
Disclaimer: These are my own opinions and not necessarily those of my
employer.
Dave Legg |Internet: legg%
[email protected]
Radiation Research Lab |UUCP: ...!ucrmath!proton!legg
Loma Linda University Medical Center
Loma Linda, CA 92354. (714) 824-4075
------------------------------
Date: 13 Feb 90 13:08:00 EST
From: "zmudzinski, thomas" <
[email protected]>
Subject: The AIDS "Trojan" is a Copy Protection System
In Virus-L V3 #38 Ian Farquhar writes:
..
> If the author of this program is convicted, it will be the first
> conviction ever for the hidious crime of writing a copy protection
> system, and will be one of the biggest farces of justice ever
> witnessed.
Zapping a hard disk and calling it copy protection is overkill.
One is generally not allowed to use lethal force to protect mere
property. (You may kill in self-defense, and you may defend your
property, thereby making "self-defense" more likely, if that's
your karma.) Rigging lethal deadfalls is a no-no (it's called
"reckless endangerment" and similar verbage).
Justice Holmes wrote that your right to swing your fist ends at
the tip of my nose. The right to protect a person's intellectual
property must end when it damages another's physical property.
I consider most copy protection to be just that, a hidious crime.
If I can't make my own back-up copy of a program, I feel that the
vendor is responsible for providing me with a replacement when
the original disk fails. Ideally this should be at no charge,
including the prepaid return-mailer that would hold the failed
disk -- and if we're talking about an applications package that
I've become dependent upon (choose any software you'd hate to be
without for 36 hours), I want damages!
^^^^^^^
................................................................
: Tom Zmudzinski : "In just causes, there are no failures, :
: DCS Data Systems : only delayed successes." - Robert Sheckley :
: McLean, VA : "Why do I feel overly successful?" - me :
:..................:............................................:
------------------------------
Date: Tue, 13 Feb 90 10:55:42 -0800
From:
[email protected]
Subject: Re: WDEF and AppleShare (Mac)
Peter W. Day writes:
> Re the discussion of infection of AppleShare servers by WDEF and
> whether to run GateKeeper there, and Brian Bechtel's point that the
> server does not use its desktop file, so the disktop file can be
> removed, after which the server can not be infected by WDEF.
>
> Even if you leave the file "desktop" on the server, that file is not
> seen by clients (even using programs that can see the desktop file on
> local disks), so it appears that there is no way a client can infect
> an AppleShare server with WDEF.
This is an incorrect conclusion.
If an AppleShare server publishes a disk which contains a Desktop file,
client systems CAN see the Desktop file. If a client system is infected
by WDEF, it _will_ attempt to open and infect the Desktop file on the
server. If the client was granted "Make changes" permission for the
volume itself, WDEF will be able to infect the Desktop file on the server
volume. This infection-process causes the server's Desktop file to be
updated by the client's Resource Manager... it can generate a very large
amount of network activity, and "lock up" the client for an extended
period... 15-30 seconds is not unusual. This performance-degradation
is one of the warning signs of a WDEF infection. Trust me... this DOES
happen!
This infected Desktop file will not, however, be capable of infecting other
clients. The Finder on a client machine does not attempt to open the
Desktop file on the server... instead, it uses AFP services to fetch
icons and bundle information from the AppleShare server (which uses
the Desktop Manager interface to retrieve them from the Desktop Manager
database files).
This doesn't mean that the infection is benign, though. If you reboot
the server from a floppy (or other volume) which does not contain the
Desktop Manager INIT, the "latent" infection in the server's Desktop file
will become active.
> Clearly you could do so by putting an
> infected diskette in the server when it was running as a workstation
> (e.g. by booting it using an infected diskette). But could you infect
> the server by inserting an infected diskette in it while it was
> running as a server?
Yes. An infected floppy could infect the Desktop file on the hard disk,
even if the Desktop Manager were running. This is another way to create
a "latent" WDEF infection.
> Once infected, will the server infect local disks
> of clients?
Nope... as mentioned above, the Finders on the client machines do not
open the Desktop file on the server.
The best ways to ensure that your AppleShare servers do not become
infected (by clients, or otherwise) are:
1) Install a Desktop-scanning INIT, such as Gatekeeper Aid, Eradicat'Em,
or an up-to-date version of one of the commercial antivirals. This
will ensure that infected floppies are cleansed when inserted, and that
any infection which _does_ sneak in will be cleansed when you reboot.
2) Do NOT grant AppleShare clients the "Make changes" permission to the
root directory on a published volume. Make all changes to this
directory from the server itself. Grant "Make changes" permission
only to lower-level directories. This will ensure that an infected
client is unable to update the Desktop file on your server's volume.
Remember that a Desktop file will be created on your volumes if you boot
from ANY disk which doesn't have the Desktop Manager INIT in its System
folder. You should NOT simply install Desktop Manager, delete the old
Desktop file, and assume that you are safe from infection... this method
is not reliable!
- --
Dave Platt VOICE: (415) 493-8805
UUCP: ...!{ames,apple,uunet}!coherent!dplatt DOMAIN:
[email protected]
INTERNET:
[email protected],
[email protected]
USNAIL: Coherent Thought Inc. 3350 West Bayshore #205 Palo Alto CA 94303
------------------------------
Date: 13 Feb 90 19:50:21 +0000
From:
[email protected] (Lambert Meertens)
Subject: Re: Re universal detectors.
[email protected] (GEORGE SVETLICHNY) writes:
) I'm actually mixing mathematics and technology in the above. The purely
) mathematical conjecture would be (having defined "virus" in some
) appropriate useful way): There is a decidable set W such that 1) all
) programs containing viruses are in W and 2) all programs that do not
) contain viruses *have an equivalent* (identical input-output behaviour)
) that is not in W. Program equivalence is undecidable so this does not
) contradict the undecidability of virus detection. The technological
) part would consiuAof expressing W in some convenient way through
) hardware architecture.
)
) Is this plausible? Frankly, it doesn't sound so to me, but I wouldn't
) discard it off hand. It's the only hope I see of some general
) mathematical result being useful for anti-viral strategies, so maybe we
) should look at it more closely.
To make this amenable to mathematical analysis, we need a precise
definition of "virus", of course, but I think that even without such a
definition there is an argument that makes it plausible that this *is*
in fact mathematically possible.
The argument assumes that we have at least a decidable after-the-fact test
that determines whether a program displayed, in its actual behaviour during
a given run, undesirable (virus-like) behaviour (whether by a bug or by
malicious intent of its author).
(N.B. I don't know if we can give a useful formal definition of what
constitutes undesirable behaviour, but if we cannot capture this notion,
then any hope of creating a universal virus detector is vain.)
Moreover, it assumes (typical mathematical assumption) that we have
unlimited storage.
Given a program P, we can create another program P' which works as
follows (sketch only):
1. Make a copy of the store.
2. Operate like P, without touching the copy.
3. On termination of P, determine whether undesirable behaviour occurred.
4. If so, restore the store from the copy and flash a red light;
otherwise, erase the copy and display a green light.
(There could be an option to have a bell rung instead of the red
light:-)
(In case the program does not terminate, we can press an abort button
whereupon the store is restored as well.)
The point is that there is a computable function F such that F(P) = P' with
the above characteristics, such that the range of F is a recursive set.
(The argument that F is a recursive function is simply that it is obvious
how to write a program for it. That the range is recursive follows from
the fact that we can easily construct F such that larger input -- in some
suitable ordering -- gives rise to larger output, so to test if Y is in the
range of F we can enumerate the domain of F until we find an X such that
|F(X)| >= |Y|.) Take the set W to be the complement of the range of F.
All benign programs have an equivalent program in W-complement, since F
does not change their input-output behaviour, and all programs in W-
complement are by their construction harmless.
I do not see how this theoretical construction would have much relevance,
but it is amusing to realise that the gist of it is to make a full backup
before you run a non-trusted program, which is indeed a good thing. Now if
only we could timely detect that infection did occur, then it would be easy
to restore and stop the spreading.
- --Lambert Meertens, CWI, Amsterdam;
[email protected]
------------------------------
Date: Tue, 13 Feb 90 17:08:07 +0200
From: Y. Radai <
[email protected]>
Subject: Re: Signature Programs
There have been a few responses to my postings on signature (or
checksum) programs and algorithms in V2 #256 and V3 #4, resp., mainly
by Bob Bosen. Let me begin by briefly summarizing my earlier postings:
In the first posting I pointed out that what has to ensure security
on a computer is not simply an algorithm, but rather a *program* which
implements it in a given operating system. And even a program based
on the most sophisticated checksum algorithm in the world is circum-
ventable if it is not written very carefully, since there are liable
to be (and in PC-DOS/MS-DOS definitely *are*) loopholes in the system
which are independent of the checksum algorithm and which a virus
writer could exploit.
Bob Bosen responded to this point only by saying that in the compa-
rison of algorithms, both implementing programs must be well-written
and convenient and "apply the algorithm across all program code
without exception". Well, that last phrase may suggest to some people
that it's necessary to checksum the boot sector and partition record
also, but otherwise, this requirement is insufficient, at least as I
understand Bob's words. And even if we interpret it in such a broad
manner that it becomes theoretically correct, this rule is rather
useless; it gives the checksum-program writer no clue whatsoever as
to how to plug most of the loopholes.
I considered, and still consider, this emphasis on the implementing
program, rather than on the algorithm, to be fully justified. One
way of putting it is that given a choice between a sophisticated algo-
algorithm with poor implementation and a mediocre algorithm with good
implementation, I would prefer the latter.
Of course, it's not really an either-or matter; there's nothing to
prevent us from striving for quality in *both* aspects. And as long
as one is aware that a naive implementation of an algorithm is very
dangerous, and is aware of the great difficulty of conceiving of all
of the loopholes, I suppose it makes sense to ask which of several
algorithms is best, given the *assumption* that all are implemented
equally well. So in my later posting, I suspended discussion of im-
plementation and restricted myself to algorithms. I mentioned six of
them and expressed the opinion that for anti-viral purposes (which I
characterized by three properties but there are actually more), any
algorithm which satisfied a certain pair of conditions should be suf-
ficiently secure. I considered the best algorithm to be the fastest
of those satisfying these two conditions, my guess being that this
would be CRC. However, I specifically mentioned three points on which
I might be wrong. I concluded by challenging people to supply evi-
dence and argumentation relative to the viral environment.
Bob Bosen took up my challenge as far as argumentation is involved:
> Specifically, in his opinion (1), Mr. Radai says that a
>virus must perform all its work ... "on the computer which it's attacking
>and in a very short time". That is not necessarily true. In networked
>environments with shared file systems, (and especially if remote
>execution is available), viruses could execute on different computers and
>take as much time as they needed. Also, as pointed out by Bill Murray,
>viral infections during the process of software distribution may be done
>off-line at the convenience of the attackers.
But as Bill correctly pointed out, we have in mind two different ap-
plications of authentication software: (I) for recognizing contamina-
tion of the program in the target execution environment; (II) for en-
suring that programs are received as they are shipped. (II) is un-
doubtedly important, but my articles were concerned only with (I)
(sorry I didn't state this explicitly), hence Bob's reference to in-
fection during software distribution is not relevant to my remarks.
As for networked environments, he's right, there are *some* such
environments in which property (1) would not hold. However, the
average user does *not* operate in such an environment. Why should
*he* choose a slow program just because it adds security in *such* an
environment?
>I must also disagree with Mr. Radai's opinion (2), wherein he posits "By
>its very nature, a virus is designed to attack a large percentage of the
>users of a particular system." Why? What's to prevent a virus writer from
>launching a "surgical strike" against a small population of familiar
>computers that are known to control assets or information of great value?
I must say I find this response rather surprising, considering that
the answer to your question is contained in the continuation of the
very same paragraph from which you're quoting me. In case it wasn't
clear, I'll rephrase that answer: There's nothing at all to prevent
such a strike, but if such a strike is made, there's no reason why it
has to be a *viral* strike. The great advantage of writing a virus,
as compared to an ordinary immediate-acting Trojan horse (which I'll
abbreviate here to simply "a Trojan") is that by delaying its damag-
ing effects and replicating itself, it can spread rapidly to a large
population of users and thus ultimately cause damage to many more
users. But it has the disadvantage that the delay of damage gives
checksum programs a chance to detect the infection. Now if you're
talking about performing damage to only a *small* population, then
there's not much advantage to writing a virus rather than a Trojan.
A Trojan is easier to write and can't be detected by a checksum pro-
gram. So to your question of what's to prevent a viral strike against
a small population, I counterpose the question What's to prevent a
*Trojan* attack against a small population? What could your sophisti-
cated algorithm do against that?? The answer is Nothing. Even ISO
8731-2 raised to the X9.9-th power would be helpless against an imme-
diate-acting Trojan.
>As to Mr. Radai's opinion (3), he says that "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." That's true TODAY. ....
> .... But if our society is
>ever going to overcome its current vulnerability, we'll need reliable,
>low-cost defense mechanisms that are worthy of widespread use. This
>implies a necessity for economies of scale. Therefore, this opinion (3)
>will not necessarily be true for very long.
I appreciate this looking to the future (which is why I mentioned
loopholes which have not yet been exploited in any existing virus).
However, I'm less enthusiastic about this particular point. I presume
that when Bob talks of the need for "reliable low-cost mechanisms" and
"economies of scale" he is referring to his previously expressed opin-
ion that someday there may be only a few high-quality programs used
by millions of people. Frankly, I find the "few" part of this rather
unlikely. If anything, the trend seems to be in the opposite direc-
tion. (For example, there's a new algorithm MD4 which has been de-
scribed by Ronald Rivest.) And even if the situation envisioned by
Bob should someday arise, I think it would still be quite difficult to
exploit.
In any case, properties (2) and (3) were less important to my case
than (1). And there's an important fourth property of the environ-
ment which I neglected to mention. Almost all types of attacks pro-
posed by cryptanalysts against signature algorithms involve *knowledge
of the signature* of one or more files, which is natural in Applica-
tion (II). It therefore requires a very secure algorithm. But in the
environment I am considering (Application (I)), such knowledge and
hence such attacks are impossible even with an unsophisticated algo-
rithm such as CRC, provided different users use different keys, and
the checksum base etc. are kept offline while a virus may be in memory.
> From what I've
>read in this forum of late, it does appear that Ross Greenberg and Y.
>Radai are at one end of this spectrum and that Bill Murray, Ralph Merkle,
>Jim Bidzos, Fred Cohen, and the others mentioned in Mr. Radai's Jan. 4
>posting are more or less at the other end with me. (If I've
>misrepresented your views here, gentlemen, I hope you'll forgive and
>correct me for it. I'm reading between the lines.)
First, don't forget that the "others" mentioned in my posting include
Prof. Michael Rabin, and that the algorithm which he advocated was the
same, relatively unsophisticated, algorithm which I consider (tenta-
tively) to be the best. (I take this opportunity to point out that
the algorithm of Rabin's to which I am referring is from a little-
known paper of his, and is not to be confused with a better-known
algorithm of his which involves taking the square root of the message
[= the file] modulo the product of two secret primes.)
As concerns your lumping me together with Ross Greenberg at the low
end of the sophistication spectrum, that picture is not far from cor-
rect only if you limit yourself to the *algorithm* involved. As re-
gards security of the *implementing program*, I'm miles away from Ross.
Although I have said that I tentatively consider CRC to be the best
algorithm for the purposes which I am considering, I wish to empha-
size that I am in no way committed to it. If someone can produce
evidence that some other algorithm is both more secure in the environ-
ment with which I am concerned and is faster or almost as fast as CRC,
I'm willing to alter my opinion. However, what it takes to convince
me (and I think a lot of other readers) is not a proclamation that
Committee X has adopted Algorithm Y as its standard, but *an actual
comparison of programs which implement the various algorithms*.
In comparing speed, we will, of course, take into account what Bob
has pointed out, namely that a program can be written to implement a
sophisticated algorithm on a small part of the file and a fast algo-
rithm on the rest. Obviously, such "hybrids" could also be among the
contenders.
Comparing security is much trickier since the results will depend
strongly on what test viruses we can think of. So no such test can
ever be conclusive. But it should be more convincing than mere proc-
lamations and appeals to the authority of some committee or other.
(By the way, I made a challenge to compare the security of programs by
such tests over a month ago; why no response?)
It is only when we have the results of such comparisons that each
user will be in a position to decide which program is best suited to
his needs. My guess is that for Application (I) there won't be many
users who will choose a program which is based on a sophisticated
algorithm.
Y. Radai
Hebrew Univ. of Jerusalem, Israel
[email protected]
------------------------------
End of VIRUS-L Digest
*********************
Downloaded From P-80 International Information Systems 304-744-2253
