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 VIRUS-L@IBM1.CC.LEHIGH.EDU (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: krvw@SEI.CMU.EDU. - Ken van Wyk --------------------------------------------------------------------------- Date: Tue, 13 Feb 90 09:49:01 -0500 From: woodb!scsmo1!don%cs.UMD.EDU@IBM1.CC.Lehigh.Edu 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: scsmo1!don@uunet.uu.net 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: 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 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 - JFORD1@UA1VM.BITNET, JFORD@MIBSRV.MIB.ENG.UA.EDU [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: 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" 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: proton!spin!legg@ucsd.edu (David Legg) Subject: Re: The AIDS "Trojan" is a Copy Protection System munnari!mqccsunc.mqcc.mq.oz.au!ifarqhar@uunet.UU.NET (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%proton.uucp@ucrmath.ucr.edu 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" 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: dplatt@coherent.com 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: dplatt@coherent.com INTERNET: coherent!dplatt@ames.arpa, ...@uunet.uu.net USNAIL: Coherent Thought Inc. 3350 West Bayshore #205 Palo Alto CA 94303 ------------------------------ Date: 13 Feb 90 19:50:21 +0000 From: lambert@cwi.nl (Lambert Meertens) Subject: Re: Re universal detectors. USERGSVE@LNCC.BITNET (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; lambert@cwi.nl ------------------------------ Date: Tue, 13 Feb 90 17:08:07 +0200 From: Y. Radai 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 RADAI1@HBUNOS.BITNET ------------------------------ End of VIRUS-L Digest ********************* Downloaded From P-80 International Information Systems 304-744-2253