VIRUS-L Digest Wednesday, 14 Feb 1990 Volume 3 : Issue 42 Today's Topics: WDEF at Naval PG School (Mac) "Expert System" virus scanner Forwarded: Re: *UNCONFIRMED* PC virus Re: The AIDS "Trojan" is a Copy Protection System Retraction of previous statement (Mac) Strange Beep... (Mac) AIDS -program? AND Class Action Suit Can DOS Extensions (indirectly) help fight viruses? (PC) Re: Jerusalem-B (PC) Re: Checksums Re: Identification strings How to notify campus community members about viruses The AIDS Trojan as Copy Protection Scheme The ethics of virus eradication VIRUS-L is a moderated, digested mail forum for discussing computer virus issues; comp.virus is a non-digested Usenet counterpart. Discussions are not limited to any one hardware/software platform - diversity is welcomed. Contributions should be relevant, concise, polite, etc., and sent to VIRUS-L@IBM1.CC.LEHIGH.EDU (that's LEHIIBM1.BITNET for BITNET folks). Information on accessing anti-virus, document, and back-issue archives is distributed periodically on the list. Administrative mail (comments, suggestions, and so forth) should be sent to me at: krvw@SEI.CMU.EDU. - Ken van Wyk --------------------------------------------------------------------------- Date: 13 Feb 90 20:27:20 +0000 From: kulp@cs.nps.navy.mil (Jeff Kulp x2174) Subject: WDEF at Naval PG School (Mac) WDEF A was found on one Mac in a restricted use Mac Lab. The virus was removed using Disinfectant 1.5. Jeff Kulp kulp@cs.nps.navy.mil [Ed. Due to the sheer volume of WDEF infection reports... Someone recently asked for all WDEF infection reports to be sent to the list; could that person please identify him/herself to me, and I'll start forwarding these reports directly to him/her? Thanks.] ------------------------------ Date: 13 Feb 90 22:26:20 +0000 From: russ@Alliant.COM (Russell McFatter) Subject: "Expert System" virus scanner USERGSVE@LNCC.BITNET (GEORGE SVETLICHNY) writes: >Now there just _*MAY*_ (note the triple enphasis) be a theorem of the >following type: > > I. Given such-and-such memory and microprocessor architecture, > then any program containing a virus (however that is defined) > will necessarily have a certain patern P in the object code. > II. Any program that does not contain a virus can be written in > a way that does not lead to pattern P in the object code. I was going to suggest this type of approach myself; if "pattern" is very loosely defined, as is "virus". I put forward this simple hypothesis: An algorithm (A) exists which can positively determine that a given set of programs (Pg) do NOT exhibit harmful behavior. "harmful behavior" can be defined however we want; self-reproduction, direct access to hardware, modification of other executables, and so on. Trivial proof: We can enumerate the set Pg and write an algorithm to identify a program as "good" if it is included in the set. This is not ENTIRELY impractical (a program which compares the executables on a disk to the "original" would fall in this class). This isn't very useful for most situations. We need to be able to add a statement like part II of George's theorem. Any program which is NOT harmful can be written in such a way as to satisfy algorithm A. This would be very difficult to prove. In reality, though: 1: We are not restricted to a single virus-checking algorithm; we can use a number of them (A1 ... An), each of which can "clear" a subset of the programs we wish to test. We may need to know which virus "disprover" algorithm applies to each given test subject ("You can check UltraGame PD 1.4 for virus-safety using 'class 5' checking methods"). 2: The set of "harmless" programs is not as clearly defined as we'd like; some programs that we'd ordinarily call "harmful" will be, in fact, exceptions to the rules. 3: We'd settle for a set of virus-disproving algorithms that works on MOST software, if we have other means to insure the integrity of the "exceptions" we need to install. 4: The usefulness of the virus-disprover varies with the percentage of real-world programs that it can successfully clear. 5: Measures have to be taken to make sure that the virus-disprover's environment is "clean". 6: A set of "safe" system calls could be used to decrease the number of "exception" programs. A pair of calls that create/delete temporary files, for example, could be considered "safe" by a virus scanner, as could most routines which perform "dangerous" acts after prompting the user. (PromptDelete, for example, might pop up a dialog box with a message such as: "Ok to delete ?" before deleting the file. This would be considered "safe" by the virus-disprover, unlike the call that deletes without prompting.) We can submit, to the software authors of the world, a set of rules that they must follow if we are to accept their products (hey, if the world can stem the copy-protection wars simply by refusing to purchase any software with copy protection, we can do the same for virus-testability). These can include all the difficult-to-test issues that have been mentioned here so far, such as: 1: No self-modifying code or execution of data. 2: No direct access to hardware-- use approved system calls only. 3: No modification of executable files. 4: No transformations of "data" files into executables or writing executable files (loaders/compilers would fail here). 5: Substantial restrictions on calculated (register) jumps (designed to accommodate most high-level constructs, but not much else). To some extent, these rules overlap simple good programming practice. Self- modifying code is hard to debug, direct hardware access is nonportable, computed jumps are "risky"; the others are generally "antisocial". When you think about it, you'll realize that we sometimes DO go this far to protect ourselves against viruses-- this is exactly what happens when you review source code before compiling and executing it. The fact that you're getting (high-level) source code means that the author has obeyed some rules, making the program easy to understand (so that you'll trust it), and not writing any "suspicious" or "dangerous" code. If YOU can "virus-check" a program, it seems reasonable that a computer could do some of the same, not only faster, but more reliably. - --- Russell McFatter [russ@alliant.Alliant.COM] std. disclaimer applies. ------------------------------ Date: Tue, 13 Feb 90 15:18:34 -0800 From: rogers@marlin.nosc.mil (Rollo D. Rogers) Subject: Forwarded: Re: *UNCONFIRMED* PC virus hi, does anyone else have knowledge/experience with this alleged PC virus? [Ed. As with all such reports, I urge people to NOT BELIEVE this without some reliable third party confirmation. We've all seen that rumors can be just as time consuming as The Real Thing...] Forwarded mail follows: Date: Tue, 13 Feb 90 14:52:02 -0800 From: Yong Kim Subject: Re: virus I went to a local computer store and one of the salesmen complained about the new kind of virus. He said that unlike the conventional ones (residing in the first track or other part of command.com, etc) this one lives in the setup-memory (CMOS) that was backed up by the computer battery. All the infected disketts can be reformated and can be purified, but this one lives there until human disconnects the battery from the unit and restart the machine. The story seems quite plausible and that's why I decided to hear from experts' opinion on the net. Since today's AT usually uses CMOS memory, this looks a serious problem. The story went further: once the scan program is loaded, the virus in there can recognize his eternal enemy (wel I might be exaggerating, or making a fairly tale..) and destroy it. Sounds like a SIFI fiction, but it looks like possible. I wish we had some kind of ANSI anti-virus detection scheme:-) ------------------------------ Date: Tue, 13 Feb 90 18:35:00 -0500 From: Donald.Lindsay@MATHOM.GANDALF.CS.CMU.EDU Subject: Re: The AIDS "Trojan" is a Copy Protection System munnari!mqccsunc.mqcc.mq.oz.au!ifarqhar@uunet.UU.NET (Ian Farquhar) writes: >This is not a trojan: it is a COPY PROTECTION SYSTEM. The >consequences of using the program without paying are quite adequately >laid out in the license, which apparently has not been read. >If the author of this program is convicted, it will be the first >conviction ever for the hidious crime of writing a copy protection >system, and will be one of the biggest farces of justice ever >witnessed. Well, no. 1. It is unacceptable and actionable that a copy protection system delete unrelated material. 2. Why did the "copy protection system" count down from a random number before "protecting" things? 3. Unsolicited material received in the mail is the property of the recipient, the presence or absence of a licence being immaterial. (Or, to be more precise, that is law in this country.) 4. Why did the perpetrators attempt, beforehand, to hide their tracks? And why didn't they come forward immediately? A judge will interpret this as a clear demonstration of intent. Don D.C.Lindsay Carnegie Mellon Computer Science ------------------------------ Date: Tue, 13 Feb 90 18:18:00 -0500 From: Peter W. Day Subject: Retraction of previous statement (Mac) Dave Platt is correct and I am wrong about the accessibility of the desktop file on an AppleShare server, and I appreciate his clarifying the situation. When I tried it previously, I had neglected to login to my server with adequate privileges. ------------------------------ Date: Tue, 13 Feb 90 18:12:08 +1100 From: "Alejandro Kurczyn S." <499229@VMTECMEX.BITNET> Subject: Strange Beep... (Mac) We have a strange problem here, working on a Macintosh II, sometimes it beeps when a file is open or closed and sometimes during starup. I read some time ago that a WDEF (or nVir) sounds the bell when present. So, I tested the hard disk (20 M) with disinfectant 1.6 and it didn't show anything. I also re-created the DeskTop file, but the same problem persist. My questions are: Is this a virus? how can I get rid of it? Is a know virus? Please mail me directly, Thanks in advance. - -Alejandro J. Kurczyn S. ITESM CEM Mexico ------------------------------ Date: Tue, 13 Feb 90 20:09:06 -0500 From: woodb!scsmo1!don@cs.UMD.EDU Subject: AIDS -program? AND Class Action Suit First of all can someone answer this question with a yes or no for me... Did the AIDS disk come with an AIDS program?? AND Is there anyway that a class action suit could be made for those who suffered damages against a convicted virus writer. Ie, could those hit by the famous WORM now sue for damages?? - -- DON INGLI-United States Department of Agriculture - Soil Conservation Service INTERNET: scsmo1!don@uunet.uu.net PHONEnet: 314!875!5344 UUCP(short): uunet!scsmo1!don UUCP(long): uunet!mimsy!woodb!scsmo1!don These are my opinions. I represent myself. Who do you think you are, Bjorn Nitmo? David Letterman '90 Catch Phrase ------------------------------ Date: Tue, 13 Feb 90 23:10:52 -0600 From: ST6074@SIUCVMB.BITNET (Tim Williams) Subject: Can DOS Extensions (indirectly) help fight viruses? (PC) I was wondering if running a DOS extension, like 4DOS, which totally replaces COMMAND.COM, would provide any measure of protection against a virus attack. I know that it would not provide any help directly (as a feature, I mean), but might subtle changes in the OS throw off some viruses? ------------------------------ Date: Wed, 14 Feb 90 14:05:07 +0200 From: Y. Radai Subject: Re: Jerusalem-B (PC) Michael Greve writes: > I want to thank all the people who sent me messages on using the >CLEAN program. Unfortunately the program did not work. It removed >the virus and shrank the .exe file from 260,000+ bytes to 84,000. >Needless to say this file didn't run. Does anybody have any other >ways of getting rid of this virus. Is the Jerusalem virus a >particularly difficult virus to get rid of??? Ordinarily, the Jerusalem virus is easy to get rid of using any of the common anti-virus programs (CLEANUP, UNVIRUS, F-FCHK, VB, etc.). However, a few EXE files contain a file-length in their header which is less than their actual length. If such a file is infected by the Jerusalem virus, it overwrites part of the file instead of extending it. In that case, it's obvious that no program can restore the file. There's seems to be some misunderstanding on this subject. For example, Brad Fisher writes: > The only problem is that >this paticular flavor of virus can not always be removed without some >damage to the original file ... but a least it can be removed! This is misleading; it sounds as if the disinfecting program does the damage. If the virus hasn't overwritten the file, I don't think any of the above programs ever damage the file. And if it has overwritten it, then the truncation performed by the program doesn't matter. Y. Radai Hebrew Univ. of Jerusalem, Israel RADAI1@HBUNOS.BITNET ------------------------------ Date: Wed, 14 Feb 90 13:51:12 +0200 From: Y. Radai Subject: Re: Checksums IA88000 asks: >If you had your choice, which checksum routine would you consider most >secure, and why. .... >To make the question a little more specific, of the checksum routines >available today, which would you select. It's strange that Mr. IA88000 makes no reference to the discussion which has been taking place so far on this forum. We've been talking of checksum *algorithms* and checksum *programs*, and I'm not sure which he's referring to when he writes "routine". And if he means a *program*, then for what computer. Since I have already answered the question in the case of algorithms, I'm going to assume here that he's asking which *PC* checksum *program* available today do we consider best or most secure. Among those that I've seen, the one which is certainly the most se- cure, and probably best all around, is V-Analyst (name changed from VirAlarm to avoid conflict with another product of the same name). I know the authors, Omri Mann and Yuval Rakavy, but that in no way in- fluences my evaluation. It's a commercial product, costing $79. It implements Prof. Rabin's CRC algorithm in which the generator is chosen at random from among all 31st-degree irreducible polynomials when each user initially sets up his checksum base. It is activated either on demand or by virtue of the command being placed in AUTOEXEC.BAT (which does not necessari- ly mean that it must be activated on *every* boot), and does not re- main resident. The user is given complete control over selection of the files which are to be checksummed (e.g. one can choose to checksum a small set of files on every boot and all files on the disk every two weeks) and both the initial selection and subsequent updating can be performed very conveniently, by wildcard notation and/or by "pointing- and-shooting". Most important, great care has been taken to prevent virus writers from circumventing the checksumming. This is the only program I've seen which blocks every loophole in DOS that I know of, provided check- summing is performed only when memory is uninfected (i.e. immediately after booting from a clean diskette). In May 88 this program was the subject of a $6000 bet on Israeli television. A software house threw 10 specially-written test viruses at it, and none succeeded in going undetected. (Although the attack- ers lost the bet, so did the defenders. Apparently, the judges deci- ded that in order to win, the latter would have to prove that their program could detect *all possible* viruses!) Checksumming a given file takes about 3 times as long as performing a COPY of that file to NUL. (This is on an XT; the factor is probably smaller than 3 on a faster machine.) The checksum feature of FSP is somewhat faster than this (it uses a simpler algorithm than CRC), and Sentry is much faster (since it checksums only the beginnings of files) and therefore will be preferred by some users. But both Sentry and FSP are potentially insecure. Also (as I mentioned previously), checksumming in FSP is extremely tedious (apparently the commercial version FSPP is less so), and Sentry suffers from a lack of flexibi- lity, particularly when it becomes necessary to update the checksum base. Y. Radai Hebrew Univ. of Jerusalem, Israel RADAI1@HBUNOS.BITNET ------------------------------ Date: Wed, 14 Feb 90 14:18:37 +0200 From: Y. Radai Subject: Re: Identification strings Fridrik Skulason: > Identification string: A sequence of bytes, used by anti-virus > programs to check if a program is infected. > Signature string: A sequence of bytes, used by the virus to check > if a program is infected. David Chess: >Well, by an unhappy coincidence, we tend to use the terms more or less >the other way around, around here. We call the thing that a virus >checks for the "self-identification", and we call the things that our >scanner scans for "signatures". Since the term "signature" already has too many meanings (checksum, for example), I suggest as a compromise that we drop it entirely and use the terms "scan-id" and "self-id" instead, i.e.: Scan-id = a string (or set of strings) used by an anti-virus identifi- cation program to check if a program is infected by a known virus; Self-id = a string or pattern used by a virus to detect if a program is already infected by it (or perhaps by some related virus). Y. Radai Hebrew Univ. of Jerusalem, Israel RADAI1@HBUNOS.BITNET ------------------------------ Date: Wed, 14 Feb 90 08:43:45 -0500 From: ELOISE@MAINE.BITNET (Eloise Kleban) Subject: How to notify campus community members about viruses Getting the word out to faculty, students and staff is a major problem that computer center consultants face. If you don't publicize the problem, you may be liable in some sense for damage that occurs. On the other hand, you must avoid accusing individuals or groups. For example, most of the virus infections I see are on faculty machines, and one major reason is the sharing of computer software that goes on among them. (There are other people on campus who deal more with students - I'm not implying that the students don't spread viruses also!) This is an issue that must be handled diplomatically. I publish articles in our newsletter, I make sure that the other consultants in the University system have the same info I have and the software tools, and every time I talk to a user about micro software, I mention the problem of viruses. However, we are very careful not to point any fingers. Eloise Kleban BITNET: ELOISE@MAINE Computing Center INTERNET: ELOISE@MAINE.MAINE.EDU University of Maine ------------------------------ Date: Wed, 14 Feb 90 09:28:00 -0500 From: Jim Shanesy Subject: The AIDS Trojan as Copy Protection Scheme When the AIDS trojan alerts first appeared I faxed them to a dear friend of mine, Mr. Paul R. Paletti, Jr., Esq. of Siler and Handmaker in Louisville, Ky. Paul is a licensed, practicing attorney at law. He gave me his informal opinion over the phone as to the significant facts in the case, to wit: 1) The disk was unsolicited and was sent through the mail. The recipient therefore owns the disk outright and the sender is automatically waiving any rights to ownership. The whole concept of "copy protection" goes right into the dumpster at this point. Paul was very emphatic in pointing out that there is no defense on this point. He said this is the most significant legal fact in the case. 2) The software on the disk sabotages another's personal property, with an accompanying demand for money. This is blatant extortion. No matter how profuse and explanatory any printed disclaimers may be, the intent is clear. The author is attempting to profit by placing another individual under duress. That boy's in a heap o' trouble. Jim Shanesy Office of Computer and Information Technology National Research Council 2101 Constitution Ave., NW Washington, DC 20418 [Ed. Is this the case under British law as well as U.S. law? If he did this in Britain, did he break any U.S. laws? Will Dr. Popp be tried here or in Britain? Just a few thoughts...] ------------------------------ Date: Wed, 14 Feb 90 10:22:39 -0500 From: Kevin_Haney@NIHDCRT Subject: The ethics of virus eradication With regard to Alan Federman's questions concerning the ethics of virus eradication, it has unfortunately become the prevailing tendency in many quarters, especially the business world, to deny and try to cover up incidences of viral infection. However, the situation boils down to this: A computer professional does not (usually) take any sort of oath of confidentiality. His primary responsibility is to the user community as a whole, not to any single individual. That does not mean, however, that reports of viral attacks should be distributed indiscriminately. As a professional, you have a responsibility to balance the feelings of the 'infectee' and the dangers of unnecessary hype against the danger of the possible spread of the virus and the potential damage it may cause to other people in the community. I don't know the particular circumstances of Federman's situation, but it sounds like he did exactly what should have been done. If there is a good probability that telling people about a particular virus might prevent them from getting it, then that should outweigh the potential embarrassment that a single person might suffer (especially since Federman did not reveal the particular name of the person involved). If someone were to contract the virus later and learned that you had known about it but did not warn anyone, the professional and political repercussions would most likely be greater than the scoldings of one irate faculty member (many of whom have a tendency to become irate with little provocation). To again revert to the medical analogy (which is admittedly imperfect), what if a physician who treats a very contagious disease refused to report it to the National Center for Disease Control and, as a result, the disease spread further. That would amount to an abdication of responsibility on the part of the physician tantamount to malpractice. The only situation where withholding the information would be permissible would be when, for some reason or other, there was little chance that the disease (or virus) would spread any further. Since there were a number of people on Federnam's campus studying fractals, there was a good possibility that someone else might have purchased or come across the infected program and thereby spread the virus further. So, while we all have to deal with unreasonable people occasionally, I do not think Federman's actions lacked any professional or ethical justification. _______________________________________________________ | | | Kevin Haney, Computer Specialist | | Division of Computer Research and Technology | | National Institutes of Health | | BITNET - Kevin Haney:dcrt:nih | |_______________________________________________________| ------------------------------ End of VIRUS-L Digest ********************* Downloaded From P-80 International Information Systems 304-744-2253