========================================================================= Date: Wed, 7 Sep 88 22:34:00 CDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: PETCHER%eg.csc.ti.com@RELAY.CS.NET Subject: Virus wars > From: "James N. Bradley" > Gentlemen, Gentlemen... > War is not an instance of rational minds at work. Rather, it is the failure > of rational minds. Viruses also might be considered a failure of an otherwise > rational mind. Regardless, in the event of a war, I think we can assume that > both sides will be doing whatever they can to disrupt whatever they can. Exactly. It is a time of desparation, and desparate measures are taken, if they offer the hope of an end to the war on terms acceptable to whoever takes the measure. > I think the question should be something on the order of "Will the exchange of > computer viruses be so detrimental that no one will instigate it?" This is > approximately the situation with nuclear weapons. As with nuclear weapons, > both sides may seek the capacity to win with a first strike, but neither is > likely to achieve that capacity given the "roughly" equal resources. Though I initiated that analogy, I must point out a major difference: Viri are capable of being stealthy. A modern nuclear attack would quickly be followed by retaliation, and quite likely a no-win situation for both parties. The use of nuclear weapons in WWII was successful because it was controlled and necessarily unilateral. Such would not be the case today. On the other hand, given the resources, it is possible a stealthy virus could be developed and injected into a target computer operated by some hypothetical enemy, that might do it's dirty work undetected - degrading system performance, perhaps causing the system to generate wrong results, or maybe simulating hardware failures. We haven't thus far seen a virus that behaves that way, only because the only known reasons for anybody to write a virus so far have been misguided mischief, and perhaps revenge. When and if the reasons for creating viri change, the behavior of them will change as well. Malcolm Petcher, Texas Instruments, Inc. ========================================================================= Date: Thu, 8 Sep 88 08:53:40 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: Virus case goes to trial (reprinted from RISKS forum) Here's an interesting article that appeared in a recent RISKS forum that I thought some of you may enjoy (except, of course, those who are already on the RISKS forum...): Date: Wed, 07 Sep 88 13:05:09 EDT From: Joe Morris (jcmorris@mitre.arpa) Subject: A Computer Virus Case Goes to Trial From the _Washington_Post_, 7 September 88, page C-1 (without permission): JURY SELECTION IN 1ST `VIRUS' TRIAL BEGINS (AP) Fort Worth, Sept. 6 -- Jury selection began today in the criminal trial of a 40-year-old programmer accused of using a computer "virus" to sabotage thousands of records at his former work place. The trial is expected to last about two weeks. Donald G. Burleson faces up to 10 years in jail and a $5,000 fine if convicted in the trial, a first for the computer industry. Burleson was indicted on charges of burglary and harmful access [sic] to a computer in connection with computer damage at a securities firm, said Nell Garrison, clerk of the state criminal district court in Fort Worth. Through his lawyer, Jack Beech, Burleson denies the charges but has declined further comment. The firm has been awarded $12,000 in a civil lawsuit against Burleson. Pretrial motions were scheduled to be heard today, followed by jury selection, Garrison said. Burleson is accused of planting a piece of computer software known as a virus in the computer system at USPA&IRA Co. two days after he was fired. A virus is a computer program, often hidden in apparently normal computer software, that instructs the computer to change or destroy information at a given time or after a certain sequence of commands. [Trojan horse???] USPA officials claim Burleson went into the comapny's offices one night and planted a virus in its computer records that would wipe out sales commissions records every month. The virus was discovered two days later, after it had eliminated 168,000 records. Kenneth R. van Wyk Calvin: Ever consider the end of the User Services Senior Consultant world as we know it? Lehigh University Computing Center Hobbes: You mean nuclear war? Internet: Calvin: I think Mom was referring to if I BITNET: let the air out of the car tires again. ========================================================================= Date: Thu, 8 Sep 88 00:30:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Jim Shaffer, Jr." Subject: request for info on an Atari 8-bit series virus About a month ago I read in Atari Explorer magazine, in an article on viruses in general, that there was a virus for the Atari 8-bit series of computers (i.e., 800, 800XL, 65XE, 130XE). However, the article didn't go into detail. Has anyone heard of this virus and can tell me more? Thanks in advance, Jim Shaffer, Jr. P.S.: The article is a good overview of viruses in general, and I'll post the information on where it appeared as soon as I can find the darn magazine :-) ========================================================================= Date: Thu, 8 Sep 88 10:37:58 CDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "James N. Bradley" Subject: Re: Hypercard as a virus vector In-Reply-To: Your message of Wed, 7 Sep 88 20:22:31 EDT Hypercard is a programming language disguised as a Macintosh application. It uses hypertext and an index card analogy with a graphic interface to allow virtually anyone to program, which has, as a consequence, produced all kinds of cute but useless programs. On the other hand, when people who know what they are doing write "stacks" (Hypercard programs) they can be really spectacular. I don't think you can compare Hypercard to REXX because of the difference in the environments. Hypercard has a strong graphic emphasis, it is designed for anyone to use, and it will (probably) be the front end program of the future for the Macintosh interface. JB ========================================================================= Date: Thu, 8 Sep 88 11:47:00 MDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "David D. Grisham" Subject: Possible nvir A user (Mac) has come to me with a disk with the following symptoms: 1) Would not save/print on MS word 3.01. 2) Used Ferret and code id 02, crashed. 3) Used VirusRx and declared "probably good" 4) Resedit found a non sequential code of 255,256, ... Is this a Virus or a bad MS word? ****************************************************************************** * * * Dave Grisham * * Senior Staff Consultant Phone (505) 277-8148 * * Information Resource Center * * Computer & Information Resources & Technology * * University of New Mexico USENET DAVE@UNMA.UNM.EDU * * Albuquerque, New Mexico 87131 BITNET DAVE@UNMB * * * ****************************************************************************** ========================================================================= Date: Thu, 8 Sep 88 07:01:14 PDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Robert Slade Subject: Easiet OS to infect All inter system rivalry aside, the bigger they are, the more places there are to hide. My reading of the collected virus reports indicates that the Mac is winning in the "I got more viri than you" stakes. When OS/2 Extended is released (on 22 1.44 meg disks no less?), oi vey. (Yes, yes, I know. The kernel will be smaller than that.) ========================================================================= Date: Thu, 8 Sep 88 06:40:22 PDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Robert Slade Subject: Viri in data files Carol raised the question about Hypercard, and "abr1" made a statement that data files could *not* carry viri. Let's be careful about what we define as data. (After all, programs really are just data that you execute.) Both Hypercard, in the Mac world, and Lotus 123 files, to give an example in the MS-DOS world, are capable of carrying commands that can do low level work in your system. Hypercard stacks at one point carried the Brandau "Macmag" virus. (I do not know of any incidents with Lotus workspaces ... yet.) Robert Slade ========================================================================= Date: Thu, 8 Sep 88 15:06:41 EST Reply-To: Virus Discussion List Sender: Virus Discussion List From: Joe Simpson Subject: Re: Easiest OS to infect In reply to the comment that bigger is easier to infect I beg to differ. Operating systems with layered architectures and rich file support are easier to infect. They may also be easier to defend with. There is an easy to use suite of public domain and sharware tools available. I can only hope th ========================================================================= Date: Thu, 8 Sep 88 16:19:44 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Ed Nilges Subject: Re: Viri in data files In-Reply-To: Your message of Thu, 8 Sep 88 06:40:22 PDT Hypercard stacks have two capabilities as virus vectors: 1. Those without XFCN and XCMD coding probably cannot screw up the Mac environment outside of Hypercard, but they can screw up a given instance of Hypercard by setting global properties in a subtle way. 2. Those with XFCN/XCMD can screw up the Mac, in addition to the Hypercard environment. This may indicate an automated test to see which class a given stack falls into. The fact that the first class is relatively benign does not entail that we should never worry about class 1 Hypercard viruses, only that we should focus the bulk of our (always limited) virus-fighting resources on class 2 viruses. Note also that Hypertalk lets you treat stacks as objects...this raises the specter of fearsomely complex, self-altering Hypercard stacks circulating around bulletin boards and such. The fact that Hypercard stacks can be entertaining (music, X-rated cartoons, and so on) will speed viruses along this particular vector. ========================================================================= Date: Thu, 8 Sep 88 15:07:00 MDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Bernie Subject: Re: 'Good' Viruses In-Reply-To: Message of 7 Sep 88 20:05 MDT from "EAE114 at URIMVS" (This is a weak, but so are most args.) Sure, any person who knows about viruses can run an anti-viral program but don't forget MOST computer users are not computer or computing literate. I really doubt that a "good" virus could easily be corrupted. After all, how many people do you know who trace other peoples ml code for fun? The whole purpose of this hypothetical "good" virus would be to remove only identifiable "bad" viruses, and maybe after a certain time remove itself. It would be doing the techno peasant a favour as well as the knowledgable because you'd never know it was there (just like a bad virus) doing the user a service. Next: OJA, hackers are not to blame. I resent that since not all hackers are innately evil, and hacking is a proven learning experience. Greenberg, you forget the Shareware protection (one of many). "Send us your money or else it won't work after a while..." Anyone know how many pieces of Shareware have trojan horses? ========================================================================= Date: Thu, 8 Sep 88 13:02:23 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: me! Jefferson Ogata Subject: good viruses/bad viruses We had a discussion about the merits of making virus-protection software viral itself some months ago. I'm hearing a lot of the same rebuttal again, and it makes no more sense this time than last. Correctness: how do you know your virus will behave the same way in some other environment and not do serious damage? How do you know ANY program will behave as you expect? Why bother writing programs? They might turn into Trojans. Surely this is paranoia. Viruses are programs. You can test them. Superfluosity: a virus cannot do anything a regular program can't do. Yes it can. A virus can self-propagate. A virus is immune to virus attacks, unlike most virus-protection software. Even encryption schemes have the glaring flaw that they can be corrupted. Insecurity: you must leave holes through which the virus can propagate. Well, if those holes could be closed, there would be no need for the good virus. As long as those holes exist, the virus can do some good. And nothing stops you from plugging all the holes you can; you'll prevent good viruses from propagating, but hopefully you'll prevent the bad ones from propagating as well. Mutation: what if the virus gets corrupted and becomes damaging? Programs don't mutate so any corruption would have to be some kind of hardware problem. In that case, the probability is much higher that some particular program will become a Trojan. It is virtually impossible for some random alterations in code to end up functional, let alone damaging. The virus code would be small and therefore less likely to be damaged. Bad guys: someone might take the code and alter it to be bad. True. - Jeff Ogata ========================================================================= Date: Thu, 8 Sep 88 09:32:50 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Jim Marks Subject: Re: Legality In-Reply-To: Message of Wed, 7 Sep 88 10:55:00 MDT from This is a good question. I'm not a lawyer, so I can't really answer it, but will offer my opinion. You can pretty much sue anyone you want, the question is whether you would (or could) win. Even lawyers often can't answer this; it depends on the state, judge, jury (if any), etc. Most of the software licence agreements have statements which say the vendor is not liable for damages as the result of using the software. Of course, the "agreements" also usually say something to the effect that the vendor doesn't even guarantee that the program will do what you need to do, either. In fact, if you saw disclaimers on cars (or other products) of the sort on software packages, you would never buy them. I question whether such agreements have legal validity, but then I'm not a judge. What would also be an interesting case would be such things as structural design software which was used in the design of a building. If the building design was not adequate (because of a "bug" in the software) and the building collapsed (say with loss of life), could the damaged parties prevail against the software manufacturer (in addition to the structural engineer)? Could the structural engineer prevail against the software manufacturer? I think there will eventually be some interesting cases of this sort (maybe not quite so dramatic) in the future, if not already. Back to the virus... What would be difficult in such a case (even if the license agreement didn't protect the vendor) would be proving that the virus actually came from the vendor's package. These things, by their nature, are pretty elusive. These are strictly my opinions; I don't even pretend to be an authority in this area. Anyone out there who is? Jim Marks ========================================================================= Date: Thu, 8 Sep 88 18:13:49 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "David A. Bader" Subject: Re: Viruses >I really doubt that a "good" virus could easily be corrupted. After >all, how many people do you know who trace other peoples ml code for >fun? The whole purpose of this hypothetical "good" virus would be to >remove only identifiable "bad" viruses, and maybe after a certain time >remove itself. It would be doing the techno peasant a favour as well >as the knowledgable because you'd never know it was there (just like a >bad virus) doing the user a service. Look at viruses such as the Brain virus and others that have been modified through time. Random programmers out there are easily able to decompose the ML code and change good to bad, or from bad to worse. Also, All the virus protection out there that watch for file size changes, CRC checksums, etc., will keep telling a user that he has been infected. (He will never know "good" from "bad" if both propogate over the same means.) Also, if the programmer can write a "good" virus to escape the view of common virus detectors, then virus writers also have the same technology. >Greenberg, you forget the Shareware protection (one of many). "Send usyour >money or else it won't work after a while..." Anyone know how many es of >piece Shareware have trojan horses? Some shareware out there has a strange kind of protection on it so that you don't have a trojan horse if you don't pay. I've seen programs that let you install them the first time around; and they monitor the date from installation. After a few months, or a year, they won't run giving you a message that you need to buy the software if you are really interested in it. Now for any computer literate person, it is easy to hack out the date stamp, or anything to those means to bypass this protection. But from the company's side, no "trojan horse" is released, and the average user is rightfully oblijed to buy the package since s/he has had a long enough trial period. David Bader DAB3@LEHIGH ========================================================================= Date: Thu, 8 Sep 88 17:33:00 CST Reply-To: Virus Discussion List Sender: Virus Discussion List From: conni annable Subject: non-existent Viruses I've just been looking through a friends catalog from a company that sells disks full of public domain/shareware programs. Page 3 of this catalog is titled "Topic: VIRUSES" in which they claim "a couple of national magazines first thought up the concept of MS-DOS viruses" and hmmm... I'll quote this paragraph entirely: >>> Simply put, there is no such thing as a virus. There never has been. >>> Period. It is a "Modern Urban Legend". The same as the $50 Corvette, >>> alligators in the New York sewers, and all the others. They go on to say that they can only speak for the MS-DOS microcomputer world and that they have tried unsuccessfully to track down some of the rumors they have heard. They point to PC Magazine and PC World as very active in 'spreading these stories' and wonder if they are doing that to sell magazines or software (at "up to $900"). They do admit that Trojans exist but state that they are 'Very Rare'. Obviously, they have a great interest in getting folks to continue to use public domain programs - after all that's their business. Gee folks - think of all the time we've wasted thinking/writing/reading about this non-existent threat! do you think we should dissolve the list? (she said with tongue firmly in cheek...) On another page this catalog refers to a newsletter from the DENVER PC BOARDWATCH as having "an excellent two-page article debunking the virus scare". Have any of you seen this? I can't tell when it was - they say "just last month" but give no indication when this was written other than a 1988 copyright. If someone has seen this article, could you summarize it please? Thoroughly disgusted (having recently been bitten), conni ========================================================================= Date: Thu, 8 Sep 88 21:54:00 MDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: KEENAN@UNCAMULT Subject: Re: Legality In-Reply-To: Message of 8 Sep 88 07:32 MDT from "Jim Marks" I'm not a lawyer either, Jim, but a few things that would certainly be relevant: Did the company KNOW about the virus? It is a basic legal principle in most civilized countries that you need to form the *mens rea* (guilty mind) to be guilty of a criminal offence. In civil actions for negligence, again the company must be shown to have some reasonable grounds to suspect the existence of a virus. closest analogy i can think of is Johnson and Johnson might have been sued successfully for continuing to sell Tylenol in the face of a clear and well known danger. (They took it off the market for a while, of course.) As for the structural engineering question, we just had such a case in Vancouver, a brand new parking structure collapsed injuring dozens of people. The association of professional engineers temporarily lifted the licenses of those responsible pending investigation. IF they were using computers AND KNEW OF SOME FLAWS they would be clearly derelict in their duties. (I worked for the company that designed a rather famous 110 story building in New York City and we did indeed find some design mistakes that needed correcting before construction.) IF the engineers had every reason to trust the programs (they relied of them for a long time in the course of business) then it might indeed bounce back to the software company's lap, and it would depend how knowledgeable they were about potential flaws/shortcomings etc. I agree that the shrink wrap disclaimers are worth the cardboard they're printed on (if that...) ========================================================================= Date: Thu, 8 Sep 88 22:20:00 MDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Bernie Subject: Re: good viruses/bad viruses In-Reply-To: Message of 8 Sep 88 11:02 MDT from "me! Jefferson Ogata" Sorry if its all been said before. I just think it is too much work to install a vaccine program and have it execute every boot or to have to do spot checks on all my disks for something which has only hit me once (and on the City's machines, not my own). Vague as always. Me. ========================================================================= Date: Fri, 9 Sep 88 08:35:54 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "David M. Chess" Subject: good viruses/bad viruses I take it that these "good viruses" would at least tell the user that they were there, and preferably ask his permission to proceed? Otherwise, *whatever* it's doing, I'd consider it Very Antisocial for a program of whatever ilk to take it upon itself to do something that I never asked it to do, because someone somewhere once decided that it'd be "for my own good". Rank paternalism! Viruses are immune from infection? In what sense? If "good" viruses became common, I'm sure someone would write a "bad" virus to infect them. It should be no more technically challenging than writing a virus to infect PC-DOS EXE files. Pardon the belligerence! DC (Affiliation given for identification purposes only) ========================================================================= Date: Fri, 9 Sep 88 08:55:42 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: portal!cup.portal.com!Dan-Hankins@SUN.COM Subject: Re: Virus Legislation Daniel M. Greenberg writes: >Many viruses are contracted by people that download unknown software >from bulletin boards. If they didn't down-load it, it wouldn't have >propagated in their system. Every time you download something- you >take a risk that it has a nasty virus. If you go to a store nd buy >a program, you can expect it to be "clean". Not so. The MacMag virus was (accidentally) distributed with Freehand, an Aldus product. Also, what about mail-order? what about those little packages that you see advertised in computer magazines that were probably put together by some freelancer in his home office? Who's to say he hasn't been infected and is distributing infected copies of his software? If one takes this 'trusted sources' argument to its logical conclusion, we're all going to have to go back to programming by front panel switches and programming our own code and no one elses. Even a reasonably large company such as Aldus can get burned. Dan Hankins These opinions are my own and are not for sale. However, they may be rented or leased at reasonable rates. ========================================================================= Date: Fri, 9 Sep 88 11:21:04 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: OJA@NCCIBM1 Re: The Burleson Case in Texas 1. The computer sabotage, to the best of my knowledge, was not a virus, but a Trojan that would monthly wipe out commissions records from the computer accounting database. (It seems that various news- paper reporters have trouble discerning between the varieties of malicious programs. This, unfortunately, includes writers for computer user group newsletters in many cases.) 2. Since I am preparing a future article on this case (mainly for non-profit computer user groups newsletters), are there any VIRUS-L participants in the Texas area who can help me by sending news clipps and other info about the case? (I am also working on getting a FOIA request in to the Dallas office of the FBI. But that's going to take some time.) Re: My comment about computer newsletter writers above.... I am also a writer for computer user group newsletters. Itin writing on a more serious level about viruses that I have learned many of the pitfalls about journalism and research. Some of my collegues, who are quite competant in writing about software and hardware, stummble when it comes to dealing with events in the news. Unlike having software or hardware before you to examine, news is lot trickier. First, the source has to be examined. Second, confirmation has to be sought. Third, discretion is need to know whether everything that passes one's eyes is to be published. Fourth, such information gathering has a relational aspect, one has to deal with people not disks or hawrdware. Discernment is crucial. Some of the newsletter misinformation that I have run into over the past year include... * The claim that Donald Burleson was the writer of the SCORES virus. In talking with the author of the article, I found that he used a newspaper report and jumped to conclusions based upon the Texas location and Federal involment in the case. * A Texas users group newsletter article about "viruses" having an interesting classification of "benign", "malignant", and "contagious" (!!!!) Examination of the article showed that the author was lumping together Trojans and viruses, so the "contagious viruses were really the viruses and the other categories were forms of Trojans. * Many articles claiming that viruses don't exist except as a ploy by "anti-virus" software distributors to sell their wares. The way these claims themselves get replicated can be considered a "viral mode" - "information viruses" Actually, it the old case of misinformation at work. Re: If one get an infected commercial software package, can the person sue the company? In the USA and many other countries - yes. As a civil tort case or possibly a class action suit, it is possible. So far, I know of no virus liability case that has gone to court. There has been much talk of virus lawsuits after the ALDUS FREEHAND incident, but no further news. Re: VIRUS-L Subscription and messages to me.... I have noticed a problem with the storage of BITNET transmissions at my installation. Using the spool display facilty on the TSO MVS system here, I noticed that the files often get purged with no apparant pattern. With that and time constrictions, a method of coping will be to unsubscribe to this list and to weekly get the logs from LISTSERV. I can still receive promptly any messages sent to me. Also if anybody has sent messages directly to me and has not gotten a response, please resend, the message(s) may have been wiped out. Thank you. ========================================================================= Date: Fri, 9 Sep 88 17:41:05 +0200 Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Y. Radai" Subject: Re: CRC vs. encryption schemes I haven't noticed any reply from Jerry Leichter to my posting of Sept. 2. Anyway, a number of people have sent me personal messages asking almost iden- tical questions, so I thought I might as well make my answers public in case any others on the list have similar questions but didn't dare to ask. (Btw, Joseph, my reply to you came back with the message "CUNYVM.CUNY.EDU unable to connect for 3 days to host", so please accept this as if it were a personal reply to you.) The questions were: (1) What are the three "loopholes" in checksum programs which I mentioned in my postings of Aug. 29 and Sept. 2? (2) What is the pro- gram I have been referring to which blocks all three loopholes? First of all, despite what I wrote, it's not so clear that the number of LHs (loopholes) is 3; it all depends on how you count them. In two cases I was counting two similar LHs as one; maybe it would be more reasonable to separate them and then there'd be 5. Anyway, I'm in the process of preparing a rather long document on the use of CPs (checksum programs) for detecting viral infec- tion, and I explain all but one of the LHs there. It should be finished in a few weeks. Roughly, it can be divided into the following sections: 1. An introduction to CPs. 2. LHs in CPs. 3. Limitations of (all) CPs 4. Criteria for comparison of CPs. 5. A partial comparison of 16 CPs with respect to almost 30 criteria ("par- tial" in that I have very little information at present on most of the CPs). I'm not sure what the best way of presenting this information is when it's fi- nished. (About a month ago I sent out a draft version of my document to three people for constructive criticism, and one of them suggested that it would be an appropriate subject for a lecture at the October conference. But that sort of thing is obviously not in my hands.) The program I was referring to is an Israeli product called VirAlarm (not to be confused with Lasertrieve's product of the same name). It sells for $50, and you can get a good idea of its relative merits from the last section of my docu- ment. My conclusion is that it's far better than any of the other programs in my possession. Obviously there may be products which I have not seen which are as good or better than VirAlarm in some respects, although I doubt this as far as LHs are concerned. I understand from the authors that VirAlarm is to be marketed in the U.S. in the near future. In any case, I have absolutely no commercial interest in the product. (Actu- ally, this "disclaimer" isn't enough in my case, since I'm in frequent contact with one of the authors, and someone might suspect that I'm trying to get in a plug for him. So let me emphasize that I'm being as objective as I can when I say that I genuinely believe it to be an excellent product.) By the way, VirAlarm was the subject of a bet on Israeli television a few months ago. The authors claimed it could detect *any* virus infection, while a Tel Aviv software house claimed it couldn't. Anyone who's interested in a re- port on the outcome and details can get it from the Risks Digest, Vol. 6, No. 93, or by writing to me. Y. Radai Hebrew Univ. of Jersualem ========================================================================= Date: Fri, 9 Sep 88 11:16:07 PDT Reply-To: Virus Discussion List Sender: Virus Discussion List Comments: Warning -- RSCS tag indicates an origin of KLING@UCIVMSA From: MESSAGE AGENT Subject: Re: non-existent Viruses Dear Virus Discussion List, This is an automatic reply. Feel free to send additional mail, as only this one notice will be generated. The following is a prerecorded message, sent for Rob Kling I am out of town for about a week, on the East Coast. I will be back around Sept 15-17. If you need to leave a message for me by phone, please call 714-856-5955 and leave a message with a secretary,..... or call 714-786-0873 to leave a longer message with my house sitter or on my answering machine. Rob Kling ========================================================================= Date: Fri, 9 Sep 88 15:10:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Glen Matthews Subject: Good vs. Bad Virus: "Mutations" With respect to "mutation" of a virus, I would suggest that a correctly functioning virus would not do that. Certainly, testing should result in any such undesirable behaviour being corrected. However, remember the environments that this "good" virus might be injected into. My programs, for example, are not guaranteed to be free of bugs every time I run them, especially the first time. If a correctly functioning "good" virus infects one of these programs, it is just conceivable that *my* program accidentally modifies the virus prior to propagation: thus, a "mutation". Lest this sound terribly unlikely, recollect the WORM article in CACM. The authors describe one of their experiences with a worm which apparently became altered in execution. My memory may fail me here, but I don't believe that hardware error was advanced as the cause (the authors could not have known exactly, anyway). Basically, when the issue of so-called "good" viri comes up, it behooves us to remember which road is paved with good intentions. Precisely because we cannot predict the eventual environment that a virus might be found in, I think that we should be cautious about releasing a virus even though that virus will solve all of our thorny problems for us. And by "cautious", I don't mean TESTING the virus; I mean having a *VERY* clear idea of the target population, as well as having escape hatches within to shut down the virus if required. And even these measures might not be sufficient to justify the release of a so-called "good" virus. Glen Matthews McGill University ========================================================================= Date: Sat, 10 Sep 88 16:34:16 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: David.Slonosky@QUEENSU.CA Subject: Re: Easiest OS to infect In-Reply-To: >In reply to the comment that bigger is easier to infect I beg to differ. > >Operating systems with layered architectures and rich file support are >easier to infect. They may also be easier to defend with. There is an >easy to use suite of public domain and sharware tools available. > >I can only hope th So what do we mean by "layered architectures" and "rich file support"? As a relative neophyte in operating systems I would like to know. Does DOS have these features? __________________________________ | | David Slonosky/QueensU/CA,"",CA | Know thyself? | | If I knew myself, I'd run away. | |__________________________________| ========================================================================= Date: Sun, 11 Sep 88 15:46:46 MEZ Reply-To: Virus Discussion List Sender: Virus Discussion List From: Konrad Neuwirth Subject: Re: Different Operating Systems In-Reply-To: Message of Wed, 7 Sep 88 20:28:01 EDT from hi, as an amiga user, too, and having been affected i can tell you something about the amiga viruses. A nice guy from switzerland ( of SCA) wrote a virus on the amiga, just to proof it is possible. Now there exist a lot of mutations of this virus, the most commonly know the byte-bandid virus. To understand the amiga viruses, it is necesary to know a bit about the amiga OS. It uses, as most machines do, the first track as a boot track, but it doesn't write too much into it, so there is a goos space for a virus. As the amiga is a multitasking machine, it is not too hard to make up a virus, as it just has to be a task, which doesn't have a window. The amiga OS is not a too good Multitasking enviroment, as it has almost no ways to protect one task from another. You certainly can imagine what that does mean for a virus. The SCA virus is, thank god, not a destructive one, but it is still enough. But the author did make a good thing in the virus ( if you can say good things about viri ;-)), he built in a self destruction feature. There also exist programs to protect the machine, and even some are small tasks chacking each inserted disk for a nonstandart boot block. I personally use VirusX, which is such a program. I don't know more about the other machines SIGNED, AS ALWAYS I /I +---- I / I +-- I I +---- "SORRY FOR LIVING, I WILL NEVER DO IT AGAIN" KONRAD NEUWIRTH (A4422DAE AT AWIUNI11) (KONRAD ON RELAY) ========================================================================= Date: Sun, 11 Sep 88 17:43:00 MDT Reply-To: Virus Discussion List Sender: Virus Discussion List Comments: W: Field "Resent-Date:/Date:" duplicated. Last occurence was retained. Comments: W: Field "Resent-Message-ID:/Message-ID:" duplicated. Last occurence was retained. Comments: W: Field "Resent-To:/To:" duplicated. Last occurence was retained. Comments: W: Field "Resent-From:/From:" duplicated. Last occurence was retained. Comments: W: Field "RESENT-FROM:" duplicated. Last occurence was retained. Comments: Resent-From: Bernie' Comments: Originally-From: Glen Matthews From: Bernie' In-Reply-To: In reply to your message of FRI 09 SEP 1988 18:51:00 EDT Mike commented, re "mutations", > ... in the chance of a bug (mutation) code is more likely > to crash or hang than to follow some destructive path. I'd agree. However, random zapping of an execuing program doesn't necessarily involve the zapping of code; data required by the "good" virus may be the component that is accidentally modified. In my work with systems, I've seen cases where instructions have been modified such that the system continues to function without a hard failure. And let me point out the case in CACM again (I'm at home now, so let me quote from the article): "... We have speculated that a copy of the program (the worm) became corrupted at some point in its migration, so that the initialization code would not run properly ..." Coupled with their environment, the unexpected result of an uncontrolled worm became a reality. Note that the programs involved do not have to function correctly or anything; as long as it "reproduces", a corrupted virus is dangerous. To stretch the biological analogy perhaps to the breaking point, recall that although individual occurances of mutations might be recall, simply multiplying the probability of their occurance by the number of possible PCs wherein they can occur can give rise to an unexpectedly large number. I don't want to over-emphasis this; in fact, I'd guess that this threat is probably relatively minor. But thinking that "good" viri can only generate "good" effects is like thinking that guns in the hands of policement ("good guns") can only generate "good" effects. Glen Matthews ========================================================================= Date: Mon, 12 Sep 88 00:04:00 MDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: LYPOWY@UNCAMULT Subject: Infecting "Good" Viruses Bernie, since a virus usually just prepends itself to an existing "program" file, is it not possible that a good virus could have a "bad" virus prepended to it? Then, when this file is executed, the bad virus would have control, then relinquish its control to the good virus (if that is in its game plan), and then the "good" virus would relinquish control to the original program. Loren ==> Is it possible to get a copy of the magazine that you are publishing for the upcoming virus conference??!! Greg Lypowy ========================================================================= Date: Mon, 12 Sep 88 02:23:25 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: me! Jefferson Ogata Subject: virus mutations > But thinking that "good" viri can only > generate "good" effects is like thinking that guns in the hands of > policement ("good guns") can only generate "good" effects. Good God; I hope nobody suggested either of those things! :-) - Jeff Ogata ========================================================================= Date: Mon, 12 Sep 88 07:56:33 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: Forwarded article on virus existance, from RISKS Here's a somewhat amusing story that was recently posted to RISKS: Date: Wed, 07 Sep 88 17:30:40 EDT From: Mark Moore Subject: "Viruses Don't Exist" and the Marconi Mysteries... I received one of those info-card packs (I forget from whom) as a result of having my name and address sold by Dr. Dobb's. I filled out a few of the cards and received a catalog from Public Brand Software, which is a shareware/ freeware clearing house based in Indianapolis, IN. Here are a few quotes on from the third page of their catalog entitled 'Topic: VIRUSES' 'It seems like a couple of national magazines first thought up the concept of MS-DOS viruses. Unfortunately, a lot of people read these magazines and believe everything that they read. But let's get a couple of definitions clear first. virus, n. 1. a purposely destructive computer program that can propagate itself by modifying other computer programs (such as COMMAND.COM) to make them destructive. 2. a destructive myth perpetrated to sell a product and/or fill editorial space.' The article goes on to claim that viruses are myths akin to friend-of-a-friend stories; popular magazines are perpetuating the myths to have something sensational to print; engineers are doing the same in order to sell vaccines. They claim that they've searched high and low and can find no such thing as a virus. 'Simply put, there is no such thing as a virus. There never has been. Period.' Sounds like a dangerous attitude to me. [Ken - Sounds like a case of foot-in-mouth to me...] Kenneth R. van Wyk Calvin: Ever consider the end of the User Services Senior Consultant world as we know it? Lehigh University Computing Center Hobbes: You mean nuclear war? Internet: Calvin: I think Mom was referring to if I BITNET: let the air out of the car tires again. ========================================================================= Date: Mon, 12 Sep 88 09:16:31 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Ken van Wyk Subject: Virus research paper by ex-Lehigh student The following paper was sent to me by Stephen Kiel, a graduate (and ex-student employee) of Lehigh University. The paper was done while Steve was finishing up work on a Masters degree in Electrical Engineering at Georgia Tech. VIRUS-L readers may recognize some of the quotes which Steve used as having been taken from VIRUS-L. Many thanks, Steve, and best of luck in recuperating from your 1200 mile bicycle ride home to NJ! :-) Steve no longer has network access since leaving Georgia, but hopes to be rejoining VIRUS-L upon taking up his new job at Bell Labs. Ken -------------------------------------------------------------------------- THE INFECTION OF PC COMPATIBLE COMPUTERS Stephen E. Kiel Raymond K. Lee Georgia Institute of Technology Summer Quarter 1988 INTRODUCTION The recent publicity over computer viruses has produced mixed reactions and much confusion inside, as well as outside, of the computing industry. The conflicting opinions are caused either by a misunderstanding of what viruses are or a lack of understanding of their potential problems. This paper answers those questions and in addition, gives a description of currently suggested methods for IBM PC's and compatibles for detecting, preventing, and eliminating viruses. A highly technical discussion is not the objective, but rather a broad overview is given along with sources of additional information and assistance. THE BEGINNING On November 3, 1983, an idea was conceived of by Fred Cohen as an experiment to be presented at a weekly seminar on computer security [1]. The idea was simple enough: design a computer program that could modify other programs to include a possibly evolved copy of itself. This evolved copy would then modify other programs and thus continue the propagation and evolution. The program could easily be spread by unknowing users throughout a computer system or network. It only took eight hours of expert work on a heavily loaded VAX 11/750 to complete the first of such programs and prepare it for demonstration. The program was inserted into the beginning of a new program on the system called 'vd,' which displayed Unix structures graphically. A new program was chosen so that details of its operation and its performance characteristics would be unknown. Users were introduced to vd via the system bulletin board. The program inside of vd used the authorizations of every user using it to infect their programs. In all of the experiments, the program that was initially inserted into vd was granted all system rights in under an hour. The shortest time was under five minutes, with the average time under 30 minutes. Even people who knew that the experiments were taking place were unable to defend themselves. Once the surprising results of the experiments were announced, the administrators of the VAX 11/750 decided that no further computer experiments would be performed on their system. Precautions were taken to keep the experiment under control. No damage was done and only reports were sent back on the program's progress. Also, traces were generated to insure that the program could not spread without detection. All files were purged of the program after the experiment was completed. It is unfortunate that an apparent fear reaction on the part of the system administrators prohibited any further testing. DEFINING A VIRUS A name for programs exhibiting the behavior described above was thought of by Len Adleman: 'viruses.' A computer virus can generally be defined as a program which hides in computer systems, usually in larger programs, whose mission is to replicate and spread until the occurrence of some designated event. When this event takes place, the program can then perform some action specified by its creator. The term 'virus' is very appropriate since computer viruses (here after referred to as simply 'viruses') behave much like their biological counterparts. Once in a computer system, a virus can remain quiet for an incubation and contagion period, during which it infects other files. After some prespecified event, such as a period of time or a number of infections, the virus can come to life and begin an attack. All the while, the offspring of the virus are infecting other files and systems, also waiting to be triggered to attack. The software that controls the computer and the devices connected to it is known as the DOS, an acronym for disk operating system. DOS commands are the core of the operating system and instruct the computer to start, stop, or continue an operation. The most popular DOS for IBM PC compatible computers is Microsoft Corporation's MS-DOS. Personal computer viruses typically infect three special MS-DOS files: IBMBIO.COM, IBMSYS.COM, and COMMAND.COM. These files are found on every system disk and become part of memory each time the operating system is loaded into the computer. The system files IBMBIO.COM and IBMSYS.COM are hidden and read-only and are not easily infected. The COMMAND.COM file, which is the default command processor of MS-DOS, is both visible and modifiable. A number of viruses have been discovered which infect this file. These three files are copied to other disks and run on other machines often enough that a virus in any of these files can spread very quickly. The action performed by viruses will vary. It could be simply the flashing of a harmless message on the screen. A virus in Aldus Publishing's FreeHand, a graphics program for the Macintosh, printed the message, "We would like to take this opportunity to convey our universal message of peace to all Macintosh users around the world" [2]. The company had to recall about 5,000 infected packages. Unfortunately, all viral behavior is not benign like this message printing or the simple infection tracing found in the experiment discussed in the opening paragraphs of this paper. There have even been reports of viruses which can slightly modify spreadsheets and other data [3]. Viruses have been found which reformat hard disks and destroy data. The destructive behavior is only limited to the warped imagination of its creator. Because of the hidden dangers involved, apparently safe software packages carrying such viruses have become known as "Trojan Horses." A viral outbreak of this sort took place last fall in the microcomputer labs at Lehigh University in Bethlehem, Pa. [4]. This particular outbreak, described below, generated a lot of publicity and caused both corporations and colleges alike to become concerned about the potential damage that viruses can inflict. THE LEHIGH VIRUS The Lehigh virus was typical of many other viruses. It sat in the COMMAND.COM file and was thus loaded into the computer whenever it was booted. The virus hid inside this file in a temporary storage space called the stack space. After infecting the same file on a number of other disks, the virus would wipe out all data and program files on the disk it was on. Backup copies were similarly infected, some users were attacked more than once. Once the outbreak had come to light, work began immediately to identify what was happening and to find a cure. Fortunately, the virus' creator made a mistake: the date on the COMMAND.COM file was altered by the infection. (It is relatively simple to keep the date from changing, so the absence of a changed file date does not guarantee that a file is virus-free.) Upon examination of the file, the contaminated stack space was discovered. Since this space is normally all zeros, student lab consultants wrote a simple program that looked at the stack space and wrote zeros over any code that was present. The virus was then erased from approximately 600 disks. If it was not for the creator's date mistake, it would have taken much longer for the Lehigh Computing Center to kill its virus. It is doubtful that any new viruses that crop up will make a similar mistake. As everything else related to computers increases in complexity, so will viruses. SIZING UP THE PROBLEM It is unknown exactly how many disks and computer systems are infected in the world. Some experts and officials are trying to keep track of the world's viruses by documenting their characteristics and occurances. For example, four versions of the Israeli virus and seven versions of the Brain virus [5] have been found. The Israeli virus was supposed to do some kind of damage on May 13, 1988, the fortieth anniversary of the founding of Israel. The Brain virus was originally written to warn would-be software pirates of a software package for physicians written by Basit Farooq Alvi, a 19-year-old from Pakistan. The Brain has since evolved to data destruction. VIRUS HYPE Fueling the scare is indeed a problem and has led to what has become known as the "Virus Hype." The press and media has been notorious for spreading rumors and partial truths about viruses. Besides causing undue panic and fear amongst computer users, the virus writer is getting notoriety and fame. This is shown in a statement from Stephen D. Morrison, a student from the University of Manitoba. When asked about the future of viruses, he responded with the following: "The scenario could be a mad-hacker, plugging away at a keyboard in the back of a dimly lit office, creating a virus like no virus ever seen before." This view angers professionals in the computing field. Ivars Balkits, an official from Computing Services at the University of California - Davis, stated, "Depicting the virus writer as a gothic/romantic figure (like pirates have been, like gangsters have been, like gang members now are) contributes to the problem. Continuing to fictionalize the virus writer as a mad scientist, a Doctor Frankenstein whose genius gives us a secret thrill, whose lawlessness challenges us, is just the wrong way to go." Another approach to stopping the hype and actually tracking the viruses is "The Dirty Dozen" maintained by Eric Newhouse [6]. This is a file, originally started by Tom Neff, which lists unlawfully copied or modified programs that have appeared on various IBM bulletin boards across the country. Newhouse hopes that this list will act as a "clearing-house" for the latest examples of "bogusware," i.e. software that is damaging to one or more parties. Currently there are almost 50 destructive programs listed. In addition to the list of bad software, the Dirty Dozen contains definitions of viruses and other destructive programs, instructions on what to do if a virus causes damage to a system, and a glossary of many of the confusing acronyms and terms used in the computer field. A list of addresses to send additions and corrections to the Dirty Dozen, along with comments to Eric Newhouse, is included in APPENDIX 1. Copies of the Dirty Dozen can also be obtained from the bulletin boards in the list mentioned above, as well as from many different electronic bulletin boards across the country. DETECTION Fred Cohen, now a member of the Electrical Engineering faculty at the University of Cincinnati, stated in a lecture at the IBM Watson Research Laboratory in Hawthorne, NY, that there are three ways to detect a virus: by its appearance, by its behavior, or by the changes it causes. Detection by appearance is undecidable since all viruses do not "look" alike. It is extremely difficult to look at a good-sized program written in assembly language and tell what it does. With an executable program, it is nearly impossible. Detection by behavior involves examining programs as they are executing and is also not very promising. Besides being disruptive by slowing down execution times, it produces too many false positives and false negatives. Initially, viruses were caught by having a monitor program watch for certain internal MS- DOS and BIOS system calls which are normally used to access system hardware, but now that is no longer the case. BIOS is an acronym for basic input/output services. Since hardware varies from machine to machine, the BIOS is used to abstract the operating system from the specific hardware it's running on. The BIOS directly controls all of the input/output devices, such as the monitor and the disk drives, according to instructions received from MS-DOS or an executing program. Unfortunately, viruses can bypass MS-DOS and BIOS system calls. It is relatively simple to go to a computer store and purchase literature that describes where MS-DOS and the BIOS keep the information they need about a disk, and also tells what port addresses do what on a PC. In order to insure compatibility between different brands of PC's, every computer manufacturer has to use the same BIOS data areas and the same port addresses. It is no mystery to find out exactly what a program has to do to get its hands on the hardware. Detection by change is easy to forge and can be very costly. Early viruses were found to simply append themselves onto files and thus change the file size or possibly change the file date, as in the Lehigh virus, viruses have become much more elusive. Existing files can have viruses implanted inside without changing their file length or modification date. It is also not very beneficial to use an erased hard disk as an indicator of viral presence. PREVENTION STRATEGIES "Prevention is the best medicine" is a phrase heard many times before, but this small advice is very true in the case against viruses. The key is education. There must be an awareness among users from the hobbyist to system managers of the potential dangers of viruses. Obviously, paranoia is not the goal but a general understanding must be achieved. With today's ever growing dependence on computers, ignorance will cost a heavy price, if it has not already. Therefore, steps must be taken to curtail the likelihood of viral destruction. Governmental legislation needed is already in progress: a House bill, the Computer Virus Eradication Act of 1988, was introduced in June that will make infesting computers with viruses a federal crime. A copy of this pending bill is in APPENDIX 2. Several other legislative acts have also been proposed. Currently, 48 states have computer crime laws. Fortunately, there are some guidelines that, if followed, will go a long way in keeping one's computer system virus-free. Of course, these guidelines are only as effective as the extent to which users are willing to implement them. These guidelines are divided into three areas - protection of diskettes, protection for the computer, and protection of systems interconnected by a local area network (LAN). DISK PROTECTION The first thing to do is not to use the original or master diskettes to execute the programs. Copies of all the original source disks should be made and used instead. The originals should then be stored in a safe place, out of sight. Although it is inconvenient, it is better to have the storage place far away from the computer or system itself. If there ever is any question as to the integrity of one of these copied files or disks, it can always be compared against the safely stored-away master copy. It is a very good idea to start using the write/protect tabs that so often get thrown away. These little stickers, usually black or aluminum colored gummed paper tags, can really save the day when it comes to inadvertent writes. Once a tab is in place, it is impossible for the computer to write on the disk. Besides being found on every system disk, the COMMAND.COM file is also a favorite hiding place for viruses. This file, as well as most others, can and should be made read-only without affecting its use. This can be easily done with the MS-DOS "ATTRIB.COM" program. Many other utility programs, such as those listed following the paper in APPENDIX 3, can also accomplish this task. COMPUTER PROTECTION The goal of virus protection can only be accomplished by limiting computer access. This strategy is simple: keep the computer "clean" by keeping the virus out. First and foremost, only tested software should be used. Also, a computer should never be booted up with an unfamiliar disk. This means that a user must be especially cautious and extremely careful with public-domain or shareware programs. Most viruses have a hibernation or incubation period, so even a seemingly good disk from a friend, co-worker, or other source can be infected. To protect a computer's existing files, it is advisable to establish a good method for backing up files on a regular basis. One strategy is to do incremental backups three times a week and perform a complete backup every two months. File attribute (FAT) tables can and should also be backed up. The intervals between backups should correspond to the amount of activity on the computer. When the computer is not in use, turn it off and lock it up. When a machine is left turned on and unattended, there is no way to know what has been installed or run on it while it was unsupervised. This implies that a computer should never be used unless the user personally boots it up. As far as locks are concerned, it is usually negligible to have a key lock installed. Software locks on PC's are easy to bypass and should not be trusted. LANS AND VIRUSES Beside interconnecting users, LAN's can provide a excellent route of propagation for viruses. In response to their initial virus attack, the computing center at Lehigh University has been taking many steps to reduce the possibilities of any new outbreaks. According to Kenneth van Wyk, a senior consultant at Lehigh, additional precautions to those mentioned above should be taken. The procedures in effect at Lehigh University's PC laboratories, which can also be applied to other distributed computing environments, are the following: 1) All public microcomputers contain dual floppy drives and are connected to LANs (Novell on 3COM boards). The hard disks were removed. 2) All boot disks are notchless and contain nothing other than the operating system boot files and the Novell software needed for the LAN. 3) All Novell hard disks on the file servers are read- only, with the exception of a "scratch" area where users can place their temporary files. 4) The "scratch" areas get erased periodically by Lehigh's student employees. 5) Users logging into the LAN are not automatically placed in the scratch directory. VACCINES With the growing publicity and concern over viruses, there has been a sudden upspring of so called "vaccines". It may even seem that the number of these programs are quickly catching up to the number of known viruses. Keep in mind, however, that none of these programs are 100% cures, and that many take a different approach in trying to solve the same problem. Probably the best attitude to take regarding these "vaccines" is the that of the Paul Mace Software Company - "Understand, the people who make these (viruses) are clever and we haven't seen their worst. We're clever too, and will keep on improving the vaccine." Several of the software/hardware products of this nature that are designed for personal computer use at home and in industry are listed in APPENDIX 4. AFTER THE ATTACK Even though precautions are taken, the worst sometimes happens: a virus evades the lines of defense and wreaks havoc. Even if a hard disk does manage to crash, regardless of whether it was virus-induced or not, all is not necessarily lost. Some investment of time may be needed, but the data can usually be recovered. There is no better remedy for a crash of any kind than a recent backup. Unfortunately, if the virus was backed up along with the rest of the disk, restoring the backup contents may bring the virus back to life. If this happens and another crash occurs from the restoration, it is time to do either a lot of detective work or seek professional help. Once a crash has occurred, the first step is to remain calm. The strong urge to shout and destroy nearby office furniture has to be suppressed. After this is done, the damage must be surveyed. The crash is probably a result of the virus doing one of the following: 1) Formatting the disk 2) Scrambling the FAT (File Attribute) table 3) Erasing files 4) Corrupting the disk's boot sector The amount of data that can be recovered depends on the cause of the crash. At this point if you do not know what you are doing, it is well worth the time and money to find someone who does. Recovering data from a crashed disk is a highly technical matter. Further information on the above causes and their remedies are provided in APPENDIX 5. Any improper attempts by an inexperienced user can result in permanent data loss. FURTHER INFORMATION One of the best ways to learn more about viruses and related topics is through VIRUS-L, an electronic mail discussion forum for sharing information about computer viruses. The computer that handles this forum is located at Lehigh University and is a result of the need for more information about viruses after the Lehigh outbreak. There are currently several hundred subscribers to the list from academic and corporate institutions from all over the world. Discussions on the list include current events, virus "sightings," practical and theoretical virus prevention methods, and questions/answers about viruses. The discussions on this list are extremely informative and educational. The list is non-moderated and non-digested, which means that any message sent to the forum goes out immediately to all subscribers. All submissions to VIRUS-L are stored in weekly log files which can be down-loaded for later reference. Also, there is a small archive of some of the public anti-virus programs which are currently available. In order to get on the mailing list, a user must have access to the BITNET network, which is possible through ARPANET, Internet, and several other networks. If this is the case, than the user only has to send the message "SUB VIRUS-L " to . Questions and comments about VIRUS-L can sent to the list's moderator, Kenneth van Wyk, at the addresses listed in APPENDIX 6. SUMMARY Computer viruses, like their biological counterparts, are constantly changing. It is impossible to predict the course that future viruses will take. According to William H. Murray of Ernst & Whinney, "if you can conceive it, and if it could be done by any other program, then it can be done by a virus." The prevention and protection methods discussed here are not infallible since they will need to adapt to the dynamic nature of viruses. This paper is meant to serve as a useful introduction to the nature of viruses and how they must be confronted. If this information is understood, the warnings heeded, and the basic precautions taken, the probability of a virus attack should be lessened. APPENDIX 1: The Dirty Dozen Eric Newhouse, the editor of the Dirty Dozen, can be contacted for more information at the following addresses: 1) The Crest RBBS/CAMS (160/50 MB), 213-471-2518, 1200/2400. (This is Eric Newhouse's bulletin board) 2) The West LA PC-STORE (50 MB), 213-559-6954, 300/1200/2400. 3) Camelot PC-Board (80 MB), 213-204-6158, 300/1200/2400 - leave E-mail to "NORMAN TEETER" and it will be relayed. 4) The Source - leave E-mail to "Doctor File Finder" (Mike Callahan) in IBM SIG #4 and it will be relayed. APPENDIX 2: The Computer Virus Eradication Act of 1988 Whoever knowingly -- (1) inserts into a program for a computer information or commands, knowing or having reason to believe that such information or commands will cause loss to users of a computer on which such program is run or to those who rely on information processed on such computer; and (2) provides such program to others in circumstances in which those others do not know of the insertion or its effects; or attempts to do so, shall, if any of such conduct affects interstate or foreign commerce, be fined under this title or imprisoned not more than 10 years, or both. Entered July 14th 1988 by Mr. Wally Herger (Congressman from CA) for himself and Mr. Bob Carr (Congressman from MI); referred to Committee on the Judiciary. APPENDIX 3: Disk Utility Programs 1) PC-Tools, Central Point Software. $80. 2) Mace+ Utilities, Paul Mace. $100. 3) Advanced Norton Utilities, Peter Norton. $150. APPENDIX 4: Vaccine Products 1) Antidote by Quaid Software, Toronto, Canada. Detects viruses but allows the user to correct the problem. $60. 2) C-4(Cylene-4) by InterPath Corp., Santa Clara, CA. A program that resides in ROM and looks out for viruses. If found, computer activity halts and C-4 warns the user. $30. 3) Data Physician by Digital Dispatch Inc., Minneapolis, MN. Protects and remove viruses from MS-DOS based computers. 4) Disk Defender by Director Technologies Inc., Evanston, IL. An add on board that will guard the hard disk. 5) Disk Watcher by RG Software Systems, Willow Grove, PA. A memory resident utility that "watches" the disk drives to prevent accidental writes or formats. $80. 6) Dr. Panda Utilities by Panda Systems, Wilmington, DE. A set of programs that checks files from BBS and other software before letting them used. $80. 7) FluShot by Byte's BIX. A free utility. Contact BYTE magazine or BIX for more information. FREE. 8) Mace Vaccine by Paul Mace Software, Ashland, OR. It provides write protection for system files. $20. 9) NTIVIRUS by Orion Microsystems, Quebec, Canada. Monitors the system files for viruses. $30. 10) Passcode System by Dynamics Security Inc., Cambridge, MA. Complete hardware software protection system. $200-$2000 depending the size and components needed. 11) Syringe,Canary,Infect by Sophco, Boulder, CO. Three programs that will "quarantine" a bad disk, test and remove viruses. $30. 12) Vaccinate by Sophco. A "milder virus" that will warn the user of other viruses. $195. 13) Virusafe by ComNetco Inc., Bernardsville, NJ. Checks the system memory for viruses then prevents them from being used. $250. 14) VirAlarm by Lasertrieve Inc., Metuchen, NJ. Stores programs on CD-ROM after making sure they are virus- free. 15) Virus Implant Protection by LeeMah DataCom Security Corp., Hayward, CA. Uses a dedicated PC to "monitor unauthorized activities" on other networked computers. 16) Vaccine by FoundationWare, Cleveland, OH. "5 levels" of protection from write-protect to checksums. $189. APPENDIX 5: Recovery from a Disk Crash Recovering information on a formatted disk depends on the method of formatting. If the disk was low-level formatted, then the contents of the files and the directories referencing them have been over-written. The only hope of recovery is a backup. If the disk was high-level formatted, then the disk contents have not been erased and are recoverable to some degree. Unformatting programs have been written to reconstruct the contents on the disk. Since MS-DOS breaks up or fragments large files and stores the pieces wherever there is room on the disk, complete recovery is only possible if the unformatting programs have a "picture" of the disk before the crash. This picture is generally taken by a utility accompanying the unformatting program. Several of these programs are listed above in APPENDIX 3. If the FAT table has been scrambled, it can be rebuilt. Two of the three disk utility programs listed below, Norton Utilities and PC-Tools, include editors that allow an experienced user to piece together a FAT table. This is not easy and requires a large amount of experience and a high degree of proficiency. The other alternative involves finding a FAT backup program and making periodic backups. A number of FAT backup programs are public domain and can thus be obtained from a trusted friend or trusted computer bulletin board. If files were erased and the FAT tables are still intact, then the files may simply have to be unerased. All three of the disk utility programs listed in APPENDIX 3 can do this. When a file is erased, the first character of its name is usually changed to a non-printable character to indicate that it is no longer a valid directory entry. Everything else is left intact. Since the contents of erased programs are over-written by newer programs, it is best to unerase the files the most recent files first. If this is not done, a previously erased program may grab part of a newer file. The last cause of a disk crash is when the boot sector is either erased or formatted. In this case, the data is still safe on the disk, but the disk cannot be booted from. Another system disk in a floppy drive can be used to boot the system. Before proceeding any further, backup the hard disk in case any damage is done trying to restore the disk to boot status. The first thing to try is running the MS-DOS "SYS.COM" program. This program will copy the system files from one disk to another. After this is done, COMMAND.COM will have to be copied to the crashed disk using a simple "COPY" command. Information on this procedure is available in the MS-DOS manual. If this does not work, Mace+ Utilities has a function called "restore boot sector" which should be tried. If all else fails, the disk should be first backed up and then low-level reformatted. Instructions for this procedure should either come with the computer or are available from a computer store. After this is done, the MS-DOS program "FDISK.COM" be run to prepare the disk for high-level formatting. This formatting is done with the DOS "FORMAT.EXE" program. The DOS manual should be consulted before running any of these MS-DOS commands or programs. When everything is completed, the backup can be restored. APPENDIX 6: VIRUS-L The moderator of VIRUS-L, Kenneth van Wyk, can be contacted for more information at the following addresses: 1) on Internet 2) on BITNET 3) Kenneth van Wyk User Services Senior Consultant Lehigh University Computing Center Bethlehem, PA 18015 (215) 758-3900 REFERENCES [1] Fred Cohen, "Computer Viruses", PhD dissertation, University of Southern California, 1985. [2] P. Honan, "Beware: It's Virus Season", Personal Computing, July 1988, p36. [3] P. Karon, "The Hype Behind Computer Viruses", PC Week, May 31, 1988, p49. [4] Fred Cohen, "On The Implications of Computer Viruses and Methods of Defense", University of Cincinnati, unpublished. [5] J. Pournelle, "Computing at Chaos Manor", BYTE, July 1988, pp198-200. [6] E. Newhouse, "The Dirty Dozen", Issue #8a, February 21, 1988. ========================================================================= Date: Mon, 12 Sep 88 08:30:00 MDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Bernie' Subject: Re: Infecting "Good" Viruses In-Reply-To: Message of 12 Sep 88 00:04 MDT from LYPOWY I'm thinking more of viri which hide themselves on unused sectors. Mind, running a utility that erases all unused sectors and checks all files against the vtoc would be just as effective? ========================================================================= Date: Mon, 12 Sep 88 16:26:53 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Joe McMahon Subject: Re: hypercard virus question In-Reply-To: Message of Tue, 6 Sep 88 16:48:00 EDT from <$CAROL@OBERLIN> >My colleague (bitnet address PRUSSELL@OBERLIN) asks: > > Does anyone know if Hypercard stacks are capable of carrying > Macintsosh viruses? Are they considered applications or data? > Yes. The first known Mac virus was spread via a Trojan horse HyperCard stack. It is also possible to write self-propagating XCMDs/XFCNs which can spread viruses. Lastly, it is possible to write viruses in HyperTalk (the HyperCard language) which can spread only from stack to stack. --- Joe M. ========================================================================= Date: Mon, 12 Sep 88 11:52:11 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: SHERK@UMDD Subject: Re: CRC vs. encryption schemes In-Reply-To: Message received on Tue, 30 Aug 88 19:00:38 EDT Sorry if this is a bit late in the conversation but I have been on vacation. Dr. Levine is quite right when he states that there are two distinct times when one wants to check an application's integrity. One time is when you recieve a program distribution and you want to check if you got a good copy. Another time to check an application is at boot time or before you exec it. It seems to me that these two types of checking could use two different schemes. Scheme 1: Software distribution. The publisher of a software product should publish a list of several different CRC polynomials and their results. Say two or three. This way, the recipiant can check his downloaded software with a couple of CRCs. I do not beleive it is possible for two different programs (i.e. the original and the infected) to have the same CRC number for two different CRC polynomials. That is: if CRC( prog1, poly1) equals CRC( prog2, poly1) then CRC( prog1, poly2) can not equal CRC( prog2, poly2). Scheme 2: Personal CRC Once you have verified that you recieved a good copy you can then pick your own personal CRC polynomial out of the 70 million "irreducible" polymonials. (You should pick one that is different from the published one.) Then record the CRC number and use this new CRC in the future. It seems to me that this dual approach would be hard to beat. Erik Sherk Computer Science Center, University of Maryland. sherk@umd5.umd.edu ========================================================================= Date: Mon, 12 Sep 88 21:21:11 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: me! Jefferson Ogata Subject: crc polynomials It IS possible for two different programs to have the same CRC for two different polynomials. - Jeff Ogata ========================================================================= Date: Sun, 11 Sep 88 12:24:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: WHMurray@DOCKMASTER.ARPA Subject: Re: Different Operating Systems In-Reply-To: Message of 7 Sep 88 20:28 EDT from "David.Slonosky%QUEENSU.CA at CUNYVM.CUNY.EDU" David Slonosky asks "Are all operating systems equally vulnerable?" Of the examples that he calls out the answer is essentially yes. This is because they are all designed for personal computing and for single state processors. However, we when you get into multi-state systems you begin to enjoy the opportunity for high integrity procss-to-process isolation. At that point operating systems begin to differ dramatically in their ability to resist viruses. They differ in terms of the amount of generality, flexibility, and transitivity that they reserve to the user. The more that they are prepared to reserve to themselves, the more resistant they are. Applications also vary dramatically. Those that do not permit user programming (yes Virginia, there are such applications) are significantly less vulnerable than those that do. Those that maintain strong segregation between data and procedure are also less vulnerable. William Hugh Murray, Fellow, Information System Security, Ernst & Whinney 2000 National City Center Cleveland, Ohio 44114 21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840 ========================================================================= Date: Mon, 12 Sep 88 22:55:54 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: David.Slonosky@QUEENSU.CA Subject: Re: Different Operating Systems In-Reply-To: > >David Slonosky asks "Are all operating systems equally vulnerable?" Of >the examples that he calls out the answer is essentially yes. This is >because they are all designed for personal computing and for single >state processors. However, we when you get into multi-state systems you >begin to enjoy the opportunity for high integrity procss-to-process >isolation. At that point operating systems begin to differ dramatically >in their ability to resist viruses. > >William Hugh Murray, Fellow, Information System Security, Ernst & Whinney >2000 National City Center Cleveland, Ohio 44114 >21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840 Ok, so what are examples of multi-state systems? Anything below the minicomputer/mainframe range? __________________________________ | | David Slonosky/QueensU/CA,"",CA | Know thyself? | | If I knew myself, I'd run away. | |__________________________________| ========================================================================= Date: Tue, 13 Sep 88 02:49:43 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: me! Jefferson Ogata Subject: data/code People seem to talk quite glibly of the distinction between data and procedure around here. What's your dividing line? One man's data is another man's procedure... - Jeff Ogata ========================================================================= Date: Tue, 13 Sep 88 04:38:10 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: David.Slonosky@QUEENSU.CA Subject: Virus research paper by ex-Lehigh student In-Reply-To: This is an impressive summary of what has been discussed on this list for the past six months (or so). Is this material copyrighted, or are we free to distribute it? __________________________________ | | David Slonosky/QueensU/CA,"",CA | Know thyself? | | If I knew myself, I'd run away. | |__________________________________| ========================================================================= Date: Tue, 13 Sep 88 07:51:09 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Ken van Wyk Subject: Re: Virus research paper by ex-Lehigh student In-Reply-To: Your message of Tue, 13 Sep 88 04:38:10 EDT > This is an impressive summary of what has been discussed > on this list for the past six months (or so). Is this material > copyrighted, or are we free to distribute it? It's not surprising that Mr. Kiels paper reflects a lot of what has been discussed here; he used VIRUS-L as a major source of information for his paper. Steve gave me permission to "do with it as I please", so I sent it out to VIRUS-L. He did want me to keep any responses that I receive so that he can read the reactions of our readers. Anyway, I don't see any problem with distributing it in its original form, as long as you give credit to Steve and his co-author. Ken Kenneth R. van Wyk Calvin: Ever consider the end of the User Services Senior Consultant world as we know it? Lehigh University Computing Center Hobbes: You mean nuclear war? Internet: Calvin: I think Mom was referring to if I BITNET: let the air out of the car tires again. ========================================================================= Date: Mon, 12 Sep 88 21:34:20 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: ENGNBSC@BUACCA Subject: Re: crc polynomials In-Reply-To: Message of Mon, 12 Sep 88 21:21:11 EDT Without annotated source, I would be reluctant to completely trust any program... And it's a little tough getting annotated source for some strange reason :-) Bruce Howells ========================================================================= Date: Tue, 13 Sep 88 09:51:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: EAE114@URIMVS Subject: Dual CRCs < It IS possible for two different programs to have the same CRC for < two different polynmials. True, for any reasonable polynomials, but it gets harder very quickly as you add more polynomials. Esp. to do it on purpose. Has anybody seen or heard of any virus designed to pass a CRC check? Or is this more work than the casual psychopath is willing to incur? EAE114@URIMVS (ERISTIC) ========================================================================= Date: Mon, 12 Sep 88 23:04:02 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Steve Subject: Re: Re: CRC vs. encryption schemes Of course it's possible to have two different programs with two different polynomials and the same CRC. In fact, two different programs can have the same CRC using the same polynomial (which is a weakness of CRC schemes). This should be immediately intuitively obvious just from realizing that the number of possible (distinct) programs is far greater than the number of available CRCs (but each program will have a CRC assigned to it anyway), so the mapping of programs into CRCs cannot be 1 to 1. -------------------------- ---------------------------------------------- Steven C. Woronick | Disclaimer: These opinions are entirely my | Physics Dept. | own. No responsibility or liability is | SUNY @ Stony Brook | assumed regarding the use or misuse or | Stony Brook, NY 11794 | the reliability of the information preceeding.| | Just kidding... -------------------------- ----------------------------------------------- ========================================================================= Date: Tue, 13 Sep 88 09:21:01 CDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Len Levine Subject: Re: Infecting "Good" Viruses In-Reply-To: Message from "Bernie" of Sep 12, 88 at 8:30 am > >I'm thinking more of viri which hide themselves on unused sectors. >Mind, running a utility that erases all unused sectors and checks all >files against the vtoc would be just as effective? > > > Not unless you have a map of all bad sectors to check against. The virus could just as well hide in sectors that it had marked as bad in the FAT. + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + | Leonard P. Levine e-mail len@evax.milw.wisc.edu | | Professor, Computer Science Office (414) 229-5170 | | University of Wisconsin-Milwaukee Home (414) 962-4719 | | Milwaukee, WI 53201 U.S.A. Modem (414) 962-6228 | + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + ========================================================================= Date: Tue, 13 Sep 88 10:56:52 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: ENGNBSC@BUACCA Subject: Re: Dual CRCs In-Reply-To: Message of Tue, 13 Sep 88 09:51:00 EDT "Casual psychopath" - that's a contradiction in terms... Also a dangerous assumption, I am sure there is at least one "professional" psychopath out there... ========================================================================= Date: Tue, 13 Sep 88 11:12:36 CDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Len Levine Subject: Re: Virus research paper by ex-Lehigh student In-Reply-To: Message from "Ken van Wyk" of Sep 13, 88 at 7:51 am >> This is an impressive summary of what has been discussed >> on this list for the past six months (or so). Is this material >> copyrighted, or are we free to distribute it? > >It's not surprising that Mr. Kiels paper reflects a lot of what has >been discussed here; he used VIRUS-L as a major source of information >for his paper. > >Steve gave me permission to "do with it as I please", so I sent it out >to VIRUS-L. He did want me to keep any responses that I receive so >that he can read the reactions of our readers. Anyway, I don't see >any problem with distributing it in its original form, as long as you >give credit to Steve and his co-author. > >Ken > It is an excellent piece of work and I will be using it (credited) in a paper I am giving this week. Many thanks. + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + | Leonard P. Levine e-mail len@evax.milw.wisc.edu | | Professor, Computer Science Office (414) 229-5170 | | University of Wisconsin-Milwaukee Home (414) 962-4719 | | Milwaukee, WI 53201 U.S.A. Modem (414) 962-6228 | + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + ========================================================================= Date: Tue, 13 Sep 88 12:29:20 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Bob Babcock Subject: Re: Infecting "Good" Viruses In-Reply-To: len@EVAX.MILW.WISC.EDU message of Tue, 13 Sep 88 09:21:01 CDT >>I'm thinking more of viri which hide themselves on unused sectors. >>Mind, running a utility that erases all unused sectors and checks all >>files against the vtoc would be just as effective? >Not unless you have a map of all bad sectors to check against. The >virus could just as well hide in sectors that it had marked as bad in >the FAT. On a standard 360K floppy disk, a virus could make space to hide most of its code by formating tracks with 10 rather than the usual 9 sectors. I know that this works because my odd-ball MS-DOS system supports 10 sector per track disk formats. There are programs which can look for non-standard sector numbers, but unless you know the sector number, you have to try every one up to 255, and that is very time consuming. You can get some protection by not accepting any disks with bad sectors. This is perhaps impractical to require for hard disks, but floppy disks are so cheap that you can just throw away any that aren't perfect. This might even be a good idea for protection against data loss due to marginal media, which is probably more likely than a virus infection. (My floppy formating program does not have the capability of marking bad sectors, so it rejects imperfect disks. Even buying generic disks, I only reject 1-2%.) ========================================================================= Date: Tue, 13 Sep 88 14:18:57 CDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Len Levine Subject: Re: Infecting "Good" Viruses In-Reply-To: Message from "Bob Babcock" of Sep 13, 88 at 12:29 (noon) > ... >On a standard 360K floppy disk, a virus could make space to hide >most of its code by formating tracks with 10 rather than the >usual 9 sectors. I know that this works because my odd-ball >MS-DOS system supports 10 sector per track disk formats. There >are programs which can look for non-standard sector numbers, but >unless you know the sector number, you have to try every one up >to 255, and that is very time consuming. > >You can get some protection by not accepting any disks with bad >sectors. I what you say above is true, then no protection is good enough, since the drive would show no bad sectors and still have 10% overspace for use by the bad guys. + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + | Leonard P. Levine e-mail len@evax.milw.wisc.edu | | Professor, Computer Science Office (414) 229-5170 | | University of Wisconsin-Milwaukee Home (414) 962-4719 | | Milwaukee, WI 53201 U.S.A. Modem (414) 962-6228 | + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + ========================================================================= Date: Tue, 13 Sep 88 17:18:40 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: brian bulkowski Subject: CRCs First, having two CRCs instead of one doesn't help all that much. Remember that CRC's are polynomials, thus if you pick to prime CRCs there is a single CRC that is the same, just not prime. Second, if you publish the algorythm and the CRC it wouldn't be hard to have a virus that has the same CRC and attacks only that one program. (The algorythm I would use would be: if in program X, infect anything you can find. If you are in any other program, look for X, if you can find an uninfected one, infect it and disinfect yourself) I don't find this hard at all. BUT, if you also publish the LENGTH of the code, it would be MUCH MUCH harder, assuming there is no easy to find empty space in the code. You would have to pervert existing code along the lines of the CRC but retain functionality of the program. What I would do to go around that is to take a relativly unused portion of the program and overlay it. This, however, is user noticable (although they may quickly suspect a virus). Using the CRC means that the virus would probably have to be longer to make the CRC come out right, and I think CRC algorythms should exploit this to be hard on virus writers. Like doing the CRC on only the first bit of a long word, meaning that to get the CRC right many long words *may* be needed. Does anyone know enough math on this list to know how to calculate how long the "fudge factor" - extra bytes to make the CRC come out right - would have to be for a given CRC polynomial? That's the question. Yours Virtually, Brian B. ========================================================================= Date: Wed, 14 Sep 88 09:24:29 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: another amusing re-print from RISKS on virus existance Here's a followup on a message which I posted a couple days ago; it, too, is a re-print from the RISKS forum. Ken Date: 12 Sep 88 22:35:54 GMT From: ddb%ns%bungia@umn-cs.cs.umn.edu (David Dyer-Bennet) Subject: ``MS-DOS "virus" programs do not exist.'' (Re: RISKS-7.49) In RISKS-7.49, Mark Moore writes about a public-domain software catalog containing an article claiming that MS-DOS "virus" programs do not exist. I view this with a certain glee, because for several years I've been attempting to follow up each story about viruses I hear; so far, the story has either faded into the distance, or I have been told that they have the virus isolated, but won't show it to me. While I accept that people running academic computer centers, in particular, have some justification for taking a paranoid attitude (though I wasn't approaching them from within as a student), I've been telling people for some time that by covering up viruses the way they do, they are going to lead people to believe it's all a myth, which in the long run is bad. So let me just say, "I told you so." to those who've been concealing the evidence. -- David Dyer-Bennet, Terrabit Software ...!{rutgers!dayton | amdahl!ems | uunet!rosevax}!umn-cs!ns!ddb ddb@Lynx.MN.Org, ...{amdahl,hpda}!bungia!viper!ddb Fidonet 1:282/341.0, (612) 721-8967 hst/2400/1200/300 Kenneth R. van Wyk Calvin: Ever consider the end of the User Services Senior Consultant world as we know it? Lehigh University Computing Center Hobbes: You mean nuclear war? Internet: Calvin: I think Mom was referring to if I BITNET: let the air out of the car tires again. ========================================================================= Date: Wed, 14 Sep 88 09:46:13 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "David M. Chess" Subject: CRCs I *think* that, since a CRC is linear, you only need to be able to twiddle something like 2n bits to fox an n-bit CRC, if you know what the polynomial in use is. Figuring out exactly what the proper twiddling is is the hard part. And foxing two n-bit CRCs requires just twice as many bits, since using two n-bit CRCs is Just Like using one 2n-bit CRC (for most intents and purposes). Real mathematicians can correct me if I'm wrong (in either direction)! DC ========================================================================= Date: Wed, 14 Sep 88 10:20:35 CDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Len Levine Subject: Re: CRCs In-Reply-To: Message from "David M. Chess" of Sep 14, 88 at 9:46 am > >I *think* that, since a CRC is linear, you only need to be able >to twiddle something like 2n bits to fox an n-bit CRC, if you >know what the polynomial in use is. Figuring out exactly what >the proper twiddling is is the hard part. And foxing two n-bit >CRCs requires just twice as many bits, since using two n-bit CRCs >is Just Like using one 2n-bit CRC (for most intents and purposes). >Real mathematicians can correct me if I'm wrong (in either direction)! > >DC > I agree with David C. It might take an extra byte or two to make it work, but the agreement with n CRCs can be done fairly economically. What if the distributor were to distribute the software through one channel, and then through another channel, at a later date, distribute the CRC equation or equations used. Might that help? + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + | Leonard P. Levine e-mail len@evax.milw.wisc.edu | | Professor, Computer Science Office (414) 229-5170 | | University of Wisconsin-Milwaukee Home (414) 962-4719 | | Milwaukee, WI 53201 U.S.A. Modem (414) 962-6228 | + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + ========================================================================= Date: Wed, 14 Sep 88 09:59:52 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Joe McMahon Subject: (Mac) HyperCard Virus Warning! All HyperCard user, beware! A misguided (though well-meaning, I'm sure) individual on Delphi has *** PUBLISHED THE SOURCE *** for the "Dukakis" HyperCard virus! Not only that, but it was distributed to in the Mac Digest?!?!? Prepare for an onslaught of HyperTalk viruses, folks. It's just too darn simple and (worse yet) well commented. I will be publishing the source for a "set" handler you can install in your Home stack that will help trap this particular virus. How to make sure that you don't get infected by a stack? - Refuse to use any stack which does not allow you to change the userLevel or is password-protected. - Read the handlers in any new stack, watching out for "set the script of..." I will see if I can cook up a stack which will analyze a new stack and show you any scripts which attempt to modify other scripts. It will most likely get a number of false alarms, but it will be better than nothing. I'm not going to mention a couple of ways I can think of to get round this... --- Joe M. ========================================================================= Date: Wed, 14 Sep 88 13:07:02 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: ENGNBSC@BUACCA Subject: Re: CRCs In-Reply-To: Message of Wed, 14 Sep 88 10:20:35 CDT I don't think that published CRC will be the answer - I've seen software appear on bulletin boards within a few days of it's release; as soon as a new 'clean' CRC is published, anyone who really wanted to infect it could have a new mutation set up. Bruce Howells, engnbsc@buacca.bu.edu, engnbsc@buacca.BITNet ========================================================================= Date: Wed, 14 Sep 88 14:46:00 EST Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Jerry Leichter (LEICHTER-JERRY@CS.YALE.EDU)" Subject: RE: Re: CRCs The mathematics of CRC's is very simple. The basic idea can be seen more easily by using a much simpler algorithm: Consider an input file as a very long binary number B. Choose a some fixed number N, and compute the remainder of B divided by N. The result is between 0 and N-1, and is your checksum. Suppose I have a modified file which, viewed as a long binary number, has value B'. If remdr(B',N) = remdr(B,N), my modified program will have the same checksum as the original, and will fool you. I can ensure that by computing B'' = B' - remdr(B',N) + remdr(B,N); then remdr(B'',N) is "correct". Of course, in the process I may have screwed up the program: When viewed as a set of bits, B'' may not work correctly. However, in general B' and B'' differ only in the last couple of bits, so I may get away with this. In addition, B'' + k*N has the same remainder mod N as B'', for any integer k, so I can try to fiddle things around to find a version that DOES work. Now, no one actually uses remainders of programs viewed as large integers for checksums because they are very expensive to compute. CRC instead uses a related idea: Instead of viewing the bits in the program as specifying a binary number, think of them as giving the coefficients of a huge polynomial P: The first bit is the coefficient constant term, the second the x term, the third the x^2 term, and so on. Instead of a number N, choose a polynomial Q. As before, compute the remainer of P divided by Q. The result is the check- sum. The checksum is a polynomial of degree at most deg(Q)-1. Now, you COULD view the polynomial as having real numbers as coefficients - where the input coefficients happen all to be 0 or 1 - but then it's just as hard to compute the result as to do the integer long division, and besides you don't get some advantages I'll mention in a moment. Instead, you view the coefficients of P as being in the integers mod 2, which is a perfectly good field to do arithmetic in. You must then chose Q to be a polynomial over the same field - so all its coefficients are 0 or 1 - and the same with the remainder (so the remainder is just a bunch of bits, too). Arithmetic for integers mod 2 is very simple: Addition is the same as XOR, and multiplication is the same as AND. It turns out that you can implement this very simply as a feedback shift register. What this comes down to is imagining your high-school long-division algorithm for polynomials, simplified in two ways: The arithmetic is XOR's and AND's, and the quotient doesn't matter - all you need is the remainder. The first of these allows for very simple circuitry. The second means you can toss away high-order terms as you finish with them: You only need to work on a segments as long as Q is. Further, the process just proceeds right to left, never looking ahead or back; so you can checksum a stream of bits "on the fly", as you send or receive them. These properties make CRC's very easy to compute. In addition, they have a nice property which is easy to see from just thinking about the way polynomi- als work: If you flip some bits of P, but no two bits you flip are further apart than the degree of Q (plus 1), then the remainder ALWAYS changes. What this means is that CRC's are very good at detecting "burst" errors: Groups of clobbered bits close to each other. The errors seen on communications lines are usually the results of short "noise events", and are thus burst errors; so CRC's are an excellent choice for detecting them. Also, errors on disks are usually the result of physical damage to a tiny piece of the disk surface, so they, too, are burst errors. Same for tapes. That's why CRC's are so widely used. The burst error detection capability is quite irrelevent for many applica- tions. For example, I've seen people use CRC as hash functions in hash tables. This is a waste of effort; there are much simpler, easier to compute functions that will work just as well in this application. Similarly, CRC's as such have little to recommend them as signature functions. If you think about how they work, you'll see that fooling a known CRC is very easy - even easier than in the case of the "remainder mod N" example, since you can produce any CRC you want by modifying just the trailing deg(Q)+1 bits of the input. What Rabin pointed out, however, is that if you DON'T know the polynomial, then your chance of making just the right modification is essen- tially the same as that of guessing the polynomial, which can be made small by chosing the polynomial from a suitably large set of candidates. -- Jerry ========================================================================= Date: Wed, 14 Sep 88 13:52:20 CDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Kevin Trojanowski Subject: Virus in bad sectors Something I thought of on the way to work today, concerning the idea of a virus hiding in sectors marked as 'bad' in the FAT (or VTOC, or whatever). Would it not be possible to write a device driver of sorts which checks all sector reads against sectors marked as 'bad' in the FAT? Then, if the sector is indeed a 'bad' sector, return an error without allowing the sector to be read at all. One hole I can think of in this is if the author of the virus circumvents it by doing direct reads with the hardware, avoiding DOS altogethor. But that seems a little more in depth than the average (but not all) virus author would be willing to go. -Kevin Trojanowski troj@umaxc.weeg.uiowa.edu fstkkvpg@uiamvs.bitnet (if Internet access isn't an option) ========================================================================= Date: Wed, 14 Sep 88 14:02:08 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: me! Jefferson Ogata Subject: crc polynomial bit twiddling It all depends on the nature of the polynomial involved. Consider the scheme: s(i+1) = s(i) + (x[i] ** 3). That is, the CRC is the sum of all cubes of bytes in the file (lower 16 bits). In most cases, it'll take a lot more than 32 bits of twiddle factor to hit the same CRC. Approach the problem in the following fashion: the original file has some CRC m; the virus code has the CRC n. In this CRC scheme, the CRC of the combined file, i.e. after infection, is (m + n) mod (2 ** 16). There are two cases: one where m + n >= 2 ** 16, and one where m + n < 2 ** 16. Consider the latter case. It is desired that (m + n) = m. For this to happen, the virus must have a CRC of zero. Consider the other case. Here we want (m + n) mod (2 ** 16) = m. As in the first case, the virus must have a CRC of zero. So it is clear that the virus must have a CRC of zero in order for it to escape CRC detection. In order to get a zero CRC, we must pick bytes to add to the virus that drive all the one-bits out of the CRC sum. This can be done as follows (C algorithm): while (crc () mod (2 ** 3)) addbyte (1 ** 3); while (crc () mod (4 ** 3)) addbyte (2 ** 3); while (crc () mod (8 ** 3)) addbyte (4 ** 3); etc. Note that we cannot simply compute the sum of these bytes and add that, because for any x and y, ((x + y) ** 3) <> (x ** 3) + (y ** 3). If we could find a sequence of bytes that has the same CRC as the sequence generated by the above algorithm, we could use that sequence, but doing so would be VERY difficult. In order to arrive at a CRC of zero with only 32 bits of twiddling, the CRC n of the untwiddled virus must be such that (n + a + b + c + d) mod (2 ** 16) = 0, where a, b, c, and d are four perfect cubes of numbers less that 256. While any positive integer can be expressed as the sum of four perfect squares, it will usually require more than four perfect cubes. Of course, this is a case of a cubic CRC polynomial. Consider the linear scheme: s(i+1) = s(i) + x[i]. This is merely the sum of all bytes in the file (lower 16 bits). Even this scheme requires that you add about 2 ** 8 bytes in some cases. Suppose the untwiddled virus has a CRC of one. To hit zero, you must add bytes whose sum is 65535. You'll need 257 bytes to do this. (65535 / 255 = 257) - Jeff Ogata ========================================================================= Date: Wed, 14 Sep 88 15:25:11 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: ENGNBSC@BUACCA Subject: Re: (Mac) HyperCard Virus Warning! In-Reply-To: Message of Wed, 14 Sep 88 09:59:52 EDT Well, I guess we finally have "proof" of the existence of a virus... Bruce Howells, engnbsc@buacca.bu.edu / engnbsc@buacca.BITNet ========================================================================= Date: Wed, 14 Sep 88 15:42:33 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: portal!cup.portal.com!Dan-Hankins@SUN.COM Subject: Student paper The paper has one flaw in it that I can see. It claims that Trojan horses carry viruses in terms that imply that that's *all* Trojans do. This can clearly not be the case, as I personally know of many Trojans that do not carry self-replicating programs. Additionally, the term Trojan Horse as it is used in the computer world was coined long before the term virus. Dan Hankins "These opinions are mine, and mine alone. They are not for sale. They may, however, be rented or leased at reasonable rates." ========================================================================= Date: Wed, 14 Sep 88 16:52:35 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "David M. Chess" Subject: crc polynomial bit twiddling - reply to J. Ogata By "CRC", I meant the usual thing that's called a "cyclic redundancy check", described so well just now in Jerry Leichter's posting: the remainder when you treat both the data and the polynomial as polynomials over the field [0,1], and determine the remainder when dividing the one by the other. I don't think the examples that you give are CRCs in that sense? The examples you give are, I think, nonlinear in places that a real CRC is linear, and therefore may be harder to fox with control of a small number of bits. I intended my posting only to apply to real CRCs, not to signature algorithms in general. DC ========================================================================= Date: Wed, 14 Sep 88 17:36:55 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: me! Jefferson Ogata Subject: crcs It is true that the schemes I was discussing are not true CRCs. They would probably be termed 'checksums'. - Jeff Ogata ========================================================================= Date: Wed, 14 Sep 88 18:04:00 EST Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Jerry Leichter (LEICHTER-JERRY@CS.YALE.EDU)" Subject: RE: crc polynomial bit twiddling Jefferson Ogata discusses checksums of the form s(i+1) = s(i) + p(b[i+1]), where b[i] is the i'th byte of the text to be checksummed and p is a polynomial (actually, he only suggest p(x) = x^k for some k). a) This is a checksum based on polynomials, but it is NOT what "CRC" refers to. "CRC" has an established meaning in the computer science/electrical engineer- ing/coding theory fields. It means a checksum computed as the remainder mod a polynomial over Z mod 2. b) Ogata suggests that even in the simple case p(x) = x, with a 16-bit sum of 8-bit unsigned bytes as the checksum, producing a particular checksum might require adding 65535 bytes to the file (e.g., if the file had a checksum of 1 and the checksum you needed to fake happened to be 0). This is true but again illustrates the dangers of not understanding the model you are working with. If the goal is to prevent the wholesale replacement of the original file by another distinct but pre-specified file, such a checksum might be worthwhile. However, your opponent normally CHANGES the original file, he doesn't replace it. If your opponent needs to change k bytes of your file, he can always hide the changes by changing some other k bytes: For each byte he added d to, he subtracts d from some other byte in the file. Note that this doesn't change the length of the file at all. The same basic attack works for any polynomial p with the given scheme. By the way, any such scheme has a much more profound weakness: It is not sensitive to re-ordering of the bytes in the file. I can probably find all the bytes I need to construct my virus SOMEWHERE in your program. I need only move them to the place I want them. (Of course, if it's a data file like a checking account record you are talking about, changing $109 to $901 is also rather effective. :-) ) Sure, I'll break something in your program using either of these techniques, but by the time you happen to use what I broke it will probably be way too late to help you. Changing Ogata's algorithm to: s(i+1) = p(s(i)) + b[i] eliminates the rearrangement hole, and generally makes the previous "modify bytes in pairs" attack impossible, but it has other vulnerabilities. (BTW, with p(x) = kx for a suitable k, this is my favorite algorithm for generating a hash code in hash table algorithms. I ignore overflows and chose k so that r(i+1) = kr(i) is a good linear congruential random number generator mod 2^n, assuming the arithmetic uses n bits. This also makes a fairly good checksum for detecting transmission errors - not as good as CRC, but very, very easy to compute quickly in a tiny piece of easily portable code.) Remember, the security of a technique is not based on how well it resists the attacks YOU thought of, it is based on how well it resists the attacks your OPPONENT thinks of! -- Jerry X-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-X Another file downloaded from: The NIRVANAnet(tm) Seven & the Temple of the Screaming Electron Taipan Enigma 510/935-5845 Burn This Flag Zardoz 408/363-9766 realitycheck Poindexter Fortran 510/527-1662 Lies Unlimited Mick Freen 801/278-2699 The New Dork Sublime Biffnix 415/864-DORK The Shrine Rif Raf 206/794-6674 Planet Mirth Simon Jester 510/786-6560 "Raw Data for Raw Nerves" X-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-X