VIRUS-L Digest Friday, 2 Feb 1990 Volume 3 : Issue 30 Today's Topics: Re: Signature Programs Re: And another WDEF infection (Mac) Re: Universal virus detector Re: Internet Worm Statistical Distribution of Viruses Re: Universal virus detectors 4096 virus detection (PC) Jerusalem Disinfectors (PC) Trojan Alert (MAC) Help with removing virus requested (PC) The Ultimate Anti-Viral Solution? Timestamp virus protection FSP+ Checksumming 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: 31 Jan 90 20:14:06 +0000 From: well!rsa@lll-crg.llnl.gov (RSA Data Security) Subject: Re: Signature Programs The following paper is presented for review and discussion. It will be submitted to a number of conferences and MD4 will be proposed to a number of standards organizations. We encourage people to study and evaluate MD4. _________________________________________________________________ The MD4 Message Digest Algorithm -------------------------------- by Ronald L. Rivest MIT Laboratory for Computer Science, Cambridge, Mass. 02139 and RSA Data Security, Inc., Redwood City, California 94065 (C) Copyright 1989, 1990 RSA Data Security, Inc. (Version 1/29/90) Abstract: --------- This note describes the MD4 message digest algorithm. The algorithm takes as input an input message of arbitrary length and produces as output a 128-bit ``fingerprint'' or ``message digest'' of the input. It is conjectured that it is computationally infeasible to produce two messages having the same message digest, or to produce any message having a given prespecified target message digest. The MD4 algorithm is thus ideal for digital signature applications, where a large file must be ``compressed'' in a secure manner before being signed with the RSA public-key cryptosystem. The MD4 algorithm is designed to be quite fast on 32-bit machines. On a SUN Sparc station, it runs at 1,100,000 bytes/second. On a DEC MicroVax II, it runs at 70,000 bytes/second. In addition, the MD4 algorithm does not require any large substitution tables; the algorithm can be coded quite compactly. [Ed. Due to the length of this paper, I've placed it on the VIRUS-L/comp.virus document archive at cert.sei.cmu.edu, where it is available for anonymous FTP. The filename is: pub/virus-l/docs/md4.rsa.paper.] (C) Copyright 1989, 1990 RSA Data Security, Inc. All rights reserved. ------------------------------ Date: Thu, 01 Feb 90 14:01:00 -0500 From: Peter W. Day Subject: Re: And another WDEF infection (Mac) The WDEF virus has infected the public computing Labs at Emory University. ------------------------------ Date: 01 Feb 90 00:00:00 +0000 From: "David.M..Chess" Subject: Re: Universal virus detector > Any time later, I can generate a new list and compare. It is > then up to me to decide whether any differences that show up are > legitimate - but I have the absolute assurance that I WILL get an > indication of any changes. Sure, and that's certainly a good first step. But I still claim that it isn't by any means a universal virus detector, and would not solve the virus problem, because the thing that is "up to you" is just too hard. The system can tell you that only files that you expect to have changed have changed, but it *can't* tell you that they've changed only in innocent ways. That's one of the largest problems of virus protection; the system can't in general tell, and certainly can't tell down below the "which file was changed" level, which modifications to the executable-set were intended by the user, and which were not. A system like this might catch any viruses that we know of today; on the other hand, if it became widespread, viruses that it would not catch (or, more accurately, that a human using it would not catch) would shortly appear. > Another alternative is to add another bit, the "may create > executables" bit. Only code running from a block marked with this bit > may turn on the "executable" bit for another block. Normally, only > the linker and an image copier would have this bit set. A virus could > still be written - but it couldn't modify existing code directly, it > would have to produce object code and pass it through the linker. Or it could create the object that it wanted, and call the copy utility. Or is it impossible for a program to copy a non-executable thing to an executable thing? That would help a little, but would also make the system less convenient to use. How do you get a new copy of the linker? How do you write a patch program? Don't get me wrong: I think these are all good ideas for future, more virus-hardened systems. I just want to point out that, even if implemented perfectly, they don't make the problem go away... DC ------------------------------ Date: Thu, 01 Feb 90 19:07:04 +0000 From: grimesg@annapurna (George Grimes) Subject: Re: Internet Worm geof@aurora.com (Geoffrey H. Cooper) writes: lines deleted ...... > >One thing that makes me wonder: A newspaper article claims that Morris >wanted to stop the worm when it started to get out of control, and >decided that he wasn't able to. When the Internet group started to >try and control it, why didn't he offer to help? At least a copy of >the source code would have been of great assistance. Instead, he >hides and waits for the FBI to find him. > >Would not this have been his best opportunity to show his benign >intentions? Or perhaps he was advised not to help by someone. Haven't you ever screwed up badly and then panicked? Were you thinking clearly and rationally at the time? Heavy adrenalin flow is conducive to flight, not thought. George ******************************************************************************* I speak only for me...let my company form their own opinions! ******************************************************************************* +-------------------------------------------------------------------+ | DOMAIN: grimesg@sj.ate.slb.com | George Grimes | | INTERNET: grimesg@sjs.slb.com | (408)437-5305 | +-------------------------------------------------------------------+ ------------------------------ Date: Thu, 01 Feb 90 16:26:00 -0500 From: WHMurray@DOCKMASTER.ARPA Subject: Statistical Distribution of Viruses Greg Gilbert asks: >Should I purchase the subscription or should I buy each update? i.e. >What is the probability in the next year that more than four viruses >(strains, clones, etc....) will occur? Well, after all of this clinical discussion, we finally find an epidemiologist. (Greg, you will enjoy my paper in "Computers and Security," Vol. 7 No. 2, April 88.) The decision is analogous to the decision to be inoculated against a biological virus. Such an inoculation has some risk and is not free. If it is sufficiently effective and if enough others take it, there will be no one for you to catch the virus from. This is another way of saying that the virus no longer finds the population sufficiently hospitable to prosper and spread. I have never been innoculated against Polio-myelitis. I often experience reactions to innoculations. I grew up in the midst of epidemic polio, and was likely immune anyway. If all of the children, least likely people to be otherwise immune, took it, a large population from the most likely vectors would be removed. Yes, I really did go through that rational, but mostly I just do not like shots. We no longer innoculate against Small-pox. If we could clean up the Universities, Info-Centers, and retail establishments, we would go a long way toward suppressing viruses. Indeed, we may have to shut down PC labs. You can now buy a Toshiba 1000 for $549.00. This is roughly the equivalent cost of my slide rule thirty-five years ago. We did not share slide rules. The economic motive behind the shared PCs in a lab has disappeared, but the unhealthy little cess pools persist. Clean up your acts! Best, Bill ------------------------------ Date: Thu, 01 Feb 90 23:34:52 +0000 From: RWALLACE@vax1.tcd.ie Subject: Re: Universal virus detectors Leichter-Jerry@CS.YALE.EDU writes: > All this debate about whether virus detection is equivalent to the > halting problem, whether real CPU's are best modeled and FSA's or > Turing machines, and so on, is interesting but in a deep sense > completely irrelevant. > > With simple hardware support, one can design a system in which all > viruses are trivial detectable. > > Technique: The hardware will maintain, in both memory and > on disk, an "is executable code flag". For practicality, > assume this is done on a block-by-block basis say in units > of a K. > > The hardware enforces the following rules: > > 1. Any attempt to execute code from a memory block which > is not marked executable fails. > > 2. The only way to write into a block of memory that is > marked executable is from a disk block marked executable. > > 3. Any attempt to write to a disk block marked executable > fails. (To write to such a block, the executable flag must > first be cleared.) > > 4. Any disk block can be marked executable at any time. > > Memory blocks are marked executable only by reading execu- > table disk blocks into them. > > 5. Associated with every disk block is a time stamp. When > a block is marked executable, the hardware updates its time- > stamp. > > 6. The system comes with physical ROM blocks, marked exe- > cutable, which contain at least the code needed to display > the timestamps on all executable blocks.. ... > Why does this work, despite all the proofs? The proofs are not relevant to your idea because they deal with the problem of deciding whether a piece of code is a virus BEFORE it gets executed whereas your idea is a run-time system. I gather the point is that only code in executable blocks on the disk can be executed, and these blocks can never be created or altered in any way, and any attempt to modify executable memory fails. OK, so your system won't work unless flexibility is unacceptably reduced. 1. You can't do things like patch the operating system with utility programs. I have LOADS of utility programs on both Amiga and MS-DOS that modify system jump tables etc. I'd far rather have to defend my system against viruses myself than give up the use of these programs. So that alone is sufficient to kill your scheme. 2. Sometimes you WANT to modify programs, the main example being use of a file zap utility to install patches to the executable code of a program. 3. You're going to HAVE to have a method for at least creating/deleting executable disk blocks. What if the user wants to delete or copy a program file? What if you want to extract a program from an archive? What if you want to compile a program? What if you want to download a program from a bulletin board? etc. etc... If applications software can do these things then so can a virus. So your system isn't going to be very usable, or else you'll have to give up security. The timestamps are the only thing you're left with and how many people are going to go into the ROM monitor program to display the timestamps on every program on their ***-megabyte hard disk to make sure nothing's been infected? Anyway you could probably work out some way to beat this given that the virus has access to the video RAM (which it _has_ to have). I hate knocking down all these nice ideas. Someone please come up with something that'll work, I'm beginning to think there isn't any solution. "To summarize the summary of the summary: people are a problem" Russell Wallace, Trinity College, Dublin rwallace@vax1.tcd.ie ------------------------------ Date: Thu, 01 Feb 90 14:07:18 -0800 From: Alan_J_Roberts@cup.portal.com Subject: 4096 virus detection (PC) This is a forward from John McAfee: A number of people have called about SCAN's ability to detect the 4096 virus. When I said we could not detect it on disk, I was referring to a system where the virus is active in memory. If the virus is not already in the system, then SCAN will of course identify the virus on any file that you wish to scan before you run it. If the infected program is executed, however, then SCAN can only detect the virus in memory thereafter. What I'm trying to say, I guess, is that once the virus gets into memory and gains control, the only detection scheme that seems to work is a scan of memory. John McAfee 408 988 3832 (voice) 408 988 4004 (BBS) 408 970 9727 (FAX) ------------------------------ Date: Thu, 01 Feb 90 14:13:02 -0800 From: Alan_J_Roberts@cup.portal.com Subject: Jerusalem Disinfectors (PC) This is a forward from John McAfee: I have seen a few messages recently about the use of M-JRUSLM for disinfecting the Jerusalem virus. Please do not use this program, since we no longer support it. Clean-Up (CLEANP57) has replaced M-JRUSLM and all of our other independent disinfectors. If you have any of the M-Series disinfectors (M-VIENNA, M-DAV, M-1704, etc.) please assign them to the bit- bucket and replace them with Clean-Up. Clean-Up is available on Compuserve, The SIMTEL archives or on HomeBase at 408 988 4004. Thank you. John McAfee ------------------------------ Date: Thu, 01 Feb 90 15:00:32 -0700 From: Peter Johnston Subject: Trojan Alert (MAC) We have detected a new (to us) Macintosh trojan at the University of Alberta. Two different strains have been identified. Both are dangerous. The first strain is imbedded in a program called 'Mosaic', type=APPL and Creator=????. When launched, it immediately destroys the directories of all available physically unlocked hard and floppy disks, including the one it resides on. The attacked disks are renamed 'Gotcha!'. Unmounted but available SCSI hard disks are mounted and destroyed by the trojan. The files of hard disks are usually recoverable with one of the available commercial file utility programs, but often the data file names are lost. Files on floppy diskettes usually lose their Type and Creator codes as well, making recovery a non-trivial procedure. The second strain was detected in a Public Domain program called 'FontFinder', Type=APPL and Creator=BNBW. It has a trigger date of 10 Feb 90. Before that date, the application simply displays a list of the fonts and point sizes in the System file. On or after the trigger date, the trojan is invoked and disks are attacked as for the first strain. The trojan can be triggered by setting forward the Mac system clock. Because the second strain has a latency period during which it is non- destructive, it is much more likely to be widespread. Both trojans were originally downloaded from a local Macintosh BBS here in Edmonton. The second version was part of a StuffIt! archive named 'FontFinder.sit' that also contained documentation and the source code for the FontFinder application. This source code does NOT contain the source code for the trojan. A quick-and-dirty search string for VirusDetective (v/3.0.1 or later) has been developed that appears to detect the trojan engine in both strains. It is: Resource CODE & ID = 1 & Data 44656174685472616B Note that this will detect the currently known versions, but may or may not detect mutated versions of this trojan. There is some evidence that these trojans are related based on preliminary investigation of the code. It has been speculated that the second is an 'improved' version of the first (more sophisticated), or that the two versions were developed by two individual perpetrators working with the same trojan engine. There easily could be more versions either circulating or being developed. This appears to be the first deliberately destructive malicious code that targets on the Macintosh. There is some suspicion that one or both have been developed locally. There is also the possibility that one or both were uploaded from a BBS in the Seattle, Washington area. Our investigation is far from complete, but is continuing. Please warn your Mac users to make proper back-ups on a regular basis, be suspicious of all software not received from a trusted source until tested, and generally, to practice 'safe computing'. Any additional information on these two trojans or similar malicious code would be appreciated. As and when our investigation turns up more details, they will be posted... Peter Johnston, P. Eng. Senior Analyst, University Computing Systems, 352 - GenSvcBldg, The University of Alberta Edmonton, Alberta CANADA T6G 2H1 Phone: 403/492-2462 FAX: 403/492-7219 EMAIL: usergold@ualtamts.bitnet ------------------------------ Date: 01 Feb 90 10:44:09 +0000 From: "Arne Gehlhaar" Subject: Help with removing virus requested (PC) Hello ! This is my first posting (actually my second after a test) and hope you'll excuse the chaos that I might be just producing ... Anyway I have the following problem : I just got an MSDOS exe-file via bitnet from the states, and I was told that it was infected with the Jerusalem Virus. Now this happens to be the first contact I have with any kind of virus. I *HAVE* been reading most of the postings to this group, but it didn't make much sense to me then. My question is: Do I have to do anything against the virus, i.e. does it do anything that I might not want ??? If so, what can I do about it ??? Where do I get "anti-virus" programs...preferably without paying :) There seem to be quite a lot of you out there who know what's going on, so could someone please give me some hints ?? Thanks in advance Arne PS.: I don't have a signature file... as you can see :) ------------------------------ Date: Thu, 01 Feb 90 15:37:00 -0500 From: "Benjamin S. Smith" Subject: The Ultimate Anti-Viral Solution? An idea which rolled off the top of my head this afternoon: Every new program which comes out for your computer also has an "anti-virus module" with it, as a separate data file. This module contains information on what actions the program which you have just acquired takes during operation. Does the program ever change size? Does it ever create additional files? Is it authorized to make changes to other programs? What kinds of changes? How is it allowed to make such changes? Does it ever run/read other programs or data files? and so on. Included would be a list of all required read/write actions which the program uses. A central program, included with your computer from its manufacturer, is in charge of overseeing every one of these data files. It is a system-wide guard against unauthorized attempts from within any program to modify data on your computer. If a problem occurs, the central program spells it out for you and asks for further instructions. Somehow the central program would have to be referenced with every read and write, admittedly a long process. Maybe the program could be a piece of hardware, a chip, or extra memory simply set aside to be used only by the central program. Also, the more programs you have, the more that the central program must keep track of. Perhaps too much information to deal with at once. But it sounds good, right? This way the burden for virus protection falls on the computer manufacturer and the software companies themselves. No new updates of anti-virus programs are needed, since the computer can recognize any "incorrect" activity. Saves your $$, as you don't have to subscribe to an anti-virus updating service. Feasible? Or just too complicated? Could such a setup be compromised in any way short of hardware failure? Give it some thought..... Ben Smith smibs@rhodes.bitnet ------------------------------ Date: Thu, 01 Feb 90 00:00:00 +0000 From: "Prof Arthur I. Larky" Subject: Timestamp virus protection Perhaps I'm Missing Something >Date: Wed, 31 Jan 90 13:13:00 -0500 >From: Leichter-Jerry@CS.YALE.EDU >Subject: Re: Universal virus detector >While it may sometimes be difficult to decide exactly what catagory >some transitions fall into, in many cases I can be definitive. In >particular, there it is almost always the case that no existing >executable should be modified, ever. All my existing executables can >be checked by comparing their timestamps with known-correct values. >Think of this as a very cheap, absolutely unforgeable checksum. >More generally, any time I am certain my system is "clean" I can >generate and save on a secure medium a list of all timestamps on my >disk. Any time later, I can generate a new list and compare. It is >then up to me to decide whether any differences that show up are >legitimate - but I have the absolute assurance that I WILL get an >indication of any changes. I hope we're not talking about the timestamp that MSDOS puts on a file. Any time you want to change one, MSDOS will be glad to do so for you since that's what Int 21H function 57H does for a living. If you don't want to write in assembly code, it's only a few lines in Turbo Pascal. >For example, you can add a >hardware-enforced switch which when in the OFF position makes it >impossible to set the "is executable" bit at all. In this mode, you >can't do program development, install new executables, or even copy >executable files - but you absolutely can't be infected either. The >vast majority of systems could probably spend most of their time with >the switch in this position. But that's what I do for a living: "program development, install new executables, etc." Oh, well, one can always retire to something less challenging such as urban warfare. >Another alternative is to add another bit, the "may create >executables" bit. Only code running from a block marked with this bit >may turn on the "executable" bit for another block. Normally, only >the linker and an image copier would have this bit set. A virus could >still be written - but it couldn't modify existing code directly, it >would have to produce object code and pass it through the linker. I translate this to mean "find something other than a PC or a MAC on which to do your computing." True, but it doesn't solve the current problem for most of us. Art Larky Professor of Electrical & Computer Engineering Lehigh University 215 Packard Bldg 19 Bethlehem, PA 18015 For all I know, this may not even be my opinion, let alone Lehigh's. ------------------------------ Date: Fri, 02 Feb 00 19:90:53 +0000 From: greenber@utoday.UU.NET (Ross M. Greenberg) Subject: FSP+ Checksumming Y. Radai writes about the checksum *installation* being too difficult for many people to use, and that, therefore, the presumption I make that "nobody has complained" (basically) might not be representative of the actual situation out there. Well. He could be right. I must admit that, if I were writing the program all over again, the installtion procedure would have been made a lot easier. In my wildest dreams, I never expected the program to have the success it has. However, in shareware, there always must be an incentive for people to register the program - else I don't make as much money as I could. Registered users of FLU_SHOT+ get an installation program that makes the job a little easier - still not as easy as falling off a log, but a little easier. Users of my commercial program get something that is as easy as falling off a log, though, and get a choice of different checksum routines. They can even pick more than one routine, and combine the resulting checksums/sigs into one signature. If people are expecting some real sophisticated checksumming stuff, though, they won;t find it in my stuff for the reasons I've outlined before. Perhaps I'll include some real tough checksumming in the commercial product, if there is enough interest. So, far, there doesn't appear to be any real interest, except (potentially) by *some* of the readers of this mailing list. >Sorry, but I don't understand why you have to get back to the "real" >checksum. Suppose we improve the security by making the checksums >different for each user. From the fact that some user's checksum has >changed relative to *whatever* it was when that user set up his >checksum base, we'd know precisely the same thing that you know by >comparing with the "real" checksum, namely that his file had been >altered (which *may* indicate infection). So what do you gain by use >of the "real" checksum? I get people calling me up with problems on them checksumming already infected files. In most of these cases, they were not aware of the problem. By knowing the checksums of some popular programs (not just the system files), I can ask them to forward me a list of their checksummed files, ask a simple question or two and then figure out, potentially, what file is infected. Remember that I'm supporting (as of date) just over 20K users. That causes me to have to make some compromises, and more's the pity: each update has to take longer because it affects more people, more users. There are estimates that only 1% of the users of shareware ever register. If this is the case, then I have a responsibility to take things *very* slowly with any change I make. That's not to say that I won't consider making such a change, just that there is a heckuva lot more that goes into making a change that increases the security of the product by .00001% (or whatever) but that affects 100% of the users, registered or unregistered. I have a wish list of changes to make to the shareware version and to the commercial version. For obvious economic reasons, the commercial version gets all the enhancements first. For certain legal reasons, some changes can never make it into the shareware version. Just to reiterate: I never expected FLU_SHOT+ to have the popularity that it does, nor did I realize the restrictions such popularity places on the author when it comes to updating the code. Ross ------------------------------ End of VIRUS-L Digest ********************* Downloaded From P-80 International Information Systems 304-744-2253