VIRUS-L Digest Tuesday, 13 Feb 1990 Volume 3 : Issue 39 Today's Topics: None other than WDEF (Mac) Identification strings Desktop Fractal Software Infection Confirmation WDEF A strikes again. (Mac) Virus Discussion on America Online Re: The AIDS "Trojan" is a Copy Protection System Arrayboundcheck in C Re: Universal virus detector / Biological analogy RE: Copy Protection on AIDS Diskette 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: Mon, 12 Feb 90 13:03:00 -0500 From: Down & Out Subject: None other than WDEF (Mac) I noticed a couple of messages in the list recently that asked about WDEF and servers. I also noticed talk about programs to defeat all known viruses. I also noticed that Wayne State reportd being hit. (I notice alot of things). So let me say this..... 1. Albion could have possibly gotten WDEF from Wayne State (We are located South Central MI) 2.Macserve@Pucc has a fairly good listing of virus protection and some general info on viruses 3.Here is a letter that I sent to the creator of Eradicate'em, a protection program for WDEF. Subject: Identification strings Fridrik S.: > How about: > > 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. > > Comments ? 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". (The self-identification, by the way, isn't always a string of bytes; it can be a bit-pattern in the timestamp, or just about anything else!) Note sure what to suggest to solve the problem; perhaps people can just stop to spell out what they mean when there's danger of ambiguity? DC ------------------------------ Date: Mon, 12 Feb 90 15:04:04 -0500 From: "Jill A. O'Neil" Subject: Desktop Fractal Software Infection Confirmation In reply to: >From: Eric Roskos >Subject: Re: "Desktop Fractal Design System Not Infected" >.......... that to >date there is no evidence *which has been presented on VIRUS-L* that the >Desktop Fractal Design System, as shipped from the publisher, is >infected. Here's evidence. An employee at my company purchased the Fractal software directly from Academic Press via phone order. When he placed the call he was told that the order would be delayed a few days until the second printing was complete. When he received the diskette, it was indeed infected with the Jerusalem-B virus. The virus was identified by McAfee Associates VIRUSCAN. The diskette was scanned on a standalone (diskless) PC and we used McAfee's CLEAN55 to disinfect the affected PC. > There is only the claim that it is, and the statement >(secondhand) that the publisher is "aware" of the problem. Once it was determined that the Fractal software diskette was infected, I (as Security Administrator for my work location) called Academic Press (800-321-5068). The person that answered the phone did not have any details about the infection other than to say that yes they are aware of the problem and that the diskette will be replaced if the infected one is returned to them at the following address: 465 So. Lincoln Drive, Troy, Missouri 63379 Academic Press also gave me a phone number for Iterated Systems to call if I wanted further details. When I called the number, I got no answer (I tried the number several times a day for a week). I also called the customer service number listed on the warranty and again got no answer (also called several times a day for a week). Several days after the above, the person who had the infected diskette received a letter from Academic Press. The first paragraph is as follows: "Dear Customer, You recently purchased a software package from Academic Press THE DESKTOP FRACTAL DESIGN SYSTEM written by Michael Barnsley of Iterated Systems, Inc. If the outside of your package has a round sticker in the upper right hand corner which says "VGA AND CGA COMPATIBLE", the enclosed disk is suspected of carrying a computer virus. If there is no sticker on the outside of your package, the disk you received is not defective." The letter goes on to say that AP will replace the software with a "clean version" and that they will "have an expert contact you to discuss remedies in case you have infected your computer system". >It would be helpful to those of us who have to deal with these issues to >know more about details of alleged virus infections, things such as: > - Did you personally open and install the infected disk? No I did not; however, the software was run from the diskette, not installed on the hard drive. The machine on which it was run had not had any software updates in over 3 months (implying that the virus was not previously introduced on the system via other software) and only those executables that had run after the Fractal software was executed became infected with the Jerusalem-B virus. The owner of the fractal disk also copied but DID NOT RUN the Fractal diskette on his own PC at home (this was done prior to his bringing it to the office). VIRUSCAN found the Jerusalem-B virus in the fractal executable only - no other files on his PC were infected. >- Did you write-protect the disk before doing so? unknown but probably not. >- How many copies do you have that you know to be infected? One. A sitewide desktop distribution was done hours after the virus confirmation but no other employees came forward saying they had purchased this software. >- What is the version number of the software? Is there any other > date or serial number information involved? Serial Number 03276 The only other piece of identification is the VGA and CGA compatible sticker on the outside of the package of the 2nd printing of this software that was mentioned above in the letter from Academic Press. Jill A. O'Neil Bitnet: jaoneil@erenj ------------------------------ Date: Mon, 12 Feb 90 17:28:00 -0500 From: "An adept of T'Pel." Subject: WDEF A strikes again. (Mac) In case anyone's keeping track, I spotted WDEF A on an internal hard disk plus three other system disks in the Academic Computing Labs here at Xavier University (Cincinnati, Ohio) using Disinfectant 1.5. I've informed my superiors and will warn my co-workers of this. Tom Kummer ------------------------------ Date: Mon, 12 Feb 90 17:27:55 -0600 From: "McMahon,Brian D" Subject: Virus Discussion on America Online Readers with access to the America Online service might be interested in the forum discussion announced for 22:00 EST on Saturday, 17 Feb; the forum is titled, "Viruses: Hex or Hype?," keyword FORUMAUD, and claims to feature a "real-live virus writer (who will remain anonymous)." Could be interesting. As far as the anonymous bit goes, I think I'll withhold judgement until Saturday. Certainly, there will (should) be questions for the moderators as well . . . Brian McMahon Grinnell College Grinnell, IA 50112 Usual and customary disclaimer, my opinions only ... (mumble) ------------------------------ Date: Mon, 12 Feb 90 21:58:15 -0500 From: davidbrierley%lynx.northeastern.edu@IBM1.CC.Lehigh.Edu Subject: Re: The AIDS "Trojan" is a Copy Protection System In Virus-L 3:38 Mr. Ian Farquhar defended the AIDS "trojan" by stating that it was only a copy protection system and that users were properly warned. I would like to counter his remarks with a few thoughts: 1) The AIDS disk did not have copy protection at all. Copy protection is, by definition and tradition, a mechanism that attempts to prevent unauthorized copies from being made. It is not a system that seeks out and hides (or even destroys) the user's files that have nothing to do with the software package in any way. Those unrelated files belong to the user and it is the user which has the right to decide which software packages should have access to them. I'd hate to think what it would be like if any form of "copy protection," no matter how draconian, could enjoy complete legal protection. 2) The disks were unsolicited. It is my uderstanding that none of the organizations that were mailed disks asked for them, and therefore had no way to learn about the software unless they actually used them. In the US unsolicited objects received by mail are gifts, therefore, the so-called license agreement is void (and may possibly be illegal). (Yes, I know "you should never look a gift horse in the mouth.") I don't know how the laws are in the nations that were infected but its very likely that they are similar to those of the US. I would even wager that the aforementioned postal regulation could be one of the reasons that the disk's instructions stipulated that the software could not be used in the United States. 3) The market to which the disks were targeted was especially sensitive. It is very likely that vital medical records could have been tampered with by the AIDS disk, since medical organizations were the ones that received copies. If the author was truly professional, I'm sure he/she would have marketed the package through conventional means (i.e. demo disks, advertising, etc.) Of course this aspect may not be applicable to the alleged author, if in fact his judgement has been impaired by his psychological problems and/or treatment. David R. Brierley davidbrierley@lynx.northeastern.edu ------------------------------ Date: Tue, 13 Feb 90 10:17:52 +0000 From: "Dr. A. Wood" Subject: Arrayboundcheck in C This is not a virus as such; but program mishaps cause more system upsets and loss of data than viruses do, and users should eliminate all other causes of error before definitely suspecting a virus. One main cause of mishaps is writing to arrays out of bounds. In Fortran and Algol60 and Algol68 and similar, writing a compiler so it can compile in array bound check mode is easy; but C can step pointers along by adding arithmetic values, which complicates the job a lot. I don't know if there are any C compilers with full arraybound check, but Prime's C compiler hasn't got one. Bound checking array accesses is easy; the problem is bound checking pointer accesses. I hereby submit a possible method of bound checking pointer accesses in C programs. In C, I define a as any group of stored values of all the same type which are all adjacent in store. There are these types of tables:- (1) declared at compile time with [ ] . E.g. 'int x[12],y[4][7];'. A pointer to an array is created by one of these forms:- a) An array element preceded by '&', e.g. &x[i] &y[5][j+k] b) An arrayname followed by 'too few' subscripts, e.g. y[h] c) An arrayname without subscripts, e.g. x y The arrayname can be some compound form such as a struct field or the like, e.g. 'struct {int a; char[12]c; } z; ------ z.c' . (2) alias created by calls of malloc() and similar functions, which return a pointer to the allocation thus created. (3) , i.e. consecutive members of a struct which are all of the same type, e.g. 'x,y,z' in 'struct density {float x,y,z; double value; } den;'. Pointers to them are created by prefixing a '&', e.g. '&den.y'. (4) Other cases where users are tempted to step a pointer over several values, e.g. 'a,b,c,d' in the declaration 'double a,b,c,d;', are compiler dependent and I will not consider them further. My suggestion is for all pointer values to be accompanied by two other pointer values which contain its safe range limits. (Thus sizeof(), which == 6 in Prime C ordinarily, will become 18 in Prime C compiled in array bound check mode.) Examples are:- declaration assumed pointer value lower limit upper limit type int x[4]; &x[3] &x[0] &x[4] int* int x[4]; x &x[0] &x[4] int* int y[6][7]; y[i] y[0] y[6] int** struct(int w,x,y,z;}a; &a.x &a.w &a.z+1 int* int k; malloc(k) (returned value) (same + k bytes) int s; /* not table */ &s &s &s+1 int* Procedure in the various uses of pointers:- (Here, b and c are pointers) sort of use example procedure accessing value pointed at *b check that b is within its limits. pointer +- integer b+i check that b+i is within limits of b; copy limits of b as limits of b+i . pointer with ++ or -- b++ (ditto) pointer-pointer b-c error unless b and c have same ranges. pointer[integer] b[i] treat as *(b+i) . casting a pointer (float*)c if casting to a pointer to a pointer, or to a pointer to a struct with a pointer member, the compiler should moan that "array bound check can't help here". A pointer to an allocation which is lost by a call of 'free()', will then be invalid. Best not to call 'free()' when running in array bound check mode. - ---------------------------------------------------------------------- This should ensure that any pointer will only point to within the bounds of the table that it was intended to point to. {A.Appleyard} (email: APPLEYARD@UK.AC.UMIST), Tue, 13 Feb 90 08:38:40 GMT ------------------------------ Date: 13 Feb 90 04:20:25 +0000 From: Mark Wilkins Subject: Re: Universal virus detector / Biological analogy XPUM01@prime-a.central-services.umist.ac.uk (Dr. A. Wood) writes: > there have been a few 'biological analogy' articles >in Virus-L before. This analogy will not work - biological immune >systems are set up in a different way. [stuff deleted] >Also, any two bodies' cells (except identical twins) have different ^^^^^^^^^^^^^^ >immunotypes, and attempted grafting fails, thus any bacterium that ^^^^^^^^^^^ >learns to masquerade as a legal cell of body A, is rejected on trying >to invade body B. The computer analogy of this would be for each >individual microcomputer's copy of each authorized program to be >different. First, identical twins are not the only humans with identical immunotypes. Any individual's full brother or sister has a 1/4 chance of having an exactly identical immunotype, or rather just slightly less because of crossing-over. But that doesn't belong in this group. This, however, does: It is true that tissue typing analogies are poor for computerized anti-invasive agents. However, the body's system might provide some clues regarding possibilities for such things. Suppose one wants to implement a system which, like the human body, is adaptive. How about this: Each low level write call causes a checksum of the data written to be computed, or, better, the checksum is computed 12 hours of uptime later, to avoid some shrewdly-done virus from writing the data out in some randomized fashion. This checksum is then stored and indexed with the program or programs which made the alterations leading to them. If the same checksum starts cropping up repeatedly in calls from several different programs which have never before exhibited such behavior then that indicates that some uniform, self-replicating piece of code MIGHT have infected those programs. Of course, there are likely to be cases where changes in system configuration will cause this to happen, but all this routine would do is produce a log from which a reasonably technically competent individual could detect the infection. There might, also, be ways to improve it to actually prevent spreading under certain circumstances. - -- Mark Wilkins wilkins@jarthur.claremont.edu ------------------------------ Date: Mon, 12 Feb 90 22:25:00 -0800 From: jmolini@nasamail.nasa.gov (JAMES E. MOLINI) Subject: RE: Copy Protection on AIDS Diskette About the AIDS Trojan disk, Ian Fahrquar 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. It warns > quite clearly that: > > a) You should not install this program unless you are going to > pay for it. > > b) The program contains mechanisms that will ensure that the > terms of this license agreement will be followed. > > c) That these mechanisms will affect other programs on the hard > disk. > I am led to make the following conclusions: > 1. That all of the users who were adversely affected by this > supposed trojan either (a) did not read the license > agreement for the program which they were installing, or (b) > they read it and ignored it. Either way, they must accept > the consequences. The installation instructions first step > tells you to read the agreement on the reverse of the sheet. ... > 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. Although I am not a lawyer (Thank God) I can say that the PC Cyborg license agreement is inherently flawed. It is the old principle of "My privilege to swing my fist stops at the end of your nose." Although the program could have erased itself and called the user all sorts of nasty names, it had no right to hold his hard disk hostage. Even if I notify you that I will burn down your business if you fail to pay off the money you owe me, it still does not cause my action to become suddenly legal. That is why we have a court system and thousands of over employed lawyers today. You are supposed to settle contract disputes in court, not with a high tech version of vigilante justice. The end result of all this is that the user was not EXPLICITLY made aware of the absolutely catastrophic consequences of his/her actions. As some of us have seen in the past, hiding things in fine print and obscure wording is often sufficient reason to show that the signer did not know what he was signing. If you don't believe me, call a lawyer and ask him if he would represent you on a contingency fee basis (you don't pay unless he wins) for something like this. And speaking of wasting someone's time. Maybe we'd all bettter stop trying to be what we aren't and concentrate on being a little better at bug hunting and virus busting. I will if you will. Jim Molini ------------------------------ End of VIRUS-L Digest ********************* Downloaded From P-80 International Information Systems 304-744-2253