VIRUS-L Digest Monday, 16 Apr 1990 Volume 3 : Issue 76 Today's Topics: Disinfectant 1.7 (Mac) MACs for Programs Re: Death of a Virus Friday the 13th of April Computer Virus??? (PC) Re: Virus in Text Files First computer virus extinct? WDEF A on Chessmaster 2100 and Cribgin (Mac) Re: Loophole in VIREX 2.6? (Mac) Jerusalem-B Virus (PC) 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. Please sign submissions with your real name. Send contributions to VIRUS-L@IBM1.CC.LEHIGH.EDU (that's equivalent to LEHIIBM1.BITNET for BITNET folks). Information on accessing anti-virus, documentation, and back-issue archives is distributed periodically on the list. Administrative mail (comments, suggestions, and so forth) should be sent to me at: krvw@CERT.SEI.CMU.EDU. Ken van Wyk --------------------------------------------------------------------------- Date: Fri, 13 Apr 90 15:02:44 -0500 From: Norbert Bornfeld Subject: Disinfectant 1.7 (Mac) I have major problems downloading the binhexed 1.7 version from the info-mac archives as well as from the anti-virus sites as described in this list. The file seems to be corrupted and decoding the file I get an EOF-error message. Any solutions? N. Bornfeld, University of Essen ------------------------------ Date: Fri, 13 Apr 90 11:44:00 -0400 From: WHMurray@DOCKMASTER.NCSC.MIL Subject: MACs for Programs >The first system usable for this is >the RSA public key encryption system. For a MAC, you encrypt the >checksum with the privat key of the author and append it to the >message. It can be decrypted by anyone using the public key which has >to be obtained once, and then the checksum can be checked. >Unfortunately, it is patent copyrithed (sic)in USA ..... It is true that RSA is protected by patent and copy right in the U.S. However, I am not prepared to grant that that is "unfortunate," or somehow removes it from consideration. >and requires lengthy >computations of prime numbers for the keys, .... Again, true but irrelevant. If you were going to perform a function often, its speed would be important. However, the key is only computed once, by the originator; even if it takes minutes, who cares. >and depends both on the >problem of factorisation and the discrete logarithm. And, once more, irrelevant, unless, of course your interest is only in promoting an alternative. >But there is an alternative scheme: the ElGamal-Scheme. But of course. Indeed, there are several. Let us not forget the Xerox Secure Hash Function (Snefru). Incidentally, the sponsor of this algorithm admits that it might be a little slower than RSA at checking time. Right! RSA is slow at key generation, fast at calculating the signature, which is done more often, and very fast at checking the data against the signature, which is done most often. Any number of existing and theroretical functions will enable us to determine that the probability of change is vanishingly small, at least as long as we have a trusted source for the MAC. However, RSA has the advantage of providing for attribution of both origin and, if each person in the chain adds his signature, any change. All that having been said, the important thing is to start using something. Part of the reason that we have not done so is that we insist upon seeing the value as the receiver not running something that he does not intend. On the other hand, if such a function were available, most people would not calculate it before running the code. The real value is in an author not being held accountable for something that he did not write. Given the potential for someone adding a virus to my code, I would not write code for publication where I did not compute such a value and publish it at least as widely as the code. Then, if as has happened to readers of this list, someone was damaged by code that he thought to be mine, but which had been subsequently maliciously modified, I would be able to demonstrate that the code used was not the same as what I shipped. I would be protected even if the end user, who failed to compute my function, was not protected. Authors, the use of a MAC serves you even if no one ever reconciles it. It is cheap. You have a choice of functions, security, and costs. The choice is yours. Pick one, but do something. Use several; they are cheap. William Hugh Murray, Executive Consultant, Information System Security 21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840 203 966 4769, WHMurray at DOCKMASTER.NCSC.MIL ------------------------------ Date: 12 Apr 90 00:00:00 -0500 From: "David.M..Chess" Subject: Re: Death of a Virus Dave Ihnat writes various things, including: > Systems which provide the underlying hardware CAN be made much more > secure. > Attacks on such multi-user/multi-tasking systems that > are successful invariably result from either errors in the protection > mechanisms (usually, not the hardware itself, but rather the operating > system which utilizes it) or errors in application of the provided > protections, either by programmers (privileged programs that don't > properly control access, etc.), or by administrators and users who > don't use such capabilities as ACL's and file permission settings. I agree completely with the first; systems with no concept of security are in general much harder to write reliable anti-virus software for than systems that provide a trusted kernel, or rings, or other ways to protect some software from other software. I disagree with the second, though; unless you label any setting of access levels that allows some programs to write to others as an "error", viruses can spread even in systems that have reliable access controls which are being used properly and without error. How many installations can you think of where no program *ever* legitimately writes to another? I think the reasons that we have seen microcomputer viruses, but no large-system viruses are primarily "cultural" (writing viruses hasn't become "the thing to do" in the mainframe underground, there simply aren't as many mainframe programmers, large installations don't tend to exchange software yet, and so on). DC ------------------------------ Date: 13 Apr 90 18:19:15 +0000 From: mkb@ohsuhcx.ohsu.edu (Marilyn Bushway) Subject: Friday the 13th of April Computer Virus??? (PC) Hello we are experiencing what we believe to be a virus. It just hit today. Symptoms: All executable files are destroyed and must be reloaded. It is only on P.C.'s (Dos machines) It just hit the campus today which is Friday the 13th. Is there a virus out there that we didn't know about??? Does anyone know of a utility for ridding the machine of it. mkb@ohsuhcx.ohsu.edu - -- Marilyn Bushway 3181 S.W. Sam Jackson Park Rd. Portland, OR 97201 (503) 279-8328 {ogicse,qiclab,uunet,tektronix,nosun,psueea} ohsuhcx!mkb ------------------------------ Date: Fri, 13 Apr 90 23:35:06 +0000 From: rutgers!tiger.ecn.purdue.edu!ashar@uunet.UU.NET (Ashar Nisar) Subject: Re: Virus in Text Files cdss!culliton@uunet.UU.NET (Tom Culliton) writes: >RKARRAS@PENNSAS.UPENN.EDU (Dr. Ruth Mazo Karras) writes: > >How many times has this question been answered? If you can't execute >the file or run it via an interpreter it can't carry a virus. If its That is a very general statement.... and flase too! Technically yes you may be right... but you never know if somebody can't exploit any bug in the systems software to get the control of the machine... even when APPARENLY the system is just READING a text file etc. An example is the Internet worm that used a bug in mail system Now mail system apparently only reads/sends text mail.... and there is no reason why such a bug can not exist in current PC software, especially with so many third party Network/LAN/mail/tcp etc implementations Not likely, BUT there is NO guarantee - -ashar ashar@tiger.ecn.purdue.edu ------------------------------ Date: Sat, 14 Apr 90 00:53:22 -0700 From: joe@hanauma.stanford.edu (Joe Dellinger) Subject: First computer virus extinct? In article <1095@front.se> per@front.se (Per Lindberg) writes: >He he... Single-host viruses dies out when their host dies out. >Will this be the first COMPUTER virus destined for extinction? >Why isn't the WWF doing anything!!?? Well, there is an interesting point here: Macintoshes and IBM PC's seem to be CRAWLING with many strains of viruses. One person on comp.virus reported a single file infected with three viruses simultaneously! On the other hand, it seems viruses on Apple ]['s were pretty rare. A few existed, including mine, but none of them ever seems to have reached anywhere near epidemic proportions. Most Apple ][ users I've heard back from report NEVER encountering _any_ viruses. What's the difference? An Apple ][ was an ideal machine to write a virus for. There was massive copying of software. There's been plenty of time for viruses to have become entrenched. Why didn't they? My guess is that the proliferation of non-standard DOS's (I never realized there were so many DOS variants in common use out there. Dozens of them. Wow!) and the LACK of standard methods of interfacing with the OS (such as it was) are responsible. Most viruses are _extremely_ host-specific, where "host" means both the hardware AND the OS. Can we infer the general rule that a heterogeneous software population is the best deterrent to runaway infection? (After all, people have a large number of different HLa types. Why? Smallpox is much deadlier for people with blood type "A" than "O". Why are there any people with bloodtype "A" still around?) Our computer's non-standard "fingd" did not fall prey to Morris' internet worm, even though it works fine as a "fingd". My point is that worms and viruses usually depend on a lot of things being exactly a certain way. Good network programs, on the other hand, can only assume the bare minimum protocols defined in the RFCs. There may be some escape hatch like Berkeley sendmail's "debug" option, but only ONE "genotype" of sendmail program fell prey to that attack. ------------------------------ Date: Sat, 14 Apr 90 05:11:28 -0700 From: jim@rand.org Subject: WDEF A on Chessmaster 2100 and Cribgin (Mac) VIRUS-L V3 #72 (9 Apr) contained an unconfirmed report that Chessmaster 2100 (Macintosh version) from the Software Toolworks was infected with WDEF A. The Toolworks was looking into it. I contacted them Tuesday, and they have confirmed that WDEF A was on their master disks for both Chessmaster 2100 and another game program called Cribgin, both for the Mac. They have started a recall on both products, and expect to be able to ship replacements starting this Friday. Jim Gillogly jim@rand.org ------------------------------ Date: 15 Apr 90 15:32:57 +0000 From: trebor@biar.UUCP (Robert J Woodhead) Subject: Re: Loophole in VIREX 2.6? (Mac) David_Conrad%Wayne-MTS@um.cc.umich.edu writes: > I wonder if this is a problem with VIREX or an anomaly in QuickBasic? >It could be the case that, in the future, any trojan which emulates the >structure of a QB object will be passed over by VIREX, creating a loophole >similar to the one created by checking the "Always Compile MPW INITs" box >in Vaccine. No. The problem was that, not having another example of a QuickBasic program handy, the signature used in 2.51 unfortunately matched every QB program. This was an easy fix. Thanks for the concern though. - -- Robert J Woodhead, Biar Games, Inc. !uunet!biar!trebor | trebor@biar.UUCP Announcing TEMPORAL EXPRESS. For only $999,999.95 (per page), your message will be carefully stored, then sent back in time as soon as technologically possible. TEMEX - when it absolutely, postively has to be there yesterday! ------------------------------ Date: 16 Apr 90 08:41:55 +0000 From: inesc!ajr@relay.EU.net (Julio Raposo) Subject: Jerusalem-B Virus (PC) I have made last year a program to clean the Jerusalem-B virus from the infected files without damaging them. I've done this because at the time the only other method I had was just deleting the files and restoring them from the backups. A few days after I got my hands on John McAfee's programs (Oh dear, I haven't got his name anywhere near by, please forgive me if I misspelled it) and decided I would go on working on my own program, VKILL. The version 1.0 is available from SIMTEL among other places, both C-source and compiled program with the Turbo-C init and project files. The reasons why I say that for me my program is better than SCAN and CLEAN are: Here the infections are mainly by Jerusalem-B virus (I don't know why). After using VKILL, most of the disks are reported clean by SCAN. VKILL is very fast because it looks for the only place in the file the virus usually is. It only fails if other trash has been appended to the file after it has been infected. Now I am working on the new version of VKILL. This new version is able not only of cleaning the virus but can also make all the files immune to new attacks. The next release will be 1.2, 1.1 being the Beta test version. When this new version is ready I'll send it to Keith Petersen (SIMTEL) and to Bill Davidsen (comp.binaries.ibm.pc postings). Meanwhile if someone wants more information about Jerusalem-B or the VKILL program, or has found any bug or inconvenience in the use of VKILL, please e-mail to me. - ------- Antonio Julio Raposo (ajr@cybill.inesc.pt - LISBOA - PORTUGAL) ------------------------------ End of VIRUS-L Digest ********************* Downloaded From P-80 International Information Systems 304-744-2253