From: Kenneth R. van Wyk (The Moderator) Errors-To: krvw@CERT.SEI.CMU.EDU To: VIRUS-L@IBM1.CC.LEHIGH.EDU Path: cert.sei.cmu.edu!krvw Subject: VIRUS-L Digest V5 #74 Reply-To: VIRUS-L@IBM1.CC.LEHIGH.EDU -------- VIRUS-L Digest Tuesday, 24 Mar 1992 Volume 5 : Issue 74 Today's Topics: re: F-PROT warning: false positive? (PC) Re: Which Package is Best? (PC) Re: Which Package is Best? (PC) Re: DOS version Backward incompatibility (PC) Re: Michelangelo bug ? (PC) More MBRs (PC) Fprot & 2to1 (PC) Floppy Disk Boot Records (PC) Re: Which Package is Best? (PC) Re: Recovery from a New Zealand Strike? (PC) Wanted: Info about "Form" virus (PC) Re: Network Viruses (PC) Increasing CBCS Security (PC) Re: Which Package is Best? (PC) re: St. Patrick's Day Virus? (PC) Disinfectant 2.7 (Mac) Re: Origins of viruses Viruses and epidemiology FAQ list cumbersomely long: split it up? The Ed McMahon Virus (Humor) 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: Mon, 23 Mar 92 18:31:08 +0100 From: vantent@eurcvx.eur.nl (Jan van 't Ent) Subject: re: F-PROT warning: false positive? (PC) Joshua Proschan <0004839378@mcimail.com> writes: >A related question: f-prot identifies nearly all the Norton Utilities >programs and several Microsoft Word programs as exhibiting virus-like >behavior, when the heuristic scan is used. Is this also a false >positive? Maybe ... I think it not unlikely that some 'standard' Norton tricks for direct or fast access are by-passing DOS to use BIOS or RAM directly, which F-PROT's heuristics could very well classify as non-standard or virus-like behaviour (also: for some users these ARE potentially harmful programs...) Of course in a more strict sense these ARE false positives, because the Norton Utilities won't infect other programs (unless the utilities are infected by some virus). vantent@CVX.eur.nl - Erasmus Universiteit Rotterdam - Netherlands ------------------------------ Date: 23 Mar 92 17:48:44 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Which Package is Best? (PC) 72571.3352@CompuServe.COM (Wolfgang Stiller) writes: > It's clear then that if 90% are not fully checked there IS a loss of > ability to detect an infected file. Since you were comparing two > products, my Integrity Master and Untouchable, it was vital to > compare similar modes if you're going to make a speed comparison. > You've got to compare apples with apples! Meanwhile I played a bit with both IM and UT. You are right, he should compare the full check mode. Comparing the quick check modes is not fair, since the full check mode of IM provides much better security than the quick check mode of UT. It is also true that the quick check mode of IM provides -much- less security than the quick check mode of UT. Also it seemed to me that the full check in IM is slightly faster than the one in UT, although the difference is not very noticeable. > I think that a 10% check is totally unacceptable. Keep in mind that Well, "totally unacceptable" is a bit too strong... It is pretty secure, although, of course, not as much as the full check. It would be nice if the user could tell the program how much s/he wants this percentage to be exactly... > both IM and UT often are used to detect other causes of file and > sector corruption. Also 10 executions would NOT quarantee that all For this purpose the user could use the full check. For virus detection only the quick check (if not abused) works pretty well. Otherwise why IM has a quick mode too? :-) > >VB>And don't forget that the generic disinfection will simply not work, > >VB>if the file has been previously infected. > > > YR> Of course. > I'm glad to that you admit the deficiency of genreric detection in > at least this instance. Oh, the guys from the marketting company did a pretty good job! They wrote: "Only Untouchable guarantees 100% safe recovery of infected files". Which is true - if the UT ever succeeds to remove a virus with its generic algorithm, you can be sure that the file is 100% recovered to its original state - since a checksum of the clean file is kept and verified. But how many people will undertand this as "Only Untouchable guarantees safe recovery of the infected files in 100% of the cases"? > Who cares how many errors were in the draft review? What matters is > that they were correct. I certainly wasn't quoting from the draft > review but from the published version. Oh, don't worry, there were some mistakes in the published version as well... (I know only it, so I cannot tell how buggy the draft was.) The author of the review didn't seem to understand wery well what the product does and how... I repeat, VB's technical virus descriptions are very good, because they are written by competent people (Jim Bates, Fridrik Skulason). But their reviews (especially the ones written by Dr. Keith Jackson) aren't. By the simple reason that they are written by people who do not seem to be enough techincally competent. Have you read the review of Stealth Bomber of the March issue of VB? It's just a retelling of the documentation of the product. No in-depth analysis, nothing said that the product actually provides almost no security and can be trivially bypassed (and is in fact bypassed by some of the existing stealth viruses)... > >I haven't seen the claim that it can disinfect *any* virus. If that's > >what the ads say, then I am against them just as strongly as you are. > I'm glad we agree on this point. Please check their full page display > advertisements in the major PC publications. As I said, they didn't claim that, but did it in such a way, as to mislead a lot of people. That's why most experts are angry at them... Wolfgang, now, when I have played a bit with both products, I have changed my mind a little... While I still agree that IM is the best of the shareware integrity checkers available, I must say that UT is - -much- better than it. In several ways - security, easy to use, user interface, network support, etc. One thing that extremely annoyed me was that IM seems to keep a separate checksum database in each directory. This is a very silly idea, only a little less silly than Norton's idea of creating hundreds hidden 77-byte files. In fact, it prevented me from installing the program on my office computer. It has a Stacked 60 Mb hard disk (which makes it look like a 120 Mb one), with 8 Kb clusters, less than a megabyte free space and about 1,700 (!) directories. There was just not enough place to install all your checksum databases... They must be kept in ONE file! I know that this poses some difficult management problems, but they are not unsolvable. After all, they have been solved in the Untouchable! There are some other minor things, which can make the life of the user easier. For instance, the creation of a safe diskette. IM contends itself to instruct the user what to do and lists one example, while UT contains a full analyzer of the hard disk's CONFIG.SYS and AUTOEXEC.BAT files (yeah, even if it calls other batch files) and the production of the safe diskette is fully automated... If it only supported DR-DOS 6.0 too... :-) One thing that I liked in IM better, however, was the installation procedure. It's really nice to have different levels of automation of the installation process, based on how knowledgeable the user is... As a conclusion, both products are good, and both have some things to learn from one another. 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: 23 Mar 92 18:30:16 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Which Package is Best? (PC) 72571.3352@CompuServe.COM (Wolfgang Stiller) writes: > Unfortunately, if *I* compared Integrity Master with Untouchable and > declared it to be a faster integrity checker and its known virus > scanner to detect more viruses, it would be regarded with suspicion > since I have considerable bias in this matter . I do in fact Certainly. It would be regarded with suspicion, if you didn't compare the other properties - security, easy to use, false positives... Something like VB's reviewers did... One can speculate whether their mistakes were intentional (VB is owned by Sophos), or just caused by incompetence. I personally tend to believe the latter. > when run in full check mode. His comparison of IM's full check with > UT's 10% "quick" check and his statement that UT was thus faster was > unfair. When run in full check mode IM was substantially faster > according to his numbers. True. The comparison was not correct. And IM is slightly faster. (Slightly, not substantially, according to my tests, but maybe this was caused by my particular conficuration - DR-DOS 6.0, SuperStored volume, resident virus scanner installed...) > It is with their marketting claims that I have a bone to pick. They > cause people to depend upon UT for disinfection. This is very unfair Yeah, indeed... And this is a Bad Thing... :-( Unfortunately, even the developpers of UT seem to be too excited about their generic virus removal... > not safely disinfect the files. I don't fault the product in this > area (as far as I know it's disinfection capabilities are as good as > any other) but simply the claims made for it. How can you trust the Well, it is difficult to compare. You cannot compare a generic remover with a virus-specific one. The virus-specific one (if it is good enough) will have a higher success rate, while the generic one will be more safe, because it will not destroy any files... > This corresponds to what I understand about UT. It can only handle > simple viruses which attach at the begining or end of each file. Oh, it can do a little bit more than that... But still not sufficient to rely entirely on it for disinfection... The authors have promised that the next version will be even better. They have figured some ways of generically disinfecting most of the 17 infection methods mentioned... They even claim that they'll be able to generically remove a virus, which inserts itself in an arbitrary place in the file (like Brainy, Phoenix, etc.). 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: Mon, 23 Mar 92 13:49:05 -0500 From: kw3@prism.gatech.edu Subject: Re: DOS version Backward incompatibility (PC) >Date: Wed, 18 Mar 92 15:32:00 +0000 >From: gary@sci34hub.sci.com (Gary Heston) >Subject: Re: DOS version Backward incompatibility (PC) > >> 2 - Is there disk duplicating software that could take a file >> on a hard disk and write bootable DOS disks for a different >> DOS version, assuming we had previously given in a master copy? Yes. It's called CopyQM by Sydex. We have been using it for several years. The program captures a disk image in any size and format and stores it in memory or on the hard drive. The image can then be duplicated regardless of the original DOS version. Essentialy it turns your computer into a disk duplicator. CopyQM v2.29 - Shareware Sydex P.O. Box 5700 Eugene, OR 97405 Voice: (503)683-6033 FAX: (503)683-1622 BBS: (503)683-1385 There is also an application for the Macintosh that can do the same thing for 3.5" disks called Disk Copy. It is unusual in that it will handle IBM format disks as well as Mac. Its only disadvantage is its inability to handle 5.25" disks. With the addition of a a Juke Box your Mac becomes an automated disk duplicator. The Juke Box is a device for auto loading the disk drive on a Mac. Disk Copy AppleLink Juke Box Fifth Generation Systems, Inc. 10049 North Reiger Road Baton Rouge, LA 70809 (504)291-7221 (800)873-4384 Keith R. Watson Georgia Institute of Technology, Atlanta Georgia, 30332 uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!kw3 Internet: kw3@hydra.gatech.edu ------------------------------ Date: Mon, 23 Mar 92 13:53:51 -0800 From: wetmore@cs.ucdavis.edu (Brad) Subject: Re: Michelangelo bug ? (PC) >From: kermits@akkali.iesl.forth.gr >I have a PC XT running under MSDOS 5.0 and recently discovered that >the boot disk along with some others was infected by Michelangelo >virus. Funny thing is that all the contaminated diskettes had been >unused for at least 2 months. So,is Michelangelo more older than >already assumed ? ================== Here is part of the description from CERT on the Michelangelo virus. FYI... [Moderator's note: The Computer Virus Catalog is put out by the Virus Test Center in Hamburg, Germany - not by CERT/CC here in the States.] ==== Computer Virus Catalog 1.2: Michelangelo Virus (17-Sept-1991) === Entry...............: Michelangelo Virus Alias(es)...........: --- Virus Strain........: Stoned Virus Strain Virus detected when.: Summer 1991 where.: Classification......: System virus (boot, partition table), resident Length of Virus.....: 429 Bytes A lot of coworkers thought this virus was something that just hit the "market" in the last two months. It's been around for a while. Brad / O / Steal here. X ---------------------------------------------------------------- O \ Brad Wetmore: wetmore@iris.eecs.ucdavis.edu \ Help!!! I've been robbed. Someone stole my .sig, and sold it back at the UCD used .sigstore. ------------------------------ Date: Mon, 23 Mar 92 20:12:19 -0500 From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) Subject: More MBRs (PC) All below are quotes - ------------------------------------------------------------------- From: Russ Ether (219) 231-3527 Subject: Re: FDISK /MBR and Stealth viruses. (PC) bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) writes: > barnold@watson.ibm.com writes: > >> I don't know of any viruses that don't leave a partition table intact >> in the master boot record. (Not that ignorance means much :) If you > > There are one or two, but for obvious reasons they haven't spread too > far... :-) What are the obvious reasons? I a virus does all the following... - --------------------------------------------------------------- Virus-L is not a tutorial for virus-writer wannabes but booting from a clean, write-protected floppy will fail to recognize the hard disk. Further, with a well-written BIOS (I can name several), an error message will occur on boot from the fixed disk. Users tend to notice that. Viruses fail to spread well when exposed to fresh air & sunlight. Warmly, Padgett ------------------------------ Date: Mon, 23 Mar 92 20:32:24 -0500 From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) Subject: Fprot & 2to1 (PC) >From: Michael_Kessler.Hum@mailgate.sfsu.edu >Subject: F-Prot false positive? (PC) >I do not know if this has been reported before, fixed etc. but I just >ran F-Prot to check a diskette that had 2to1.com and safembr.com on >it. Both programs were reported as "Possibly a dropper program for a >new variant of Stoned." The date of 2to1 is 9/28/91, of safembr >10/12/91 and I am using F-Prot 2.02D. This is the virtue of hueristic analysis and I would not really call it a "false positive" since Frisk is picking up the fact that my programs replace the Master Boot Record (MBR) - why the current versions include Validate numbers, should only be downloaded from reputable sources, and should be kept on bootable write-protected disks. BTW, these programs are now combined in FixMBR which also does considerably more error checking than the first examples. One thing that has delayed the release of some of my programs (and why I will not openly distribute source code) is so that they will not be used as viral tutorials by novices (anyone with the skill to take them apart is probably not going to learn anything they did not already know. Problem is that I believe that the proper place to fight viruses is at their level e.g. below DOS or from the BIOS. To do that you have to write BIOS code that is not normally found in a DOS program. Since my FIX & SAFE programs do not practise "stealth" or evasion (no tutorials again), a good program like Frisk's will wonder what is going on and report it to the user. Once again it is the old problem of one anti-viral tripping on another and for the age-old reason. More to the point, you should wonder why FDISK does not trip the same switch. Warmly, Padgett ------------------------------ Date: Mon, 23 Mar 92 20:59:15 -0500 From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) Subject: Floppy Disk Boot Records (PC) >From: "Mark Aitchison, U of Canty; Physics" >Subject: Re: Stoned/Azusa/McAfee's SCAN & CLEAN (PC) >I've used both F-PROT and CLEAN on a diskette infected with the stoned >virus where the "original" boot sector was missing, and appreciate the >problem the software has in finding a good boot sector to replace the >infected one with. There are, as I understand it, legal problems with >a commercial product carrying its own copy of a MicroSoft boot sector >(although I don't understand why, since the distribution disk is >allowed to have one, surely). Anyway, for what ever reason, these >disinfecting programs insist on trying to use the original boot >sector, if they can find it on the disk. What legal problems ? Being in a nasty mood, I will say it is either ignorance (curable) or laziness (also curable). The Boot Parameter Block protocol (three versions) is available to anyone who cares to dig it out and is the reason that most floppies formatted with DOS 2.0 are readable by DOS 5.0 and in many cases, the reverse. My FixFBR replaces whole boot sectors with my own code and I do not expect any lawyerly calls unless they come bearing gifts 8*) MicroSoft has sent out WORD disks with Compaq's boot record, Dr-DOS puts the IBM signature in the BPB, both Central Point and Peter Norton have used their own as has someone called "ALF" so it cannot be protected other than as any other program. Write another that uses different bytes to do the same thing and you can have your own copyright. The main problem is writing a boot sector that will suit everybody but even that is not too difficult (have one running now that is bootable by everything I've tested so far from IBM PC-DOS 2.0 to MS-DOS 5.0 to DR-DOS 6 - the OS does not care, it is *finding* the OS in the first place that is difficult. Of course there always seem to be "gotchas" especially when dealing with all of the different OSs and versions that exist - why I give away "beta test" versions to those who try to make such things fail, but FixFBR seems to be working well (famous last words) so am ready to try a bootable version since some people seem to want a bootable floppy with integrity checking (BTW, does anyone know why the DOS 5.0 boot record code insists on writing its own floppy parameter table that is only used while the boot record is executing - could this be something to do with the availability of 2.88 Mb floppys - have yet to see one or even a disk) ? However, while I could understand Microsoft or someone getting cranky if their FORMAT or FDISK programs were to be hacked to drop someone else's boot record, there is no law that I know of against writing your own boot record - I just did not bother to make FixFBR bootable so far (checks for infection & writes warning message about booting from floppies) since the SYS command will do the same thing. Now I might as well add that also. Warmly, Padgett ps - the reason the the anti-viral utilities mentioned try so hard to find the original boot record is so that they can be completely automatic. FixFBR avoids this problem by asking the user how big the disk is if it has trouble doing so itself (rarely). I figure that anyone smart enough to get my code can tell the difference between a 5 1/4 and a 3 1/2 inch floppy (besides the question is menu driven with only four choices, uses single validated keystrokes, and permits multiple attempts 8*). ------------------------------ Date: Tue, 24 Mar 92 03:48:51 +0000 From: trent@rock.concert.net (C. Glenn Jordan -- Microcom) Subject: Re: Which Package is Best? (PC) bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) writes: >72571.3352@CompuServe.COM (Wolfgang Stiller) writes: > >Yes, you are right. The generic disinfection is a Very Bad Idea >exactly because of that. I admit that the implementation of this bad >idea in the UT is excellent (e.g., it will never corrupt a file when >it tries to recover it, etc.), but the idea is still bad, especially >if the users begin to rely on it. McAfee Associates are trying to >implement it too (with their GenP and GenB virus removal algorithms), >and doubtlessly others will try too, but it's still a bad idea. What is new here ? VIREX for the PC has had its Inoculate database since the 2.0 release last summer, with the ability to generically detect changes and attempt repairs by replacing the initial 2 paragraphs of the file and chopping it off at the original ending point. After that we rechecksum the file to see if it matches the original, and if it doesn't we announce failure and ask the user what they want to do, delete the altered file or update the databases to account for a valid version update. We have found that the feature is very rarely used. Tech support calls on it are extremely rare. Users seem completely indifferent to this generic protection, so far. Of course, we never made any false claims about the infallibity of our methods, so like "Untouchable" in many respects. By the way, I don't think a CRC is superior to a proprietary Checksum for this kind of application. Checksumming is faster and though each individual checksumming method is sucessfully attackable, no one's has yet been attacked that I'm aware of, and the method is easy to alter between version updates. In the real world samples I've examined, duplicate checksums for different whole files have no real impact on the protection method. In my opinion, CRC's are a marketing gimmick pure and simple. Nice, particularly nice sounding, but not worth slowing down for, yet. The difference in relative "infallibilty" in the real world is not worth anything. Maybe later, who knows. As far as the quick look-up-table CRC calculations go, I'd rather have use the same code/data space for virus detection. Maybe that's one reason why "Untouchable" is missing such an alarming number of known viruses with their scanner ? Oh, well, there will probably be too many known viruses for ANY reasonable data space someday, as Alan Soloman likes to point out. I am speaking for myself, not Microcom, Inc. nor Ross Greenberg. ------------------------------ Date: Tue, 24 Mar 92 18:01:00 +1200 From: "Nick FitzGerald" Subject: Re: Recovery from a New Zealand Strike? (PC) gun6@midway.uchicago.edu (marianne catherine guntow) writes: >[someone - not Marianne - found New Zealand virus, did "something", PC won't boot from HD] > I've been told that New Zealand is a nasty virus much like > Michelangelo and Stoned. I'm looking for some more info on it. More > than that though, I'm looking for information on recovering from a > strike. Possible? I'm going to talk to her more but I would bet lots > of money that she doesn't have backups. The New Zealand virus can't be much more like Stoned than it is, being a (somewhat common?) psuedonym for Stoned. New Zealand is not "nasty" - not in Michelangelo's sense of deliberately overwriting, and hence destroying, some of the contents of an infected disk/ette - although it has a few unpleasant side-effects due to shortcomings in the virus author's apparent knowledge of some aspects of HD partitioning, etc. Normally (if there is such a thing), as part of infecting a HD Stoned moves the original Master Boot Record from absolute sector 0,0,1 to abs sector 0,0,7 (James Bond has a lot to answer for). It then writes the virus code to 0,0,1 so when the PC next boots from the HD the virus is the first piece of "external" code to execute. Assuming your user has not done something remarkably silly (like "format c:") then you may be able to recover by simply moving the original MBR back to 0,0,1. Norton's Utilities and several other disk/sector editors allow you to copy absolute sectors to achieve this. If something like this is not available you could try FDISK/MBR if you have a clean bootable DOS 5.0 floppy (this is undocumented and will work so long as the virus hasn't corrupted the partition information in the table at the end of the MBR - it doesn't usually!). Another alternative is to get Padgett Peterson's FixMBR utility. This looks in the places MBR viruses (like Stoned) are likely to have stashed the original MBR and will copy them back to where they should be. If you use FixMBR you should normally (there's that word again) expect it to find a usable MBR in the seventh sector of the affected disk. If your user ran some kind of disinfector and the HD in question was partitioned under an old version of DOS you may have to use something like FixMBR and select the SafeMBR code option. This is due to the virus overwriting part of the first copy of the FAT and subsequent corruption of the original MBR contents by file creation and/or modification in the area of disk represented by the affected part of the FAT. In this case the partitioning information is reasonably likely to have been corrupted and may require some skilled reconstruction. Further help/suggestions/advice gladly granted if more specifics can be provided. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Nick FitzGerald, PC Applications Consultant, CSC, Uni of Canterbury, N.Z. Internet: n.fitzgerald@csc.canterbury.ac.nz Phone: (64)(3) 642-337 ------------------------------ Date: Tue, 24 Mar 92 15:18:40 +0200 From: Magnus Olsson Subject: Wanted: Info about "Form" virus (PC) My computer (AT compatible running MS-DOS 5.0) seems to have been infected with the "Form" virus, or at least McAfee's SCAN reports that the boot record of my hard disk is infected by Form, and other virus scanners also say the boot sector is corrupted. I've looked it up in the Virus Catalog at ftp.informatik.uni-hamburg.de, and (fortunately) it seems to be a pretty benign virus, that only infecs the boot record. However, there are still some questions I'd like to hve answered before I attempt to remove the virus (meanwhile, I'm booting from a clean floppy). 1) Exactly what does this virus do? The Catalog says that on the 24th of each month, it "makes keys click and delays key action slightly" - is that really all? 2) What is the simplest method of disinfecting the HD? Will it be enough to just do a SYS command from a floppy, and is there any risk of damage if I do that? 3) No files seem to have been damaged (yet). However, the virus list enclosed with SCANV86 said something about Form damaging data files. In what way does it damage files? 4) Is there any risk whatsoever in using the executable files that are on my HD right now after disinfection, or should I restore everything from the distribution disks? If I've understood everything correctly, Form doesn't infect executables, so there shouldn't be any risk, but I'd like to have a second opinion... 5) Lately, my computer has hung at boot time with irregular intervals. The problem went away when I removed the disk cache from CONFIG.SYS. Could this be caused by the Form infection? Thanks in advance for your help! Magnus Olsson | \e+ /_ Dept. of Theoretical Physics | \ Z / q University of Lund, Sweden | >----< Internet: magnus@thep.lu.se | / \===== g Bitnet: THEPMO@SELDC52 | /e- \q ------------------------------ Date: Tue, 24 Mar 92 08:21:51 -0600 From: raymond@aramis.cs.ua.edu (Raymond Erdey) Subject: Re: Network Viruses (PC) > 1> Is it possible to bypass the read-only file-locking mechanism > provided by Novell Netware and Banyan Vines ? In one of the Novell Netware manuals it tells you not allow access to the debugger; Because any good hacker can overcome system security with it. So I would think that if a hacker can do this with a debugger, then why not with some assembly code? I am just learning how to set up a Novell Network. So I may be wrong. But I am a firm believer that no "security" is secure. :-) Raymond - -- - ------------------------------ Raymond M. A. Erdey Department of Computer Science Box 870290 University of Alabama Tuscaloosa, AL 35487-0290 (205) 348-7373 raymond@aramis.cs.ua.edu (Internet) ------------------------------ Date: Tue, 24 Mar 92 06:41:41 -0800 From: Toria@cup.portal.com Subject: Increasing CBCS Security (PC) bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) writes: > dgreefho@cs.ruu.nl (Danny Greefhorst) writes: > > I discovered something strange ; I booted from a perfectly clean > > system. Then I asked the directory of disk that was infected by FORM. > > After that I let Scan 86b search my memory for viruses and it said > > that FORM was active in memory. > > > How come that a virus is active after just reading the directory list ? > > This is called a ghost false positive and is caused by Scan's silly > way to check the memory. It scans the whole memory for the virus and > kdorma@nemesis.eche.ualberta.ca (Kevin Dorma) writes: > > > I ran f-prot and it came up with vsafe.sys and vwatch.sys (both from > > Central Point Anti Virus) being infected with a new or modified > > varient of FLIP. > > Yes, this is a false positive. CPAV is silly enough not to encrypt its > scan strings. Throw it away. > > > Is it normal for these programs to show up as infected > > Yes. Throw them away. You have easily done away with two of the most diffused (and relied upon) anti-viral programs in the Ms-Dos environment. I don't like to rely entirely on an anti-viral program in a real-life environment, but it's what I had to do on MC-link, the computer-based conference system I work for. We have a shareware library of some 300 Mb, about 100 of which are Ms-Dos. And our paying subscribers expect us to keep it free from viruses. So we have set up a regular routine by which every .ZIP that is uploaded by a user is manually checked, and one of the checks consists in running SCAN against it. This procedure has not kept us from stumbling in a sample of "September 18th", which was not acknowledged by SCAN (but was found by one of the users who ran CPAV against one of our newest additions). So I have determined to add some more anti-viral software to the check routine, namely CPAV, NAV and VIRex. I know I'm still not 100% sure, but I had to do something to decrease the residual insecurity given by trusting SCAN alone to do the job. Is there something more that I could do? I have been toying with the idea of using an integrity checker on a separate machine, on which I would run the new uploads and verify if the pre-existing software remains intact after each run. But I'm not sure if this would add any significant security to my system. - --------------------------------------+---------------------------------------- Stefano Toria, MC-link, Rome, Italy | "Fatti non foste a viver come bruti toria@cup.portal.com | ma per seguir virtute e conoscenza". - --------------------------------------+---------------------------------------- ------------------------------ Date: Tue, 24 Mar 92 17:16:00 +0200 From: Y. Radai Subject: Re: Which Package is Best? (PC) Round 3 in the Untouchable/Integrity-Master debate ... Donny Gilor, Wolfgang Stiller and Vesselin Bontchev write: >>>> IM 1:59 >>>> UT quick check 1:09 DG> DG>It doesn't seem fair to compare 10% of one software (quick scan) with DG>100% of another software (full scan) and say "we work faster". ^^ Before I reply to the charge of unfairness, I'm curious to know just who the "we" refers to. Since I'm the one who made this comparison, it sounds as if you think that Untouchable is, in part, *my* product, which is completely incorrect. Btw, while I was at the Virus and Security Conference in New York (which is why this reply is being posted so late), I got a look at Fred Cohen's ASP integrity shell and I was very favorably impressed by it. I don't yet have any hands-on experience with it, so I can't really compare it with packages like UT or IM, but it looks like a very serious contender, much better than the version of ASP which I read about a couple of years ago. Now to the point raised by Donny (and one of those raised by Wolf- gang). It is true that UT's full check is slower than IM's, and I can certainly understand why both of you, and probably many others, felt that my comparison of UT's quick check with IM's full check was un- fair. However, when I answered Vesselin's question, my criterion in comparing the two checkers for speed was to use the *fastest* mode which each product provides. Unfortunately, I had not noticed that IM also has a quick check. It does (albeit based on a different principle), and I apologize for this oversight. Nevertheless, given my above criterion and the (mistaken) assumption that IM does not have a quick check, my comparison was not unfair. My claim that UT's quick check is for all practical purposes just as secure as a full check was challenged by Vesselin and Wolfgang. Ves- selin claimed that a virus writer VB>could make a virus, which collects some statistics which files are VB>executed most often and infects only them. This way the virus will VB>spread better, while there will be fewer infected files and therefore VB>the probability that they will fall in the 10 % fully checked files VB>will be less. Sorry, but I don't think this is a very practical scenario. At best it would delay the detection of the virus by a tiny amount. That would hardly be worth any virus writer's effort. Wolfgang gives a different argument: WS>I think that a 10% check is totally unacceptable. Keep in mind that WS>both IM and UT often are used to detect other causes of file and WS>sector corruption. Also 10 executions would NOT quarantee that all WS>files were checked (nor would 100 executions)! True, even 100 executions in UT's quick-check mode won't *guarantee* that a given file has not been infected or corrupted. But even a full check can't guarantee security 100.00...00%. The question is not whe- ther security can be guaranteed, but how secure a given option is for practical purposes. In any case, both UT and IM assume that the user will not depend on quick checks alone, but will perform a full check in a clean system from time to time. The difference is that unlike almost all other products, which at best *advise* the user to periodically perform a full check after booting from a clean diskette, UT does its best to *make* the user do this by periodically displaying a large red notice telling him it's time to perform a safe test using the diskette which was created during installation and which contains everything necessa- ry to perform the task with almost zero effort on the user's part. Unless the user deliberately ignores these messages (which repeat on every boot until he obeys them), the fact that the quick check is not 100% secure is not so relevant. WS>I'm glad to that you admit the deficiency of genreric detection in WS>at least this instance. I suppose you mean generic *disinfection*, though I'm curious why you're so *glad* about this. Anyway, it looks like generic disinfec- tion is becoming more and more popular; I know of 4 products now which do it, the most recent being McAfee's SCAN/AG and CLEAN/GENERIC start- ing with Ver. 86, and I'm sure there'll be many more in the future. >>First, I can't help mentioning that I saw the *draft* version of the >>review (by Mark Hamilton) of Untouchable which appeared in the VB, and >>I must say I have never seen so many errors and confusion in a product >>review. .... WS> WS>Who cares how many errors were in the draft review? What matters is WS>that they were correct. I certainly wasn't quoting from the draft WS>review but from the published version. You seem to have completely misunderstood me. Didn't you notice that I prefaced my remarks with "I can't help mentioning that ..."? What I wrote at that point was simply a *BTW*, not something directly rele- vant to the discussion, and certainly not an argument against you. >>What I have found *so far* is that it fails on viruses which overwrite >>code (understandably) and on those which overwrite stack space (not so >>understandably, but this will be corrected in the next version). WS> WS>How will this be done? Do they plan to save even more than the 40 WS>bytes they copy from the front of the file? It seems the only way WS>they could do this would be to backup the entire file. Nope (but I can't give details). VB>The hash-table based search takes constant time only if there are no VB>colisions. As soon as the hash table begins to get filled, the search VB>will slow down. In the worst case (bad hash function and full hash VB>table), it will take as much time as the linear search. That's correct only if the size of the table remains *fixed* (or in- creases more slowly than the number of viruses). In general, the probability of a collision depends on the number of entries divided by the length of the hash table. The size of UT's table is kept *proportional to the number of viruses*, so the probability of a collision remains constant, hence the time remains constant also. >> Well, it would certainly help to have a file- and sender-authentica- >> tion scheme (by means of a two-key system, preferably preceded by a >> hash function) to authenticate the sender and to ensure that the file >> has not been altered en route to the user. .... VB> VB>I was speaking about ensuring that the system on which you are going VB>to install the integrity checker is virus-free, not that the integrity VB>checker itself is not tampered with. And I don't see how you can prove VB>that the MBR and the boot sectors are virus-free without performing VB>known-virus scanning... I was not speaking of ensuring that the integrity checker is virus- free, but of ensuring that *all files* on the disk are. I had given measures for ensuring that the MBR and boot sector were clean (by FDISK/MBR and SYS; it's not clear to me why one has to "prove" this), hence I assumed you were talking of how to ensure that the files on the user's disk were virus-free before the initial checksums are com- puted. As you know, inter-machine file- and sender- authentication is a way of greatly increasing the probability of that. VB>Or, do you mean that IM's virus -removal- does require an update, VB>while UT's doesn't, because it's generic? Yes, that's (approximately) what I meant. VB> Well, if we are counting the VB>-successful- virus removal, then in the long run IM is even more VB>efective, since there -are- infection methods which cannot be removed VB>automatically, and once the virus writers figure out this, they will VB>begin to produce mainly such viruses. Viruses, which IM will be able VB>to remove (if updated), while the generic remover - not. There is no such thing as a "long run" in this context, only a con- stant escalation on both sides. The whole point of generic disinfec- tion is that at any given moment there will be new viruses which KVSs have not yet been taught to remove, yet the *great majority* of them will be removable by a generic disinfector such as UT. As for the situation you describe of virus writers figuring out which types of viruses UT does not know how to remove generically, I expect that UT's disinfector will also be improved occasionally (though not nearly as often as KVSs need to be). Besides, remember that I didn't say that a known-virus scanner/remover wasn't necessary *at all* with UT, only that it's much *less* necessary. VB>I said "a Lehigh-type virus", not "the Lehigh virus". I meant a virus, VB>which hides only in one place in the system... How would such a virus spread?? The only types of viruses I can think of which hide in only one place are those which hide in the MBR, the DOS boot sector (or a hidden system file), or COMMAND.COM, and I have covered these cases (by FDISK/MBR, SYS, and refreshing COMMAND.COM, resp.). To spread successfully, a virus which is limited to a single place would have to be in a program which is present on nearly all hard disks and diskettes and which is frequently executed; how many pro- grams other than the above do you know of which satisfy these condi- tions? VB> we won't wait long until we see viruses, which attack ... VB>All checksum-based defenses. In fact, the stealth viruses are just VB>that. Remember the old argument whether a simple CRC can be forged? VB>:-) Well, they didn't try to forge it, they just invented a new form VB>of attack. We both know that stealth viruses can be taken care of by booting from a clean diskette. Do you have some other attack in mind? VB>I think you'll agree that if a system is infected with a virus, which VB>infects only one object in the system, and which infects other objects VB>only if they are modified, will not be detected by a checksummer, if VB>the checksummer is installed on an already infected system. I think what you're trying to describe is what I referred to as an "ambiguity" virus in my paper. It can't be detected by a checksummer *alone*, but there are other measures which can be taken in this case, and who says that the burden must be on a checksummer alone? VB> In fact, VB>it is possible to design a virus, which will even prenentrate a VB>checksum-protected system, even if the integrity checkers is installed VB>before the virus. Even if the system is booted from a clean diskette (and the checker is UT)? Please explain. >> I can only presume that [Hamilton] was not running Untouchable's >> resident module, UTRes, at the time, because it *does* detect all the >> common viruses in memory. VB> VB>The resident module - maybe, but the off-line scanner should detect VB>them too, IMHO... Yes, it should too. The reason I mentioned only UTRes is that it is normally resident, whereas UTScan is not normally run, except during installation. VB>As a conclusion - the UT is an excellent product and I recomend it to VB>everybody. However, let's better educate the users how to do proper VB>backups, instead of creating in them a false sense of safety (safety, VB>not security, since I -know- that the UT is secure) by letting them VB>believe in a magical generic removal method. Concerning backups, I wrote something about them in my last posting (to which you unfortunately have not reacted): >>That's true in theory, but in practice most users do not keep backups, >>at least not in a way in which they can be easily accessed for reco- >>very purposes, and that's the reason there is a demand for specific >>disinfectors ............ and generic ones (like UT). Moreover, many >>of those who do keep backups do it incorrectly, e.g. they keep making >>new backups of the same executable files until they find out that from >>some stage on, they have been backing up infected files. We could go >>into a long discussion of how (not) to create backups. Y. Radai Hebrew Univ. of Jerusalem, Israel RADAI@HUJIVMS.BITNET RADAI@VMS.HUJI.AC.IL ------------------------------ Date: 24 Mar 92 11:15:35 -0500 From: "David.M.Chess" Subject: re: St. Patrick's Day Virus? (PC) >From: mhollowa@csws5.ic.sunysb.edu (Michael Holloway) > >A friend reports that his computer was taken over by a virus that >replicated his root dir structure many times. Almost certainly not a virus; just a bug somewhere. This may be one for the FAQ, Ken! [Moderator's note: Added to the FAQ, thanks!] Q. Something very strange has happened to one of my directories: it seems to contain a copy of all the files and subdirectories that are in the root, *including itself*! So I have an infinite looping chain of subdirectories. Is it a virus? A. Probably not. This happens now and then, when something sets the "cluster number" field of some subdirectory to zero. The /F parameter of CHKDSK, and any of various popular utility programs, should be able to fix this, usually by removing the offending directory. *Don't* erase any of the "replicated" files in the odd directory, since that will erase the "copy" in the root as well (it's really not a copy at all; just a second pointer to the same file). DC ------------------------------ Date: Mon, 23 Mar 92 16:53:56 -0600 From: j-norstad@nwu.edu (John Norstad) Subject: Disinfectant 2.7 (Mac) Disinfectant 2.7 March 23, 1992 Disinfectant 2.7 is a new release of our free Macintosh anti-viral utility. Version 2.7 detects the new INIT 1984 virus. The INIT 1984 virus was discovered in the Netherlands and in several locations in the USA in March, 1992. INIT 1984 is a malicious virus. It is designed to trigger if an infected system is restarted on any Friday the 13th in 1991 or later years. The virus damages a large number of folders and files. File and folder names are changed to random 1-8 character strings. File creators and file types are changed to random 4 character strings. This changes the icons associated with the files and destroys the relationships between programs and their documents. Creation and modification dates are changed to Jan. 1, 1904. In addition, the virus can delete a small percentage (<2%) of files. The virus caused significant damage to the hard drives of several users on Friday, March 13, 1992. Because only a relatively small number of reports of damage were received, we hope that the virus is not widespread. The virus only infects INITs (also known as startup documents or system extensions). It does not infect the System file, desktop files, control panel files, applications, or document files. Because INIT files are shared less frequently than are programs, the INIT 1984 virus does not spread as rapidly as most other viruses. The virus spreads from INIT to INIT at startup time. The virus affects all types of Macintoshes. It spreads and causes damage under both System 6 and System 7. On very old Macintoshes (the Mac 128K, 512K, and XL), the virus will cause a crash at startup. If you have an INIT file which is infected by the INIT 1984 virus, when the virus attacks during startup, the Disinfectant 2.7 INIT beeps ten times, and an alert is presented at the end of the startup sequence. The virus is neutralized and does not spread or cause any damage, but the non-viral part of the infected INIT runs as usual. In order to properly detect and block the INIT 1984 virus, we had to make an important change to the way the Disinfectant protection INIT works. In previous versions of Disinfectant, the protection INIT always had to load last. Under System 7, the protection INIT had to be located in the System folder proper, not in the Extensions folder. These rules have been turned upside down in version 2.7. Starting with version 2.7, the protection INIT now must load first, before any other INITs. Under System 7, the protection INIT must be located in the Extensions folder, not in the System folder proper. The "Install Protection INIT" command in version 2.7 installs the new protection INIT in the proper location. When version 2.7 is run, it checks to see if an older version of the protection INIT has been installed in either the System folder or the Extensions folder. If it locates such an older version, it presents an alert asking if you want to install the new version. If you click on the "Install" button, the old version is removed and the new version is installed. In previous versions, several users reported "Unexpected error -194" errors when trying to install or save the protection INIT. We were finally able to reproduce this problem and find its cause. Version 2.7 fixes the error. Many users have had problems trying to build a System 6 Virus Tools disks because they could not fit System, Finder, and Disinfectant on a single 800K floppy. We now recommend building this disk without a copy of Finder and making Disinfectant the startup program. This should solve the problem. We have added a new "Known Problems" section to the document. This section lists in one location all of the known problems with Disinfectant and all of the known incompatibilities between Disinfectant and other software. Disinfectant 2.7 is available now via anonymous FTP from site ftp.acns.nwu.edu [129.105.113.52]. It will also be available soon on sumex-aim.stanford.edu, rascal.ics.utexas.edu, comp.binaries.mac, America Online, CompuServe, GEnie, Delphi, BIX, MacNet, Calvacom, AppleLink, and other popular sources of free and shareware software. Macintosh users who do not have access to electronic sources of free and shareware software may obtain a copy of Disinfectant by sending a self- addressed stamped envelope and an 800K floppy disk to the author at the address given below. People outside the US may send an international postal reply coupon instead of US stamps (available from any post office). Please use sturdy envelopes, preferably cardboard disk mailers. People in Western Europe may obtain a copy of the latest version of Disinfectant by sending a self-addressed disk mailer and an 800K floppy disk to macclub benelux. Stamps are not required. The address is: macclub benelux Disinfectant Update Wirtzfeld Valley 140 B-4761 Bullingen Belgium John Norstad Academic Computing and Network Services Northwestern University 2129 Sheridan Road Evanston, IL 60208 USA Internet: j-norstad@nwu.edu John Norstad Academic Computing and Network Services Northwestern University j-norstad@nwu.edu ------------------------------ Date: Mon, 23 Mar 92 13:07:10 -0800 From: wetmore@cs.ucdavis.edu (Brad) Subject: Re: Origins of viruses >markf@syma.sussex.ac.uk (Mark Foster) writes: >>kiae!rtech!vl!ALS@vl.ts.kiev.ua writes: : > I heard from the news that origins of virus points to Bulgaria. Is it : > true? And anti-virus activities started in Israel ? : : Oh,no! : But answer is simple: virus writing started with wide PC using and : anti-virus writing started when people recognized couple of viruses on : their PC's. >The very first virus that I ever saw or heard of was the SCA >(Scandinavian Cracking Association) virus for the Commodore Amiga. >Obviously inspired by the film 2010 approx 4-5 years ago and all in < >1k. >Can someone confirm or deny if this was indeed the one that started it >all. I haven't been following the thread closely enough to know if I've already missed something, but I thought I would add my .02 worth. The most popular "historical" accounts of computer virus was the work of Fred Cohen, "Computer Viruses: Theory and Experiments." He did a lot of work explaining what viruses are, and gave some of the first available code for explaining how they worked. However, according the book "Computer Viruses, A high-tech disease," by Ralf Burger, 1988, publications about "worm programs" and viruses appeared in the U.S. in the seventies and early eighties (ACM Use of Virus Functions to Provide a Virtual APL Interpreter under User Control (1974)). That is the earliest reference to computer viruses that I have. Brad / O / Steal here. X ---------------------------------------------------------------- O \ Brad Wetmore: wetmore@toadflax.cs.ucdavis.edu \ Help!!! I've been robbed. Someone stole my .sig, and sold it back at the UCD used .sigstore. ------------------------------ Date: Tue, 24 Mar 92 16:44:16 +0200 From: JJ Merelo Subject: Viruses and epidemiology Has anybody tried to study viruses using epidemiology methods? I mean, by identifying date of infection as accurately as possible, vector of infection, and so on, a map can be made, which can point to the first place of infection, and thus the source. I know that in a networked world this is a little bit difficult, but anyways knowing the exact date of infection and vector could be valuable. JJ ------------------------------ Date: Tue, 24 Mar 92 08:56:56 +0000 From: Anthony Appleyard Subject: FAQ list cumbersomely long: split it up? from: {A.Appleyard} (email: APPLEYARD@UK.AC.UMIST), Tue, 24 Mar 92 08:47:16 GMT The FAQ list, as a single message >1200 lines long, is massively cumbersome to read through or to find a particular reference in it. I feel that it should be published as a separate digest of several messages:- Subject: introduction to Virus-L FAQ list Subject: FAQ: sources of information and anti-viral software Subject: FAQ: definitions Subject: FAQ: virus detection Subject: FAQ: protection against viruses Subject: FAQ: facts and fibs about computer viruses Subject: FAQ: questions about specific viruses and antivirals Subject: FAQ: miscellaneous questions [Moderator's note: Anyone else have any opinion on this?] ------------------------------ Date: Mon, 23 Mar 92 17:27:00 -0400 From: Rich Stillman x6135 Subject: The Ed McMahon Virus (Humor) > The implications of what damage the "McMahon Virus" could wreak are > too chilling to contemplate. A message would flash on your screen saying... If your computer is infected with this virus, YOU MAY HAVE ALREADY LOST THE CONTENTS OF YOUR HARD DISK! Rich ------------------------------ End of VIRUS-L Digest [Volume 5 Issue 74] *****************************************