Return-Path: Received: from IBM1.CC.Lehigh.EDU by abacus (SunOS 4.1/SMI-4.1-01) with sendmail 4.1/SMI-4.1-01 id AA04021; Wed, 22 Apr 92 19:10:40 +0200 Message-Id: <9204221710.AA04021@abacus> Received: from LEHIIBM1.BITNET by IBM1.CC.Lehigh.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 6481; Wed, 22 Apr 92 13:03:01 EDT Received: from LEHIIBM1.BITNET by LEHIIBM1.BITNET (Mailer R2.08) with BSMTP id 5036; Wed, 22 Apr 92 13:02:52 EDT Date: Wed, 22 Apr 1992 12:59:02 EDT Reply-To: VIRUS-L@IBM1.CC.LEHIGH.EDU Sender: Virus Discussion List From: "The Moderator Kenneth R. van Wyk" Subject: VIRUS-L Digest V5 #91 Comments: To: VIRUS-L@ibm1.cc.lehigh.edu To: Multiple recipients of list VIRUS-L Status: RO VIRUS-L Digest Wednesday, 22 Apr 1992 Volume 5 : Issue 91 Today's Topics: Re: Which Package is Best? (PC) Banyan Vines "Trojan" identified (legitimate) (PC) Re: LAN PROTECT by Intel?? (PC) Re: Polymorphic listing, Stealth in memory (PC) Error in SCAN V89B ? (PC) re:VDS... (PC) Misinfo detected, A/R/ or name a Bulgarian virus (PC) Re: Stoned, No-Int, and SCANV86B (PC) Re: Vesselin B. on NOVELL-VIRUS in #87. (PC) false alarms given by Virex (Mac) SYSMAN trojan followup (VAX/VMS) A kinder gentler Virus-L New file on risc (PC) New files on eugene and beach (PC) I-M112.ZIP available (PC) Review of Worldwide Vaccine 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. (The complete set of posting guidelines is available by FTP on cert.sei.cmu.edu or upon request.) Please sign submissions with your real name. Send contributions to VIRUS-L@IBM1.CC.LEHIGH.EDU (that's equivalent to VIRUS-L at LEHIIBM1 for you 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: Wed, 15 Apr 92 02:53:27 +0000 From: hank@netcom.com (Hank Roberts) Subject: Re: Which Package is Best? (PC) I'm looking for anyone who's used/heard of two packages: F-PROT for PCs "Untouchable" for networked PCs Email or comments here appreciated. ------------------------------ Date: Wed, 15 Apr 92 01:28:33 -0400 From: Jon Freivald Subject: Banyan Vines "Trojan" identified (legitimate) (PC) Would like to post this to hopefully save other Vines administrators much headache chasing a problem that's really not a problem. I discovered this problem while working on an end-user's system and finding about 40 copies (in almost every directory on his C: drive) of a file named "errlevel.com". Not being an assembler programmer, dissasembling this beastie was a royal pain (it is benign other than eating disk space) and determining it's source took quite a bit of time, coffee and hair pulling! On Banyan Vines networks that have a 3270 SNA service with the File Transfer Software the following will occur under the specified circumstances: If the user has the FTS send.exe in his path before the z:\send.exe The user has one of the two following conditions on his system: 1 - resident 3270 emulation is not loaded 2 - resident 3270 emulation is loaded but no TSO session is active on the host The user types "send" at the DOS prompt (or from a menu that attempts to execute via the path) The user will receive an error message from the FTS software. So far, so good - the smart user will realize the error and follow up with "z:\send" to use the desired feature. The problem is that the FTS software (specifically ibmban.com) will, upon error exit, create a 48 byte file named errlevel.com in the default directory. Apparently this file is used by some of the other spawned programs to determine the specific error which caused ibmban.com to abort. The answer to the "problem" is to not be overly concerned and to simply delete the spurious copies of errlevel.com that will accumulate and use up disk space. I hope my experience chasing this ghost will keep others from burning the midnight oil chasing what turns out to be just a stupid programming practice... Jon ============================================================================= Jon Freivald ( jaf@jaflrn.uucp ) Nothing is impossible for the man who doesn't have to do it. ============================================================================= ------------------------------ Date: Wed, 15 Apr 92 09:05:30 +0000 From: Fridrik Skulason Subject: Re: LAN PROTECT by Intel?? (PC) In Message 10 Apr 92 23:14:30 GMT, rslade@sfu.ca (Robert Slade) writes: >There is, or, rather, will be, a LANprotect product from Intel. The >product has not yet been released, as was learned when Intel's >LANspool product got a bit of a bad break with an infected release. >Intel is not developing this, but is "second sourcing" it. Well, Intel added some bits and pieces - basically (if I understood them correctly) they took one of the existing scanners and changed it into a program that would run on the server itself... - -frisk ------------------------------ Date: Wed, 15 Apr 92 09:08:58 +0000 From: Fridrik Skulason Subject: Re: Polymorphic listing, Stealth in memory (PC) In Message 10 Apr 92 03:31:01 GMT, tck@netlink.cts.com (Kevin Marcus) writes: >Therefore, if one discovers one of the encryption algorythms, it will >not be useable to identify all strains, whereas with a virus such as >V2P1/1260, V2P2, V2P6, and V2P6Z, for example, the encryption >algorythm does not change at all, though the key does. Sorry - V2P6 is a typical polymporphic virus...it is not necessary that the encryption changes, only that the implementation of the encryption changes - for example with the addition of "garbage" instructions in between the actual instructions. - -frisk ------------------------------ Date: Wed, 15 Apr 92 13:36:50 +0000 From: rolf@let.rug.nl (R.P. Mulder) Subject: Error in SCAN V89B ? (PC) Hi fellow netters, I just stumbled over a weird error in SCAN V89B. S.o. in our faculty asked me to scan her PC she had bought somewhere around the stone age. It has IBM-PC DOS 2.10 (don't laugh) on it. As I started Scan it came back with the message `Sorry, I cannot open "" to compute checksum.' And that was it, it refused to work. Then I switched back to V86B and this time IT WORKED, no problem whatsoever! BTW, my copy has not been hacked with. When I extracted it, it had all the -AV codes in it, including John's number. Now I know I c(sh)ould upgrade the f** machine but as for now I don't have the time for that, neither do I have the time to RTFM. Is this a known problem or is it something that could be fixed using a parameter? C u'round, Rolf ---------------------------------------------------------------------------- Rolf P. Mulder * Computer support devision Faculty of Arts & Letters, Groningen University, The Netherlands E-mail: rolf@let.rug.nl * FIDO: 2:282/500.21 * Phone: +31 50 635990 - Difference between a virus and Windows? A virus never fails - ---------------------------------------------------------------------------- Disclaimer: I didn't really say this! ------------------------------ Date: 15 Apr 92 13:22:46 -0400 From: "Tarkan Yetiser" Subject: re:VDS... (PC) Hi Kevin, tck@netlink.cts.com (Kevin Marcus) writes > Subject: VDS... (PC) > Tyetiser@ssw02.ab.umd.edu writes: >> We do not scan memory at all! > Well, I hope that you use some method to make sure there are no viruses > present in memory at the time of scanning, or you are going to > make a real big mess with any fast virus that happens to be memory > resident. If, for example, Dark Avenger were in memory and you started > examining files, they're all gunna be infected. Rest assured, we pull a few other tricks :-) VDS is not a scanner, it is an anti-viral centered around integrity checking. It is not prone to such viruses as Dark Avenger, 4096 etc. because of the way it operates. Yes, it comes with a separate scanner which could be fooled to spread infection if one crafted a virus after studying its operation. Specifically, VDS.EXE is the integrity checker that needs to be installed on the hard drive. VDSFSCAN.EXE is the virus scanner that is compatible with networks, even CD-ROMS etc. VITALFIX.EXE is a tool that helps the user to deal with MBR/BR infectors and so on. You are invited to try it. It is on Simtel. Regards, Tarkan Yetiser VDS Advanced Research Group P.O. Box 9393 (410) 247-7117 Baltimore, MD 21228 e-mail: tyetiser@ssw02.ab.umd.edu ------------------------------ Date: 15 Apr 92 13:13:36 -0400 From: "Tarkan Yetiser" Subject: Misinfo detected, A/R/ or name a Bulgarian virus (PC) Hello, bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) writes > Subject: Re: New Anti-viral ... (PC) > TYETISER@ssw02.ab.umd.edu (Tarkan Yetiser) writes: > Re-sigh... It'd better be a joke... :-( I donloaded the package > and took a look at it. Gosh, I had to set up a special system just to > install it! The damn thing is not compatible with Sacker, SuperStor, > Disk Manager, any disks containing non-dos partitions, produces memory > faults with DR-DOS loaded high on a 386, etc... The SPECIAL system is standard MS/PC DOS based PCs most people use. They are prepared using FDISK, and are not compressed or protected by an exotic security system. You seem to argue by the exception rather than the rule :-) > In non-installed state the program mostly refuses to run. However, > when I tried it with the -Scan only option, it did start and hung > the machine. During installation it insists that I boot from a > diskette (which is good), but when I booted from a diskette, > containing DR-DOS 6.0 and some of the fancy things that come with it, > the program thought that I have -not- booted from a dikette (which is > not good). That's good. It is supposed to be installed properly first. As far as DR-DOS is concerned, Bill Gates is not losing any sleep, neither are we:-) > When trying to recognize my CPU type it reported a 286 while in fact > it was a 386. This, combined with the warning that the driver that the Misinformation detected; Abort, Retry, or name an unheard-of Bulgarian virus :-) The program does not check CPU type to make such a distinction. > program generates may damage data if run on a different machine, > sounds pretty dangerous. How do you determine "different machine"? > What if I only change a printer controller? A disk controller? A hard > disk? Well, the warning is a little too strong. Just make sure you use the device driver generated for the same computer only on the same machine. And if you repartition the hard drive, re-installation is a safe bet. On alike machines, it may work fine, but why not install it as intended. > The documentation makes some blatant claims and tends to present the > answer "this is a bad practice" or "we do not intend to support such > systems" almost always when it mentiones a problem. Yes, the exceptions, but not the rules. It is honest about what it does not like so that the user has a chance not to use it. What do you think about the opinions in the docs? Are they totally wrong? > The "risk analisys test" presented there is just plain silly and > designed to promote the useage of anti-virus programs. To justify It tells you at the very beginning that it is a simple tool to evalutate the vulnerability of your computers...; not a complete risk indicator. Let's not take things out of context, shall we? > my claims: the "test" divides the users into 4 groups, dependening on > how risky are viruses for them. If you are in group 3 or 4, you are > strongly warned that there is a high risk of being infected. Well, but > due to the scoring system, just answering "Yes" to the question "Have > you been infected in the past two years?" makes almost certain that > you'll get into group 3 (you need 11 points for this and the answer to > the above question gives 10 points). Now, suppose that two years ago I > was infected once by the Cascade virus and since then have been highly > disappointed in PCs and decided to work only on VAXes. Is there a > - -high- risk that I'll be infected in the near future? :-) Sharp eye, Vesselin. But again, you are arguing by the exception rather than the rule. Most people do not run away from their beloved PCs because a dumb virus hit them in the past, and they do not even bother to get virus protection even after the attack. Well, yes, they run a scanner :-) > Furthermore, the description of the methods that some stealth viruses > use seem to show a good understanding of -some- stealth viruses (4096) > but a remarkable lack of fantasy about what a stealth virus (a really Wait a minute. The section about virus attack methods is intended to provide the unexposed users with preliminary information about how such beasts work. Not a comprehensive chapter on slealth viruses. Maybe, it is too preliminary for someone like you who has seen it all as far as PC viruses go. > good one) is able to achieve. If you describe me how do you detect > that a virus is present in memory, I'll show you that it is possible > to construct a virus, using only the currently known techiniques, wich > will pass undetected. Why don't you describe the methods you have in mind, and I will see if I am allowed to tell you which ones defeat VDS scheme. Honest, I will. Did you get a chance to see which pet viruses you have were able to spread on a system protected by VDS? I mean, without being detected. >> Maybe we mean something different when we talk about "verification". >> We do not scan memory at all! Stealth in files? What does that mean? > I initially misunderstood you that you are checking the memory for the > signatures of the known stealth viruses. I meant that the stealth > technology consists in concealing the presence of the virus in the > files, not in memory, and therefore such viruses are easily detected > in memory by scanning for the known signatures. They can't be encrypted > there, since as Whale proved, this slows down the computer > unacceptably and leads to the discovery of the virus. Okay, I see what you had in mind. The problem with such verification is that if the signature for a stealth beast is not known to the verifier, the results are scary. We do not rely on simple signature checking in memory like some others do. I hope you are not saying that it is sufficient to do signature scan of memory. > Yep, but now I got the package and didn't like it too much. It's less > secure than other integrity software that I know about (the Untouchable, Please, take a closer look at it if you have time, and on a regular system most people use, not DR-DOS or other fancy things. As far as UT is concerned, just don't let a stealth fast infector UT does not have a signature for get control :-) Speaking of being secure... > the ASP Integrity Toolkit). It's very prone to companion viruses, since > any new files are automatically checksummed and the > checksum database updated. It doesn't know about the DOS files Nope, that's incorrect. It handles companion viruses just fine. > fragmenting attack. It's capabilities to bypass stealth viruses make > me think that it won't be compatible with local area networks... > And many other drawbacks. This certainly means that VDS DOES NOT > represent the strongest software solution currently available. Sharp eye again, Vesselin. VDS is meant to be installed on stand-alone machines, not network servers. The identification part (VDSFSCAN) works on networks, even on CD-ROMs! Sure, VDS is not for everyone. It sure is the strongest software solution available, maybe not as convenient as some other packages with flashy user interfaces. Not as expensive either :-) > Of course, if the user succeeds to install and use the package, relying > on it is better than relying on SCAN. :-) Unzip VDS20T.zip onto a formateed, blank floppy diskette that can go in your A: drive. Boot from a clean, MS/PC DOS diskettes. Once you get to A> prompt, put in the diskette with the VDS stuf on it in drive A:, and type INSTALL and press ENTER. Follow the instructions. Simple and easy. If you have DR-DOS, Stacker, or some other non-standard stuff on your machine, please do not waste your time, VDS is not for such systems. >> If a virus is so difficult to convince, it may also be slowing down >> its own infection rate. No, it won't catch them all with decoys. > Yep. Like boot and master boot infectors, but they are not a problem > to detect and remove. Like non-resident infectors, but they are not so > dangerous. Like system attacking viruses (Lehigh), but they are also > relatively easy to catch and erradicate. Or like device driver > infectors. Or like those of them that get the information form your > CONFIG.SYS file (the Involuntary virus). Or like the ones that infect > the programs listed in AUTOEXEC.BAT only. Or like the StarShip virus. > Or.... Decoys are not for boot sector infectors. Non-resident ones, well you know how common they are :-) Device driver infectors, damn, how many of those do you have? StarShip actually infects! > Besides, the decoys seem to be launched only in the root directory, so > it's pretty easy to program the virus to avoid them. Aha, a direct attack. Yes, you are correct, that is always possible. > Speaking about root directories, why do you think that everybody's > command interpretter is the file C:\COMMAND.COM? Couldn't you > follow the COMSPEC variable? Several viruses do it better than you... :-) Yes, we are aware of that. Just much simpler to do it this way. >> Is it availale for anon FTP? Or should we contact Mr Cohen and beg >> for a copy? How much is it? > ASP IT is a commercial product. I don't know his exact price; you > should contact Dr. Cohen (he reads this list). The "Short course" is a > book, not a program or a file. You should check your book shop about > it or again ask Dr. Cohen directly. I suggest everybody to read this > book; it's very readable (unlike some of Dr. Cohen's scientific > papers ) and contains a very good cost evaluation of the > different types of anti-virus defenses. Contains a lot of other useful > stuff too; some of it can be gathered from Cohen's papers in Computers > & Security, but it's better to have them gathered in one booklet. I see. I am told (thanks Jon) that the book is $24. Just a dollar cheaper than the complete VDS package :-) It must be worth it since you seem to like it so much. Is it true that it explores the effects of viruses in environments where sharing of info is desired, but transitivity cannot be contained? Situations like system A is secure, system B is secure, but when they interact, it is a different ball game? Regards, Tarkan Yetiser VDS Advanced Research Group P.O. Box 9393 (410) 247-7117 Baltimore, MD 21228 e-mail: tyetiser@ssw02.ab.umd.edu ------------------------------ Date: 15 Apr 92 21:28:05 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Stoned, No-Int, and SCANV86B (PC) martin@cs.ualberta.ca (Tim Martin; FSO; Soil Sciences) writes: > strain. Of course it might be argued that another level of > resolution is needed: for example stoned.empire.b has variations > 1, 4, and 6, because of one or two bytes that vary. This is exactly why I initially insisted on names of unlimited depth in my scheme! Unfortunately, several people objected. They even wanted to limit the scheme to three levels, but for the file infectors this is not always possible, so we decided to stick to a four-level naming scheme.. As to your particular example, I tend to accept it (with only more consistent numbering: 1, 2, 3; not 1, 4, 6). However, in order to resolve -all- the virus names correctly, we'll have to study each of the virus variants as carefuly as you have studied the Empires. With the current ammount of about 1,300 viruses and averagely 100 new ones appearing per month, this is simply impossible. Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Bontchev@Informatik.Uni-Hamburg.De Fachbereich Informatik - AGN, rm. 107 C Tel.:+49-40-54715-224, Fax: -226 Vogt-Koelln-Strasse 30, D-2000, Hamburg 54 ------------------------------ Date: 15 Apr 92 21:36:49 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Vesselin B. on NOVELL-VIRUS in #87. (PC) masjol@dou.dk (J|rgen Olsen) writes: > At the time I was a member of the NOVELL-MAILBOARD - and there was a > message - I belive it was that issue it covered - from NOVELL > describing how they hired John David to demonstrate the spread of the > VIRUS on a NOVELL network that they sat up according to his > specifications! Yes, and he couldn't - I know the story. > He failed to do so - the VIRUS - when analyzed by an outside expert > was demonstrated to be a common variant (I belive it was of Jerusalem) > with no special features! It has never been published that the particular virus that Jon David observed to seem to bypass some of the Novell rights has been IDENTIFIED to be the original Jerusalem. (BTW, currently there exist at least two Novell-oriented viruses. The first of them is Jerusalem based and has 2 variants, and the second is Yankee Doodle based and has 4 different variants. These viruses do not bypass Novell's rights - - they can't - but they are Novell NetWare-aware and collect the passwords that the users use.) > John D. disagreed with the NOVELL conclusion that the incident he > described involved someone who was careless in SUPERVISOR mode! > Time since then - however - seems to have demonstrated that NOVELL was > right! I have a copy of the article that you mentioned above, which tells the story from Novell's point of view. It seems to me that they are right. However, the document mentiones something which I have not seen in print. I am not a NetWare expert (in fact, my knowledge in this area is minimal), but as far as understand it, it tells about a serious security flaw. Nothing particularly virus-related; just the fact that under some versions of Novell NetWare, if you log in with some rights (e.g., supervisor) and then revoke some of them; the rights in fact are still available until you log out. Have in mind that I might have misunderstood what the document actually says; I'll post the relevant part tomorrow. > Our personal experience in a wide open environment is that the NOVELL NETWARE > is a quite good protection against the spread of Virus, provided : > a) you have strict guidelines for people with SUPERVISOR rights > (may only be used from a trusted and newly scanned machine - not > a unit in the ZOO (student Lab)). > b) Users have individual passwords and directories so that they > cannot use the system as a library for infected games. Don't forget the essential: no user should have write access to executable objects that are readable/executable by other user(s). Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Bontchev@Informatik.Uni-Hamburg.De Fachbereich Informatik - AGN, rm. 107 C Tel.:+49-40-54715-224, Fax: -226 Vogt-Koelln-Strasse 30, D-2000, Hamburg 54 ------------------------------ Date: Tue, 21 Apr 92 10:24:55 -0500 From: Werner Uhrig Subject: false alarms given by Virex (Mac) it has been (convincingly) brought to my attention that the latest Virex apparently contains a pattern recognition string which will trigger ERRONEOUSLY and report a virus (mentioned were a version of DiskFirstAid, Fingerd, and Ramp) I am in contact with Microcom to get "the low down" but as I could not get an answer yesterday, I decided to post a brief warning note. Simply double-check any reports with Disinfectant or GateKeeper or VirusDetective or any other anti-viral you have handy. please note that such false positives are really rather common on other hardware platforms (PCs for example) and that this should not automatically be interpreted as reflecting badly on Virex. ---Werner ------------------------------ Date: Wed, 15 Apr 92 16:31:46 -0700 From: karyn@cheetah.llnl.gov (Karyn Pichnarczyk) Subject: SYSMAN trojan followup (VAX/VMS) I didn't see any followup to your note in virus-l digest, volume 5 issue 85, so I thought I would mention something. The CIAC group put out two bulletins on this topic in early November, 1991. The trojan was not widespread as first thought, it was found on a very small number of systems. Your information on the program is (basically) accurate, and is good enough to check VMS systems for this trojan. If you would like to see a copy of these bulletins (C-5 and C-7) feel free to email me and I will supply them to you. Karyn Pichnarczyk karynp@llnl.gov CIAC Group ------------------------------ Date: Wed, 15 Apr 92 14:00:40 -0400 From: Brian Seborg Subject: A kinder gentler Virus-L I usually tend to passively observe the goings on on Virus-L, however, I feel compelled to put forth my humble opinion on this occasion since I am getting somewhat bored with some of the recent postings especially when they discourage new ideas, or enter an endless loop of discussion which might be better off conducted off-line. That said, let me be more specific. First, I want to complement Bontchev, Stiller, Padgett, Skulson, Chess, and others for taking the time to post and to answer some of the more mundane questions over and over and over. I am impressed with the ability of some people to be able to post frequently and voluminously. :-) I would request that the postings cut down on a lot of the product specific information, not so much bug fixes as these are useful, but the endless arguing over which product is best. I suggest that no one product is the best for all people, and that in fact, many products may offer the best solution for a particular site, environment, or individual depending on things not often discussed as being important. For example, is a product which identifies 3000 virus strains and is capable of scanning faster than any other product necessarily better? I would say maybe, but then again, maybe not. Where is the comment on user interface? Ease of administration? User goof proofing? Ease of dissemination within a large organization? I have seen none of these issues covered, and yet I would suggest that they are much more important than many of the other issues. For example. A power user may find CPAV to be the best because s/he likes the interface and the fact that there are so many options to configure. A less literate user may like SCAN since it is a pure vanilla product and is relatively simple to use, no need to learn an interface. A hacker may like some of Padgett's, Yetiser's, Skulason, or UT. No matter which product there may be someone who feels it is the best for him/her. So let's get back on track. I would like to see a discussion of generic characteristics which are desirable for different user classes rather than specific product characteristics. Then one can use the set of desirable characteristics to choose among the miriad of products available. Also, I find it discomforting to see people with new ideas such as Alexander Shehovtsov, and Tarken Yetiser being immediately flamed by someone posting that there is obviously a way around the method suggested. Any technique which yields new ways to prevent viruses should be encouraged. Truth be told, we could find a way around all anti-virus programs if we really wanted to expend the effort. The point is not to build a product which can prevent 100% of all known and unknown viruses, but to build products which decrease our risk to acceptable levels. This has been said before, but I feel like I should reiterate the point. No one product will protect 100% of the systems from 100% of the viruses. But, it's still fun to try :-)! I think that if we had accepted Fred Cohen's hypothesis that it is impossible to build a virus detector that is 100% effective and so why bother, then we would be in a pretty bad fix right now. What has happened is that we have accepted this hypothesis, but said, well, how about 95% of all viruses? As T. Yetiser states in his documentation, the counter argument to Cohen's hypothesis is that while it may be true that no one can build a program to detect 100% of the viruses, it can also be said that no one can build a virus which is 100% non-detectable. The fact that we have found ways to detect even the most troublesome viruses points to this fact. So let's be kinder and gentler! I want to see new ideas, even bad ideas. If no one ever shared their failures then we would all be doomed to repeat them! Also, I would like to call for a more robust FAQ. It is a good start, but given the continuing onslaught of common questions not addressed by the FAQ it is obvious that it needs to be a living document which continues to grow and become more complete. I would be happy to enter into a discussion with others on making additions which would be mutually beneficial to all parties concerned. Thanks for the bandwidth! :-) Sincerely, Brian Seborg ------------------------------ Date: Tue, 14 Apr 92 20:50:23 -0500 From: James Ford Subject: New file on risc (PC) The following file has been placed on risc.ua.edu (130.160.4.7) in the directory /pub/ibm-antivirus: /pub/ibm-antivirus/virx22.zip - -- jf ------------------------------ Date: Wed, 15 Apr 92 09:27:52 -0500 From: John Perry Subject: New files on eugene and beach (PC) Hello Everyone! I have added the following files to eugene.gal.utexas.edu and beach.gal.utexas.edu. I have also updated all the archives on beach to reflect eugene. Please feel free to use either site. CVC192AM.ZIP CVC192MA.ZIP CVC192MS.ZIP CVC192AT.ZIP CVCINDEX.ZIP TBRESC18.ZIP TBSCAN33.ZIP TBSCNX30.ZIP FIXUTIL3.ZIP (Thanks Padgett!) VDS20T.ZIP VIRX22.ZIP VSIG9203.ZIP If you have any problems or questions, please contact me at perry@eugene.gal.utexas.edu. - -- John Perry - perry@eugene.gal.utexas.edu ------------------------------ Date: Thu, 16 Apr 92 06:26:00 -0400 From: HAYES@urvax.urich.edu Subject: I-M112.ZIP available (PC) Hi friends. Thanks to Webb Blackman Jr, sysop of the Blue Ridge Express BBS and member of the ASP, a copy of Integrity Master version 112 is now available for FTP processing from our site. Filename: I-M112.ZIP Site: urvax.urich.edu, [141.166.1.6] (VAX/VMS using Multinet) Directory: [anonymous.msdos.antivirus] FTP to urvax.urich.edu with username anonymous and your email address as password. You are in the [anonymous] directory when you connect. cd msdos.antivirus, and remember to use binary mode for the zip files. Thanks Webb! Best, Claude - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Claude Bersano-Hayes HAYES @ URVAX (Vanilla BITNET) University of Richmond hayes@urvax.urich.edu (Bitnet or Internet) Richmond, VA 23173 ------------------------------ Date: Mon, 13 Apr 92 15:56:24 -0700 From: rslade@sfu.ca (Robert Slade) Subject: Review of Worldwide Vaccine Comparison Review Company and product: Worldwide Software Inc. 20 Exchange Place, 27th Floor New York, NY 10005 USA 212-422-4100 Telecopier 212-422-1953 Vaccine version 3.31 Summary: Primarily operation monitoring and restriction with scanning and change detection facilities. Cost Rating (1-4, 1 = poor, 4 = very good) "Friendliness" Installation 1 Ease of use 2 Help systems 1 Compatibility 2 Company Stability 2 Support 2 Documentation 2 Hardware required 2 Performance 2 Availability 2 Local Support 1 General Description: VACCINE operation monitor, PHYSICAL scanner, CHECKUP change detection, SHELTER operation restriction and XRAY CMOS backup. Comparison of features and specifications User Friendliness Installation The program is shipped on writable, but protected, 5 1/4" 360K media. Although a scanner is included in the package, scanning of the system to be protected is suggested only after installation is completed. Manual and automated installations are provided. The manual installation is incomplete in that the necessary final step to have *any* protection at all lies in another part of the manual. The automated installation is performed through a simple batch file which creates a directory and copies the file into it. An environment variable is set and used, so the installation may fail on occasion. A command is prepended to the beginning of the AUTOEXEC.BAT file. Although the documentation specifically states that the INSTALL program will work with a dual floppy system, in fact it will not. The VACCINE program, and operation monitoring, is stated to be the "soul" of this package. Any program which performs any kind of "suspect" functions must be authorized. Once authorized, the program can perform any of the restricted operations without interference. Ease of use The VACCINE program requires a list of programs which are authorized to perform restricted functions. Since "restricted functions" includes such things as any form of deletion, a number of programs will need to be added to the list. The list is a simple ASCII file of program names, one per line. (The "ease of use" of this can be determined by the fact that the documentation suggests EDLIN be used to create or amend it.) The creation of the authorized programs file would not be a simple matter. Likely programs would have to be run "against" VACCINE to see if they trigger the alarms. I was surprised to find that the PHYSICAL scanner triggered VACCINE, since it should only be performing "read" operations. In this light, the file could only be built in an environment guaranteed free from viri ... which somehow seems to defeat the purpose. Help systems Although the manual talks about "online help", this is, in fact, restricted to a list of command line switch options if you use the "-h" switch or improper switch syntax. Since "no switches" is not improper, one must read the manual in order to know that there are switches. Compatibility As of this version, none of the Vaccine programs will function if a network is present. A network version is available separately. Company Stability Unknown. Company Support The package makes no statements regarding support. Documentation The documentation is sufficient to install and run the programs. Its statements and examples are clear. However, it must be said that the claims made for the program, and the discussions of viri in general, border on misrepresentation. There is *no* discussion of boot sector infectors, although the signature list contains strings for several, and the only suggested method for dealing with infections is to "*erase [the infected program] immediately* using the DOS ERASE command". A clever use of the documentation is that the command to "teach" VACCINE to accept new "restricted" programs is buried in the documentation, and is not a part of the online help. Hardware Requirements None stated. Performance PHYSICAL identified about two thirds of the common infectors presented to it. A number of the viri were misidentified, but were, at least, flagged as infected. The choice of signature strings shows, therefore, promise for identifying new variants. Where multiple infections are found, the program will scroll off the screen. The Vaccine package as a whole has serious shortcomings with regard to boot sector infectors. The PHYSICAL program will not, apparently, identify boot sector infectors in diskettes in drive B. VACCINE will not catch a BSI in memory on startup (Stoned was used in testing), and will falsely identify the program that is trying to make a change to the boot sector. (In the test case, this was its own PHYSICAL.) Since most activities that trigger Stoned to infect will also trigger VACCINE, this is of no help at all. (Short of rebooting the computer, VACCINE offers no "protection": it is only an alarm. I would see this kind of interference as being almost worse than Antivirus Plus.) The one bright spot is that the boot sectors of diskettes in drive A, if present, are always scanned for viri. If found, however, the suggested remedial action is "Reinstall DOS": effective against a BSI on a floppy, but perhaps misleading when the diskette is non-bootable and the "system" is on the hard drive. It should be noted that all "restricted" operations are considered together. Therefore, once a program has been "authorized", it is allowed to perform any operations. If an "authorized" program becomes infected, it will be allowed to infect all others. (An authorized program can also "permit" a virus, already resident, to operate.) Local Support None provided. Support Requirements It is unlikely that novice users could obtain significant protection from this package. Intermediate users could likely install it and make suitable decisions regarding "authorized" programs, but in all likelihood advanced support would be required for installation and creation of the authorized programs file. General Notes Although the "multi-layered" approach to protection is good, with this package's reliance on operation monitoring it is difficult to find an environment to recommend it for. Low change, low utility use, no diskette use situations may find it suitable. copyright Robert M. Slade, 1992 PCVCNWWS.RVW 920401 ============= Vancouver | "The client interface Institute for Robert_Slade@sfu.ca | is the boundary of Research into rslade@cue.bc.ca | trustworthiness." User CyberStore Dpac 85301030 | - Tony Buckland, UBC Security Canada V7K 2G6 | ------------------------------ End of VIRUS-L Digest [Volume 5 Issue 91] *****************************************