To: VIRUS-L@LEHIGH.EDU Subject: VIRUS-L Digest V5 #202 -------- VIRUS-L Digest Tuesday, 15 Dec 1992 Volume 5 : Issue 202 Today's Topics: Re: DOS CHKDSK bug (PC) Anyone have experience with XTree's VIRUSAFE 4.5? (PC) Re: Is this a DOS virus? (PC) Re: Preventive Methods (PC) Re: Vshield vs Virstop (PC) Re: VSHIELD, VIRSTOP, ... comparison ? (PC) Re: F-PROT & CLEAN won't remove this one !!! (PC) Re: Fake Dir-II (PC) Re: Filler virus (PC) Re: Filler virus (PC) Re: Integrity Management (PC) Re: Is this a new virus? (PC) Re: VSHIELD, VIRSTOP, ... comparison ? (PC) capture.com false positive? (PC) Re: Is this a real virus? (PC) Re: Need Info about INVOLVE virus (PC) Re: Odd Virus? HELP (PC) Re: Not a Stupid OS/2 Question (OS/2) re: A user's view of IBM's antivirus/2 (OS/2) Re: Integrity Management 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@LEHIGH.EDU. Information on accessing anti-virus, documentation, and back-issue archives is distributed periodically on the list. A FAQ (Frequently Asked Questions) document and all of the back-issues are available by anonymous FTP on cert.org (192.88.209.5). Administrative mail (comments, suggestions, and so forth) should be sent to me at: . Ken van Wyk ---------------------------------------------------------------------- Date: Thu, 10 Dec 92 18:32:10 -0500 From: Richard Hosker Subject: Re: DOS CHKDSK bug (PC) Mike Ramey writes: > How can you tell if you have MS-DOS version 5.00a or not ? > > I called Microsoft and requested the updated version for my computer > labs, even tho' we have not encountered the failure conditions yet. I > was told that in MS-DOS version 5.0a, the date on COMMAND.COM is > 11-11-91. I have not yet received the updated version, so I cannot > confirm that. (My current DOS-5 COMMAND.COM date is 4-09-91.) If I > learn anything different, I will post it. I don't have a definitve answer to the question Mike posed, but I can report one way you *can't* tell which version you have... :-/ The VER/R command returns the following for **both** versions: DOS 5.00 Revision A DOS in memory (The wording may not be exact here, but the Revision A part is correct.) I have tested this on both versions, dates 04-09-91 and 11-11-91. Since the "Revision A" message appears regardless of version, this is *NOT* a reliable way to determine which version you have. To be safe, check the date. BTW, by my reckoning, the 65280-cluster limit represents a partition of about 130 MB. No small bug, this... :-( Hope this heads off any confusion or false security... ============================================================================== Richard Hosker : ttttttttt Tennessee Technological University rph0470@tntech.edu : t u t u Cookeville, TN PO Box 6083 TTU : t u t u Cookeville, TN 38505 : t uuuuu "Home of the Golden Eagles" ============================================================================== Disclaimer: After this many years of college, these opinions are among the few things Tech *hasn't* taken from me yet. ;-) ------------------------------ Date: Thu, 10 Dec 92 18:44:37 -0500 From: Dave Mickle x5205 Subject: Anyone have experience with XTree's VIRUSAFE 4.5? (PC) I'm looking at purchasing a site license for a virus scanner in the immediate future. I am familiar with VIRUSCAN and F-PROT. Can anyone report on their experience with XTree's VIRUSAFE V4.5? [Moderator's note: I'd suggest that you start by taking a look at Chris McDonald's review, which is available by anonymous FTP from cert.org:/pub/virus-l/docs/reviews/pc/mcdonald.virusafe] - ----------------------------------------------------------------------------- - ----David K. Mickle "As soon as I pressed the red button, I - ----if !(BITNET) MICKLE@CSMCMVAX realized I had made a terrible mistake." - ----then (VOICE) 310 855-5205 -Dr. who pressed the UNMARKED power - ----else (FAX) 310 967-0112 kill switch for the computer room. - ----while (Cedars-Sinai Medical Center, Los Angeles, CA USA) - ----------------------------------------------------------------------------- ------------------------------ Date: 11 Dec 92 08:05:10 +0000 From: frisk@complex.is (Fridrik Skulason) Subject: Re: Is this a DOS virus? (PC) echrstmn@lab4.smcm.edu (Evan Christman) writes: > On one of our PC's we are observing some odd behaviour of our >DOS files. The symptoms are: certain DOS files, share, dosshell and a >few others report that their size has been altered when I run a >CHKDSK. Infection by a stealth virus is a possibility, but simply regular FAT corruption is a much more likely explanation. Do the following: reboot from a clean diskette rerun CHKDSK if it reports that the file sizes are wrong, you just have regular FAT corruption. In that case you can try to run CHKDSK /F and then replace the damaged files, just to be 100% safe :-) - -frisk ------------------------------ Date: 11 Dec 92 08:16:13 +0000 From: frisk@complex.is (Fridrik Skulason) Subject: Re: Preventive Methods (PC) fwilliam@dev1.smcm.edu (Frank Williams) writes: >I am looking for software that will prevent an infected floppy diskette >from transfering a virus to a hard disk. Sorry - this is not really possible. You cannot use software to *prevent* the hard disk from becoming infected, if you boot from an infected floppy disk, This can be achived via hardware methods, but software can only detect boot sector infections after the fact - not prevent it. - -frisk ------------------------------ Date: 11 Dec 92 09:09:59 +0000 From: frisk@complex.is (Fridrik Skulason) Subject: Re: Vshield vs Virstop (PC) >BTW, one tip. The detection rate of Virstop is exactly the same as of >F-Prot in Quickscan mode - they are using the same mechanism. Maybe >I'll do tests on our virus collection with F-Prot /quick one of these >days... Well, VIRSTOP (or Quick scan) will not detect as many viruses as F-PROT Secure scan. It will miss all MtE viruses for example, and most of the viruses which cannot be found using a signature-based approach. While Secure scan will detect around 99% of all viruses, Quick scan may detect only around 90% (however, it will detect a much higher percentage of "in-the-wild" viruses). >> Virstop seems awfully small to have all >> those signatures inside itself, Well, 12K isn't exactly small....and of that only 2K is code, the rest is the signatures. Of course, by using the /DISK command-line switch you can get VIRSTOP's memory usage down to 2K, as the cost of a small delay when running any program. - -frisk ------------------------------ Date: 11 Dec 92 09:27:55 +0000 From: frisk@complex.is (Fridrik Skulason) Subject: Re: VSHIELD, VIRSTOP, ... comparison ? (PC) mramey@u.washington.edu (Mike Ramey) writes: >One of my questions is this: VSHIELD intercepts a keyboard reboot and >checks for the presence of an infected diskette in the boot diskette >drive; it does not allow booting from a (boot-sector?) infected >diskette. Does VIRSTOP have this function? No, not yet. However, I am working on adding several features to VIRSTOP, which are lacking from it. They are: option to scan files during copy (done, being tested now) option to scan boot sectors when disks are accessed (almost finished) - -frisk ------------------------------ Date: 11 Dec 92 09:32:48 +0000 From: frisk@complex.is (Fridrik Skulason) Subject: Re: F-PROT & CLEAN won't remove this one !!! (PC) overberger@gw.wmich.edu writes: >We may have found a new variety of STONED on our campus. It seems to >infect the partition table of infected DOS machines, disabling both >the COM: ports as well as doing some unusual things to the root >directory. F-Prot 2.06a identified it as a STONED virus but refused to >remove it. Ditto with the latest version of CLEAN. After mailing Frisk >and receiving a response indicating he believed it was not a virus >(basically a blow off) Well, unless I'm wrong, the description I got seemed to indicate an old problem - the message "Possibly a new variant of stoned" happens quite often on disks that have once been infected with stoned, and improperly disinfected by a program that just overwites a part of the boot sector with valid code, leaving a part of the virus, so my program only gets a partial match. That happens much more frequently than new virus variants, so I just thought it was the case here too - I apologize if I was wrong, but you see, without a copy of the boot sector it is practically impossible to tell exactly what is going on. - -frisk ------------------------------ Date: 11 Dec 92 17:20:26 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Fake Dir-II (PC) Stefano_Turci@f108.n391.z9.virnet.bad.se (Stefano Turci) writes: > F-prot says that it is possibly a new variant of Dir-II, and it doesn't say > that the file is infected by Dir-II, however I am a little worry about it > because.....I am the author of that program. :-) > I wrote that program using assembler, and I found the piece of source code > that produces the above warning: > - ------------------------------------------------ > mov bx,offset message > mov cx,46d > decrypt: > xor byte ptr [bx],0ffh > inc bx > loop decrypt > - ------------------------------------------------ > I can only suppose that the virus uses a very similar decrypting routine, > however I think there is something wrong in the way used by F-prot to search > for new variants of Dir-II. [stuff deleted] Hmmm.... The worst of all is that the real working virus (Dir_II) *doesn't* contain such piece of code... Except... Well, there is one "variant" of this virus, which tries to be polymorphic and uses something similar to the above to variably encrypt/decrypt itself... However, as pointed out by the Russian anti-virus researcher Dmitry Gryaznov, this variant of Dir_II will never work, due to some serious bugs in it... Maybe F-Prot should just not try to detect it? Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN < PGP 2.0 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C e-mail: bontchev@fbihh.informatik.uni-hamburg.de D-2000 Hamburg 54, Germany ------------------------------ Date: 11 Dec 92 17:31:47 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Filler virus (PC) tck@fold.ucsd.edu (Kevin Marcus) writes: > >BTW, you will not (or should not :-) ) see this conflict with NAV. > >NAV does a more sophisticated search through memory with knowledge of > >where viruses store themselves. > > > Hmm. That doesn't sound like the most brilliant thing. It doesn't take > too long to search through memory, and it's easy for a varient to move > to a different place in memory. Or pick a random spot. Not really. It's rather hard to simply patch a virus, so that you completely modify its memory installation strategy and still produce a closely related variant. It's almost certain that you'll get a completely different virus, which would be detected by a different scan string. I suppose that NAV is doing something similar to TbScan/HTScan - each virus is described with the area of memory it can occupy. Such areas could be: INT (in the interrupt table), DOS (in a memory hole in DOS), LOW (as a normal TSR, like Jerusalem), TWIXT (shortening the last MCB and copying itself above it), VIDEO (in the video buffer), UPPER (in the memory between the video buffer and the 1 Mb boundary), AT (at a particular segment), etc. There are a few other possibilities, which I cannot recall off the top of my head. This restricted memory search usually works in most cases. That is, it is silly to look for Stoned in the DOS buffers, when you know that it installs itself after the top of memory pointed by the BIOS variable at 0:413h... The method has problems only in a few cases - for instance, the Number of the Beast and a couple of other viruses install themselves in the DOS buffers. When you copy an infected file, there is fair chance that the virus code (although inactive) will be found in one of these buffers - which is exactly where you should look for this virus in the first place. The solution is to check whether the signature is found in an -existing- DOS buffer (when the real virus installs itself in a buffer, it removes that buffer from the chain of the available ones), but I know about no program that bothers to do that... Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN < PGP 2.0 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C e-mail: bontchev@fbihh.informatik.uni-hamburg.de D-2000 Hamburg 54, Germany ------------------------------ Date: 11 Dec 92 17:44:46 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Filler virus (PC) mcafee@netcom.com (McAfee Associates) writes: > Considering that the other anti-viral program appeared several years > after VIRUSCAN was released, I think it is fair to say that SCAN does > not contain a "shoddy scan string," I disagree. It absolutely doesn't matter when the anti-virus program has been released. What does matter is (1) when the program has been updated to detect this virus, (2) when did the virus appear, and (3) are there any other possible scan strings for that virus. If a virus like Cascade appears tomorrow, and if it uses variable encryption, so that the only possible scan string is the (short) decryptor in the beginning, guess what will both McAfee Associates and any other anti-virus company pick as a scan string... > rather, (1) the other program was > not adequately tested against existing anti-viral programs for > compatibility problems before release; (2) the other program does not > cipher its virus search strings, opening the possibility of false alarms > with other anti-viral programs which use the same search strings, and Now, -that- is definitively fair to say. Any scanner-like anti-virus program that doesn't do the above (and that doesn't clean up the memory after itself upon termination) is plain silly. > (3) this problem is not adequately documented in the other programs' > documentation. Well, in this particular case, it is documented... :-) They just tell you in the docs that their program is incompatible with any other anti-virus software... :-)) > In one of my chats with the other programs' technical support staff, I > was told that the problem should be fixed in the new version of their > software. Hopefully, this problem will disappear as users upgrade to > the current version of the program. [rumors mode ON] Allegedly, a version of the product mentioned will be included in MS-DOS 6.0. Allegedly, this particular problem has been already fixed in that particular version. [rumors mode OFF] > When a new anti-viral program is brought to market, who should be > responsible for compatibility-testing it to ensure that no false > alarms exist with existing programs? And to what extent should > testing be done? And who should be responsible for fixing any > incompatibilities? Comments, anyone? That's a really good idea... As Dr. Solomon says, it's very easy to create the perfect virus detector. It will achieve 100% detection rate when tested with -any- virus collection. It can be just a short .BAT file. Here it is: echo %1 is a virus. (or something similar, to include the boot sectors testing, but you get the idea). Unfortunately, such program has no practical use, since it gives an infinite number of false positives. The tough problem is to create a scanner that still has a good enough detection rate, but has no false positives... Unfortunately, there is no simple way to test a scanner for false positives... False negatives are easy - you just get a huge virus collection and count how many viruses the scanner -doesn't- detect... I really don't know how a reliable false positive test should be performed... One idea is to get all the MS-DOS software from Simtel20 (it is available on CD-ROM), unpack it and run the scanners on all the executable files. Another idea is to run each scanner on a wide range of other anti-virus programs, maybe even including itself. At the VTC-Hamburg we are working on a test protocol about how anti-virus tests should be performed, so any ideas are welcome. Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN < PGP 2.0 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C e-mail: bontchev@fbihh.informatik.uni-hamburg.de D-2000 Hamburg 54, Germany ------------------------------ Date: 11 Dec 92 18:30:58 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Integrity Management (PC) padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) writes: > Seems like we should be about due for some "next generation" products, > products that can detect a one-byte change in any program but are smart > emough to know that a one byte change is not likely to be a virus. Hmm... Wasn't that you who explained me once how a one-byte change in a particular data area might mean a virus infection?... :-) > 1) Multilevel validation - secondary programs that validate whether or not > the protection program is working properly. We already have something like that - most self-respecting integrity checkers perform a self-check when executed. > 2) TSR awareness - what programs are expected to change memory allocations > and which are not. I think that Jim Bates' anti-virus package has a program that does something similar, but I have never seen it, so I am unable to provide more information. > 4) DOS locations, sizes, and expected values specific to the particular PC. At least some packages do that already. (I.e., location, and size checks. The "expected values" are a bit difficult, due to the lots of different versions of DOS that are around - e.g., the German version of COMMAND.COM has a different length than the English version of the same file, even for one and the same version of DOS.) > 5) Ability to temporarily disengage certain functions for maintenance without > having to remove the entire package. Again, most full-blown anti-virus packages allow you to use only some of their functions. > 6) Partitioning support. What is this? > 7) Ability to detect an attempt to write to an executable You mean, a monitoring program? Well, they are so easy to be bypassed... OK, maybe they should be there as a protection at least against the stupid viruses, but then such programs tend to be rather obtrusive... > >As far as I know, Prof. Eugene Spafford and a few others from Purdue > >University are working on a platform-independent user-programmable > >scanner. It will be released in source, free of charge. Initially it > >will have routines to access Unix file systems, but since it will be > >written in C++, nothing will prevent other people from writing the > >appropriate interface to DOS, MacOS, AmigaDOS, or whatever. As you see > >- - no deep secrets. > The problem is that a platform independent management program is going to have > a hard time detecting platform-dependent low-level attacks. Consider > for a moment malicious software that tries to go resident in the disk buffers. > To work it must recognize the differences between buffers used by DOS 3.x > and those of higher versions. So must an integrity management routine. Three objections. First, I was speaking (in this particular case) about a platform-independent -scanner-, not about an integrity checker. Second, it is supposed to run without a virus being active in memory, so there is no reason to check the buffers and other such stuff. Third, as I said, it will be platform-independent. In order to port it to another platform, you'll have to write the platform-specific I/O routines. If you want to scan the memory, you'll just have to write routines that provide access to it as a file. Not difficult at all. > Gene & Co. at Purdue are doing important work but it must be realized that > you cannot get all of the way with a platform-independant solution. A > long way certainly & would work on a PC with Jerusalem & Sunday, but how > about a low-level infection such as MICHELANGELO or FORM ? These depend on > the platform. First, Michelangelo is not that much platform-dependent... I mean, it can perfectly infect a Unix-only system, if it runs on an IBM PC compatible... (The fact that it will also crash the system and prevent it from booting is a completely different story.) Second, in order to use that scanner on such a platform, you'll just have to write the I/O routines that provide access to the boot sectors - as simple as that. > Of course the real answer might be for a generic "kernel" with attachable > platform-specific modules that are assembled on installation. Not difficult, > just different. Why different? As far as I understand, this is exactly what they are doing (maybe Prof. Spafford can comment on this?). Just instead of the ugly assembly language solution, they are using an object-oriented approach and are implementing it in C++. :-) > I agree but take it one step further, again the algorithm should be > tailored to the specific machine and use a different seed on each - this > in no way weakens the algorithm but gives each PC a different signature > for a particular file. Break one machine and "malware" must start all over > again on the next. In fact, it depends on the algorithm used. If you are using a CRC, just using a different seed for the checksum does not make it secure - you must change the polynomial each time. If you are using something cryptographically strong as DES, MD4, MD5, MD2, or some such, then just changing the seed is enough. Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN < PGP 2.0 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C e-mail: bontchev@fbihh.informatik.uni-hamburg.de D-2000 Hamburg 54, Germany ------------------------------ Date: 11 Dec 92 19:05:03 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Is this a new virus? (PC) tck@fold.ucsd.edu (Kevin Marcus) writes: > trinh@camins.camosun.bc.ca writes: > >[description of a typical Stoned+Michelangelo problem deleted] > It looks like you had a multiple infection. Stoned and it's varients > (Michelangelo is one...) don't always copy the MBR to the same spot. No, the problem is cause by exactly the opposite - both Stoned and Michelangelo copy the MBR to exactly one and the same spot (on the hard disk), which results in the original MBR being lost. > Michelangelo finds it's way onto your system; your MBR at 0,0,0 is > moved to 0,0,7. Shortly after, some copy of Stoned decides to find > its way there, too, moving 0,0,0 (which is Michelangelo) to 0,0,15. > > Now, upon a normal boot, the sectors are executed like: > 0,0,0 (Stoned) > 0,0,15 (Michelangelo) > 0,0,7 (Real MBR) > > Removal of this can be funny because some varients of Stoned store > the real MBR at 0,0,7, as well as Michelangelo. What probbaly Removal of the above is very easy: you read 0,0,0, see Stoned in it, get 0,0,7 and put it at 0,0,0. Since (according to your description), it contains the real MBR, the problem is solved. > tried to remove the real mbr. (Though I don't know why this is so, > since Mich uses sector 7, if my memory serves me right). Correct, so in reality this is what happens: 1) Clean disk: 0,0,0 (Real MBR) 0,0,7 (unused) 2) After a Michelangelo infection: 0,0,0 (Michelangelo) 0,0,7 (Real MBR) 3) Now comes a Stoned infection: 0,0,0 (Stoned) 0,0,7 (Michelangelo, put there by Stoned, overwriting the real MBR) 4) A scanner sees Stoned in the MBR and tries to remove it, by restoring what it believes is the real MBR from 0,0,7 (where Stoned puts it): 0,0,0 (Michelangelo - fetched from 0,0,7 by the remover) 0,0,7 (Michelangelo - still there, unless wiped out) 5) The scanners no sees the Michelangelo and tries to remove it by restoring what it believes is the real MBR from 0,0,7 (where Michelangelo puts it): 0,0,0 (Michelangelo - fetched from 0,0,7 by the remover) 0,0,7 (Michelangelo - still there) And so on ad infinitum... If the remover is smart enough, it will wipe out the sector at 0,0,7 at step 4. Also, at step 5 it will figure out that the sector at 0,0,7 now is wiped out and contains no valid MBR (this is what F-Prot does). Now, if the remover is -really- smart, it will install a valid MBR program that it carries with it, just for such cases... Of course, there are some pitfalls with preserving the partition table data, but they can be dealt with... Does anybody know a scanner that is that smart? Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN < PGP 2.0 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C e-mail: bontchev@fbihh.informatik.uni-hamburg.de D-2000 Hamburg 54, Germany ------------------------------ Date: Fri, 11 Dec 92 19:25:02 +0000 From: mcafee@netcom.com (McAfee Associates) Subject: Re: VSHIELD, VIRSTOP, ... comparison ? (PC) Hi Mike, mramey@u.washington.edu (Mike Ramey) writes: >I have found Robert Slade's quick comparison (and his longer reviews) >of several anti-viral programs very helpful; they prompted me to try >F-PROT and VIRx, in addition to the McAfee suite of programs which I >have been using for several years. > >Is it possible that the three of you (McAfee, Frisk, and Slade) could >cooperate to produce a point-by-point comparison of VSHIELD and >VIRSTOP? [...deleted...] Given the already-existing number of anti-viral product-related messages on comp.virus (and VIRUS-L) lately, perhaps it would be best to do this offline in email. If Rob is willing to do the comparison, I'd be happy to review a draft copy. Regards, Aryeh Goretsky Technical Support - -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - McAfee Associates, Inc. | Voice (408) 988-3832 | INTERNET: 3350 Scott Blvd, Bldg 14 | FAX (408) 970-9727 | mcafee@netcom.COM Santa Clara, California | BBS (408) 988-4004 | CompuServe ID: 76702,1714 95054-3107 USA | USR HST Courier DS | or GO MCAFEE Support for SENTRY/SCAN/NETSCAN/VSHIELD/CLEAN/WSCAN/NETSHIELD/TARGET/CONFIG MGR ------------------------------ Date: Fri, 11 Dec 92 19:27:03 +0000 From: tgee@alfred.ccs.carleton.ca (Travis Gee) Subject: capture.com false positive? (PC) In the analyse.doc that comes with f-prot v. 2.06a, it says that >Currently the following programs are known to cause a false positive: > >DIR1.COM >GBXIBMEL.EXE >GRAPHICS.COM >PC-CACHE.COM >WORD.COM (Microsoft Word) >XTPRO.COM I got one for graphics.com , alright, but also for qdcolor.com (a qdos file), and capture.com (a Word5 file). The qdcolor.com warning says that it contains code to search for other executable files: no kidding! It's an installation device for the qdos user interface. capture.com, however, 'modifies itself in a highly suspicious way...' This wasn't my machine and I don't know Word5, so I don't have any hunches about it. Two more Type I's for the record, though! ------------------------------ Date: 11 Dec 92 19:26:10 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Is this a real virus? (PC) GLWARNER@samford.bitnet (THE GAR) writes: > We had a lab machine die in one of our computer labs yesterday. > SCAN8.7BV95 said it had a "Generic Boot Virus" (real useful stuff, that). Sigh... Hints to all producers of scanners: Yes, indeed the most important question that interests the users is "Am I infected or not?". However, the NEXT important question is "If I am infected, which virus is it, i.e. what can it do/has done to me?". (The THIRD question is usually "How do I get rid of it?".) Reports like "Generic Boot Virus" or "FamilyQ Virus" are not very informative... Users -do- want exact identification (or at least "almost exact identification", if we use Frisk's terminology)... > hits has been mostly due to bad code. Stoned has garbled many floppies, > and we have seen Marijuana messages and bouncing balls, but this is the > first destructive hard drive hit we've seen. No kidding, you have seen the Marijuana message? On the screen?? Displayed by the virus??? Then you should have a new variant - none of the ones we have here displays that message. The original virus displays only the first part - "Your PC is Now Stoned". > The virus began in Sector 0, and wrote variations of ASCII 0-255 all the > way through the boot sector and the FAT table. (Or so it seemed to me Ah, this explains the "Generic Boot Virus" report... It seems to me that SCAN is using some kind of heuristics (Aryeh?) and reports a "generic" boot (or partition) virus each time when something seems wrong with the boot sector(s) - like missing names of the hidden DOS files, missing signature (0AA55h), etc. In your case the whole contents of the boot sector has been destroyed, so its contents has become obviously "abnormal". This has triggered SCAN's heuristics (just a wild guess; I'm not certain that it is indeed so). In your particular case, the crash might not be caused by a virus. It might be a normal crash, or be caused by a buggy program... It's the destruction of the contents of the boot sector that has caused the report about the "Generic Boot Virus", not the "generic boot virus" has caused the destruction... Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN < PGP 2.0 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C e-mail: bontchev@fbihh.informatik.uni-hamburg.de D-2000 Hamburg 54, Germany ------------------------------ Date: 11 Dec 92 19:38:23 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Need Info about INVOLVE virus (PC) mcafee@netcom.com (McAfee Associates) writes: > >> hello, I am new here. I hope someone could give me some information > >> about the INVOLVE virus. I know that it changes the date on the files > [...deleted..] > >Hmmm... Which version of SCAN? SCAN 99 never reports such name when > >run on our virus collection. Also, no such name is listed in > >VIRLIST.TXT. On the top of that, I have never heard about a virus with > >this name... Maybe Aryeh can comment? > The Invol (Involuntary) virus is a memory-resident .EXE and .SYS file > infector about 1,400 bytes in length. It has a little message embedded in > it thanking users for involuntarily spreading the virus. Please let me > know if you don't have a copy. I do have a copy of both variants of Involuntary, but the original posting was asking about the INVOLVE (not INVOL) virus and that has misleaded me. I have done a full search in my report files, instead of a fuzzy one... :-) Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN < PGP 2.0 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C e-mail: bontchev@fbihh.informatik.uni-hamburg.de D-2000 Hamburg 54, Germany ------------------------------ Date: 11 Dec 92 19:44:34 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Odd Virus? HELP (PC) ctoth@magnus.acs.ohio-state.edu (Christopher M Toth) writes: > sure I wasn't going to make backup copies of any virus. NAV told me > that it had detected the Pakistani virus and another one called the > Brain virus. Very silly from the part of NAV, since Brain does not infect hard disks... > First of all, I thought the Pakistani virus was only a > floppy disk infector. Exactly. > Anyway, I exited NAV after the warning and tired > using NAV again as a second check, well, this time NAV comes up with > NO viruses on my hard drive. Hmm... Are you using some other anti-virus software, by (mal)chance? > But when I checked my directory, I > noticed that some of my files(50-60%) had their dates changed to dates > ranging from 1955 to 1965. Can anyone help me out here?? Huh??? How can you achieve that?? As far as I know, the "year zero" in MS-DOS is 1980 and you just cannot have a date before that... Speaking about that, -how- do you know that the years have been in the 20th century? The DIR command displays only the last two digits of the year... Are you sure that the dates have not been from 2055 to 2065? Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN < PGP 2.0 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C e-mail: bontchev@fbihh.informatik.uni-hamburg.de D-2000 Hamburg 54, Germany ------------------------------ Date: 11 Dec 92 07:54:33 +0000 From: frisk@complex.is (Fridrik Skulason) Subject: Re: Not a Stupid OS/2 Question (OS/2) Kevin_Haney@nihcr31.bitnet writes: >Yes, I too wish that F-PROT, otherwise an excellent product, could be >modified to recognize the fact that it may be running on an OS/2 >machine Well, that is reasonably easy to do. However, what is really needed is a way to find out if a given drive letter corresponds to a FAT or a HPFS system. F-PROT seems to work OK on HPFS systems (apart from problems with long file names, like many other DOS programs), if it refrains from scanning the boot sector. This is on my list of things to do - but as a temporary solution, just telling it not to scan the boot sector when working on HPFS seems to work. - -frisk ------------------------------ Date: Fri, 11 Dec 92 11:30:20 -0500 From: "David M. Chess" Subject: re: A user's view of IBM's antivirus/2 (OS/2) > From: ygoland@edison.SEAS.UCLA.EDU (The Jester) > In conclusion, IBM's AntiVirus/2 is the friendliest anti-viral program > I have seen. Its easy to install, set up, and use. Glad you liked the program! We're pretty proud of it. I think it's still the only OS/2 anti-virus program that has disinfection features, an easy GUI interface, and all the rest. Brag, brag! *8) > But it's integrity > Management features leave alot to be desired. > this program does not list all files that have changed and how they have > changed. The short answer to this is that it's an anti-virus program, not a change-management or integrity-management program. But that's a cop-out. We did test internally a program that showed you every file that had changed (with hints as to which changes were most likely to be a virus). A few people liked it a lot, but most people found it basically just noise. Since programs change a *lot*, and very very few of those changes are caused by viruses, people got very tired of reading the change reports. Most users didn't want to know about a change unless it was caused by a virus. They didn't want to be told that SETVER.EXE had changed (because they added a SETVER entry), or that 123.EXE had changed (because they upgraded), or that their boot record had changed (because they changed a volume serial number). If enough people tell us that they want their anti-virus program to also help with change management, we'll certainly consider how to do that. But in general change management and virus protection seems to be mostly distinct; the vast majority of changes are non-viral, and if you want to know about them anyway it's probably because you have some other interest besides viruses. As usual, I'd love to hear from anyone who has different data; if there are large classes of users who want to know about every change on their machines, we'd like to help them, too. > Right now when you run a virus > check you only get a message if something goes wrong, nothing else > shows up. Thats great! That's it exactly. If enough people also want to see an entry in the log for every file that has changed, we'll look into making it an option. My fear is that, even if we say otherwise in big letters, people will assume that if an anti-virus program even mentions a file, that file must have a virus in it! *8) DC - - -- - David M. Chess | IBM AntiVirus/DOS and /2, in the U.S.: High Integrity Computing Lab | Retail: 1-800-551-3579 IBM Watson Research | Site Licenses: 1-800-742-2493 ------------------------------ Date: 11 Dec 92 18:12:56 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Integrity Management 72461.3212@CompuServe.COM (Ross M. Greenberg) writes: > >...Have just noticed that one of the major anti-virus houses has completed > >the addition of effective integrity management with the ability to > >use a single file for storage of all data for checking by their TSR > >instead of relying on snippets on the end of each program. > > C'mon now, Padgett: my own Virex-PC code has had this ability for > something like two years. Heck, even Flu_Shot+ has had that since Day > One (well, since version 1.1, at least) which means that it's been > available for about four years by this time... Well, maybe by "effective" Padgett also means "efficace" (sp?) integrity checking? I mean, in Bulgaria I've seen a program, that when run, used to modify COMMAND.COM of PC-DOS 3.30 in such a way that it displayed the string "FluShot+ is STUPID! Press any key to continue" and waited for a keypress each time the command interpreter was run... This was achieved using tunneling techniques, so FluShot didn't detect the modification of the file on-line. Furthermore, the file was modified in such a way, that the (rather trivial) checksum algorithm of FluShot+ didn't detect the changes... I can hardly call such integrity checking "effective"... Besides, Padgett does not claim that some company has suddenly invented the integrity checking; all he says is that a company that did not provide such features in their package, has finally decided to do so... This is always good news; let's only hope that the integrity checking provided will be secure enough... Regards, Vesselin P.S. No, I wasn't on vacation; I attended the EICAR anti-virus conference in Munich, so I was absent for about a week... :-) - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN < PGP 2.0 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C e-mail: bontchev@fbihh.informatik.uni-hamburg.de D-2000 Hamburg 54, Germany ------------------------------ End of VIRUS-L Digest [Volume 5 Issue 202] ******************************************