From lehigh.edu!virus-l Fri Jan 29 07:08:26 1993 Date: Wed, 27 Jan 1993 15:12:18 -0500 Message-Id: <9301271940.AA16908@barnabas.cert.org> Comment: Virus Discussion List Originator: virus-l@lehigh.edu Errors-To: krvw@cert.org Reply-To: Sender: virus-l@lehigh.edu Version: 5.5 -- Copyright (c) 1991/92, Anastasios Kotsikonas From: "Kenneth R. van Wyk" To: Multiple recipients of list Subject: VIRUS-L Digest V6 #11 Status: R VIRUS-L Digest Wednesday, 27 Jan 1993 Volume 6 : Issue 11 Today's Topics: Re: Yes, but is it a virus? Re: Export restrictions of anti-virus software? Re: On the definition of viruses Re: January LAT Good and bad viruses (was FC on virus creation) Re: os2-stuff (OS/2) DOS Viruses under HPFS (OS/2) Re: PKZIP V2.04C (PC) Re: Vshield vs Virstop (PC) Re: Wanted: info about Dos 5.0 virus (1578?) (PC) windows virus (PC) Re: Monkey [Mon] and Multi-2 [M12] viruses (PC) Cansu virus plague revisited (PC) Re: Known virus that tweaks PC date function? (PC) Re: Vshield vs Virstop (PC) Re: Untouchable (PC) Re: Untouchable (PC) new PKZIP problems? (PC) New Virus (PC) Internet Worm - Media (CVP) 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: Fri, 15 Jan 93 16:37:27 -0700 From: martin@cs.ualberta.ca (Tim Martin; FSO; Soil Sciences) Subject: Re: Yes, but is it a virus? ygoland@edison.SEAS.UCLA.EDU (The Jester) writes: >If Dr. Cohen is speaking of viruses to other experts in the field >then his comments regarding Beneficial Viruses and such are >appropriate and will be understood. I doubt anyone who understands >his comments would disagree with his assertions. The interesting point that Dr. Cohen made, though, in his first (?) article, was that it is precisely those one would expect to understand, the academics and the anti-virus software writers, who get most upset with his definitions. According to Dr. Cohen, his customers, who are non-experts, are not bothered about whether his protection software is using viral techniques to install itself on their systems, as long as the installation works efficiently. I call this the interesting point because I think (as an academic) that it is an interesting commentary on the nature of academia today. Tim ------------------------------------------------------------- Tim Martin * Spatial Information Systems * These opinions are my own: University of Alberta * My employer has none! martin@cs.ualberta.ca * ------------------------------------------------------------- ------------------------------ Date: Fri, 15 Jan 93 17:20:52 -0700 From: martin@cs.ualberta.ca (Tim Martin; FSO; Soil Sciences) Subject: Re: Export restrictions of anti-virus software? >From postings by Vesselin, Aryeh, and Frisk, I am informed that it would be against Canadian Law for me to "export" anti- virus "shareware". The Monkey virus, which originated in Canada, has been found in the US and in England. The Killmonk program, an embarassingly simple little snippet of code, also written in Canada (I haven't been out of the country for months, something we Edmontonians notice mid-winter), is one of few "convenient" ways of removing the Monkey virus from a hard disk. Killmonk is "freeware". The entertaining question of my week is "Am I breaking my country's Law by distributing Killmonk to persons and ftp sites outside Canada, to help them get rid of a virus that exported itself to them from Canada?" :) Nothing like a little legal mirth to warm the winter spirit. Tim. ------------------------------------------------------------- Tim Martin * Spatial Information Systems * These opinions are my own: University of Alberta * My employer has none! martin@cs.ualberta.ca * ------------------------------------------------------------- ------------------------------ Date: Mon, 18 Jan 93 10:06:10 -0500 From: Y. Radai Subject: Re: On the definition of viruses Albert Lunde writes: Fred Cohen can point with justified pride to the mathematical theory > of viruses. At the same time, I think it is perfectly understandable > that people will use more relative, subjective critera based on a > perception of risk and intention. This is especially the case since > one of the consequences of the mathematical theory is a proof that a > general "unknown virus" detector is impossible! You don't need Fred's mathematical theory to show that. It's also a consequence of any reasonable informal (natural-language) definition of "virus", as Fred himself has shown. Since his informal proof has been presented on Virus-L/comp.virus at least five times, I won't bother restating it here. However, I'd like to present an argument which I thought of a couple of years ago, which demonstrates (at least for all practical purposes) the undecidability of whether a given program contains a virus, in a completely different way from Fred's proof (the one based on the proof of the undecidability of the Halting Problem on a Turing Machine), a way which seems to me far more intui- tive, even if it's not quite as conclusive. Suppose a program contains code for replication, but only within a statement of the form "If then ", where is something which depends on the run-time environment, e.g. on the input which a user supplies. Can a detection program discover whether the program actually does replicate? To illustrate the generality of the situation, I'll even offer a choice between three reasonable informal definitions of "virus": (a) a virus is a sequence of instructions which replicates on *every* execution; (b) a virus is a sequence of instructions which replicates on *at least one* execution; (c) A sequence of instructions is a virus in a given run-time environ- ment if and only if it replicates in that environment. If the decision is to be made by appearance of the program alone, then the simplest case is (c), for suppose that the program asks the user to supply two numbers, x and y, and is "x < y". Then it is completely obvious that fulfillment of this condition cannot be determined without actually running the program, hence whether the program is a virus is undecidable by appearance of the program alone. Note that this argument does not require the assumption that the computer has an infinite amount of storage, as Fred's proof does. If the definition is (a) or (b), then we can do even better: we can show that in some cases the question cannot be decided even by running the program any finite number of times. For example, suppose the program asks the user to input four positive integers i, j, k, n (where n must be > 2). If you choose definition (b), I shall take to be "i^n + j^n = k^n". Now for all anyone knows, it may be that this condition is *never* actually satisfied. (The statement that there are no such integers is Fermat's "Last Theorem", for which he *claimed* he had found a proof, but he didn't produce it and no mathematician since him has found either a proof or a counter example.) Not only can we not decide this by appearance of the program, but even if we run this program a zil- lion times and the program doesn't replicate, that doesn't prove that it can *never* replicate; all one can say is that the program hasn't replicated *so far*. If you choose definition (a) instead, I take to be the negation of the above statement, and the same argument works. In any case, there are some situations in which you can't decide whether a given program is a virus. We can substitute for Fermat's Theorem any other unsolved problem. If you could write a program which could decide whether the resulting programs are viruses, then you would become famous for having solved all the world's heretofore unsolved problems!! (Well, at least those which can be expressed by a computer program.) Thus it is intuitively clear that the property of virality is undecidable, at least for all practical purposes. Of course, one can take the position that it's just an historical accident that these problems have not yet been solved, and that in principle they may all be solved some day. However, it can be shown that there are infinitely many problems which can *never* be solved (although that apparently requires use of one of those "paradoxical"- type proofs which I've been trying to avoid here). Comments are welcome (especially Fred's). Y. Radai Hebrew Univ. of Jerusalem, Israel RADAI@HUJIVMS.BITNET RADAI@VMS.HUJI.AC.IL ------------------------------ Date: Mon, 18 Jan 93 11:31:17 -0500 From: Y. Radai Subject: Re: January LAT Bill Lambdin writes: > I had hoped to test Search & Destroy From Fifth Generation > Systems, but I haven't received it yet. My understanding is that Search & Destroy is the same as UTScan + UTRes. (Fifth Generation's answer to those who want a scanner without an integrity checker.) Y. Radai Hebrew Univ. of Jerusalem, Israel RADAI@HUJIVMS.BITNET RADAI@VMS.HUJI.AC.IL ------------------------------ Date: Sun, 17 Jan 93 12:12:00 +0000 From: Amir_Netiv@f120.n9721.z9.virnet.bad.se (Amir Netiv) Subject: Good and bad viruses (was FC on virus creation) Y. Radai writes in response to Suzana: > But it doesn't *have to* become a bad virus. And if > it does become one, then by most people's definitions it probably > wasn't really a good virus to begin with. I think the dabate concerning "goodness" of viruses, has gone out of hand here... The question should not be if a virus is good or bad according to our benefit (or losts) caused by it, but: does it's behaviour and method of propagation comply with certain rules that will make it hard to detect/clean/ prevent! For example we concider a good virus as one that: - Does not reveal itself "easally" :-). - Uses "different" (unusual) stealth techniques. - Uses a special (prferably "new") method of hooking a program (think about DIR-II). etc... Most of the terms here can be subject to many intensive philosophical dicussions. So to my openion the question shold be: What are the rules ? Regards * Amir Netiv, V-CARE Anti-Virus, Head team. - --- FastEcho 1.21 * Origin: <<< NSE Software >>> Israel (9:9721/120) ------------------------------ Date: 15 Jan 93 06:04:18 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: os2-stuff (OS/2) chess@watson.ibm.com (David M. Chess) writes: > >could infect them by mistake. How are the DLL and DRV files loaded in > >OS/2? If they are not loaded using any INT 21h/AX=4Bxxh function, then > >it is rather unlikely that any of the currently known viruses will > >infect them... > No, no OS/2 call does an INT 21 at all; that's one of the main > reasons that no DOS virus runs in native OS/2. Operating system > calls in OS/2 are done using Protect Mode constructs like call > gates (I forget the details again!), not using INTs. DC OK, but suppose that the user opens a DOS window. Suppose also that s/he runs an infected DOS program in this window and the virus becomes resident. Does OS/2 access some DLLs in order to handle the running of a DOS program in a DOS window? Are those accesses visible to the program running in the DOS window? If they are not, then none of the currently existing viruses will infect a DLL file and there is no need to scan such files... Another possibility is a virus like Frodo, which (erroneously) infects files with different extensions, because it thinks they are COM or EXE. But Frodo's criteria for executable extension does not classify "DLL" as such and I don't know other viruses which do the same stupidity... So, it seems that there is indeed no need to scan the DLL files, right? Or am I missing something? 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.1 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: 15 Jan 93 23:27:00 +0000 From: bill.lambdin%acc1bbs@ssr.com (Bill Lambdin) Subject: DOS Viruses under HPFS (OS/2) Quoting from Chris Antkow to All About DOS Viruses under HPFS (O on 01-15-93 CA> Being a virus researcher myself, I find it sometimes suicidal to tes CA> out and disassemble new stealth and polymorphic class viruses on my CA> DOS based PC. I'm deathly paranoid that it's going to escape on one o CA> my floppies and infect the rest of my house... Even though I know my CA> ASM a bit better than the average Joe, who knows what might happen. When I test viruses, I configure my CMOS to deactivate the hard drive, then I cold boot the computer from a write protected bootable diskette. Re-activate the hard drive. Later i hope to get a laptop for research purposes. You might want to think of a dedicated virus test machine yourself. Bill - --- * WinQwk 2.0 a#383 * Hacked version of AutoMenu. 4.8 ------------------------------ Date: 15 Jan 93 06:11:58 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: PKZIP V2.04C (PC) btf57346@uxa.cso.uiuc.edu (Byron "Bohr" Faber) writes: > Just a note: With all the talk going around that pkzip204c is NOT > infected with a virus, I'm not suprised somebody has really infected a > copy and uped it. Why? Most people -still- think that it is infected. Others have at least heard the rumours and will be cautious... > You might be able to fool a few to many people. I think that the "anti- > virus" community should be carefull of what they are telling people. Well, we, the anti-virus people -are- careful. Unlike PKWare, who only posted the size and the date of the file (something easily forgeable), in my report I posted VALIDATE checksums of the file that I verified to be virus-free. OK, it is possible to forge them too, but it requires much more effort... Nevertheless, if somebody still does not feel secure enough, I can post a MD5 digest of the archive that I verified to be virus-free. Besides, the new PKZIP/PKUNZIP is so horribly buggy, that I wouldn't advise anybody to use it - data loss may occur and much more likely to bugs than to a virus... :-) 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.1 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: 15 Jan 93 06:23:44 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Vshield vs Virstop (PC) ST29701@vm.cc.latech.edu writes: > VSHIELD with the /CF option to check for a file validation information > will not catch a file infecting virus like INTRUDER (very generic) > untill after it has infected. I would have hoped it could catch it > while the infection was trying to occure. Well, the /CF switch instructs VShield to use checksums of the protected programs, stored in a separate file. This means that in this particular case, VShield acts as a resident integrity checker. All integrity checkers detect modifications, not viruses. Next, they can detect the modifications only AFTER the modifications occur. Thus, VShield with the /CF option will catch an unknown virus only after this virus infects a protected file (i.e., causes a modification) and you try to execute it (because VShield performs its checks on program execution). There is no way an integrity checker can detect a virus before any modification occurs... Of course, it remains unanswered why the -scanner- component of VShield does not detect the virus - at least SCAN 99 -is- able to detect Intruder (although it reports it as two viruses - Sick [Sck] and Intrud-B [Intr])... 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.1 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: 15 Jan 93 06:34:02 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Wanted: info about Dos 5.0 virus (1578?) (PC) lvandyke@balboa.eng.uci.edu (Lee Van Dyke) writes: > I have just been informed of a virus in command.com (47,845 4-9-91) of > Dos 5.0. Can anyone give me info on this? Please, check you source of information, before spreading rumors like that... We had enough of PKZ204C and definitively to not need the same story repeated for DOS. Also, please read the FAQ, question F4, in order to learn how to report suspected virus infections. In your particular case: 1) Where do you have this information form? The local pirate BBS, an unmoderated newsgroup, a friend, a newspaper, a computer magazine, Microsoft's tech support? 2) What does the information say exactly? If it says nothing more that COMMAND.COM in DOS 5.0 is rumored to contain a virus, then you can safely ignore it. Rumors like that appear with every new DOS version. 3) What -facts- support the claim that there is a virus? Does any scanner report it? Does it replicate? 4) Does your information source report a virus infection of a particular site, of the system diskettes distributed by a particular OEM vendor, of the diskettes distributed by Microsoft? 5) If there has been an official report about an infection from the supplier, for which geographical area does it apply? The net distributed your message all over the world. 6) At last, -which- DOS? MS-DOS, produced by Microsoft, or PC-DOS, produced by IBM? All in all, your message is either based on some local infection, or (more likely) is just a rumor. Until it is confirmed (and I doubt that it will ever be), just ignore 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.1 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, 15 Jan 93 11:50:14 -0500 From: S.M.Baines@sheffield.ac.uk Subject: windows virus (PC) I am sorry to be a nuisance, but several users of Windows at Sheffield appear to have been hit by a virus that isn't detected directly. Using memory resident virus checkers only detect a write to a protected file or disc, but not the name. Scanning the disc and memory also fails to show up the 'virus'. It appears only to infect the Windows files, and these fail to run. It has been caught trying to write to the kernel of windows, and has also written to other windows programs. As this has occured to 2 different users, not using the same computers, or software to get the same fault within 2 days of each other seems very odd. In both cases the only solution was to reinstall windows and all other software (including non-windows software) and hope the problem has gone away. The common link between the two was use of HENSA to download software at terminals at the University of Sheffield. Has this 'virus', if it is a virus, been reported before or is it just a bug and an unhappy co-incidence? Once again I appologise for disturbing you, but hope that someone can shed some light on the problem, in the mean-time we are avoiding down- loading files. Stephen Baines s.m.baines@howden.sheffield.ac.uk ------------------------------ Date: Fri, 15 Jan 93 16:18:38 -0700 From: martin@cs.ualberta.ca (Tim Martin; FSO; Soil Sciences) Subject: Re: Monkey [Mon] and Multi-2 [M12] viruses (PC) LIBBIE@pucc.PRINCETON.EDU (Libbie Counselman) writes: >We have been using and supporting F-Prot 2.06a on campus, but have >discovered 2 viruses that are not detected and not disinfected by >F-Prot. >The first one discovered was the Monkey [Mon] virus. It affects the >File Allocation Table. SCAN discovers it, but does not disinfect, but >Norton Disk Doctor will recover the clean FAT. I've posted a lot of notes in the past, about Monkey, so you may want to check the archives. Monkey doesn't infect the FAT; nothing does. It infects the main boot record (MBR) of a hard disk, and the boot sector of a floppy. The main twists Monkey has that make it different from Stoned are that 1. it doesn't keep the partition table in place in the MBR, and 2. it encodes the MBR before it hides it (in this case in sector 3 on the hard disk.) Because the partition table isn't in place, when you boot from a floppy you can't see the hard drive partitions, so any attempt to change to drive C: for example results in a "invalid drive specification" error. Because the MBR is encoded before it is hidden, general scanner/disinfector packages can't find the proper partition table values to recover the MBR properly. F-prot will find it on floppies, and call it "a new variant of stoned", but will not clean it. It has other twists, such as stealth, as well. I would like to know what you mean when you say that Norton Disk Doctor will recover the clean FAT. The FAT was clean all along. The problem is not to recover the FAT but to find appropriate values for the partition table. If NDD manages to do this, from a Monkey-infected hard disk, I am impressed. Actually one can take advantage of Monkey's stealth to get the proper partition table values. If you know a hard disk is infected with Monkey, you can boot the computer from the hard disk, so the virus is active, and use Norton Utilities or some such to see what the proper partition table values are. While the virus is active, a request to read the MBR sector (sector 1 of side 0, cylinder 0) will return the MBR (sector 3), properly decoded, instead of the virus sector. Copy down the proper table values, reboot from a clean floppy, use fdisk /mbr (with DOS 5.0) to reinstall the MBR executable code portion, and use Norton Utilities or whatever to type in the correct partition table data. >The second is known as Multi-2 [M12]. It has a predecessor called >Multi [M-123], also not recognized by F-Prot. This one infects .COM >files, .EXE files, overlays and becomes memory resident. CLEAN >apparently disinfects it. I don't know this one. >Does anyone know any non-commercial packages (i.e. shareware or freeware) >that can combat these viruses? I have written a program called Killmonk that should get rid of the Monkey virus. Killmonk is at several of the ftp sites, but let me know if you can't find it. Tim. ------------------------------------------------------------- Tim Martin * Spatial Information Systems * These opinions are my own: University of Alberta * My employer has none! martin@cs.ualberta.ca * ------------------------------------------------------------- ------------------------------ Date: Sat, 16 Jan 93 11:37:36 +0000 From: ianst@qdpii.comp.qdpi.oz.au (Ian Staples) Subject: Cansu virus plague revisited (PC) Further to my earlier post on this recent outbreak, a couple of other questions have arisen: When using CLEAN (v.99) to remove the Cansu virus from floppies things normally work as you would expect. BUT, every now and then a disk bobs up (only with 5 1/4" in our experience) which CLEAN thinks it can't cure. The message is something along the lines of "Cansu virus detected in boot sector, can not be safely removed." What gives? Why do some (most) work okay but some don't? Furthermore, once this message appears CLEAN then thinks it can detect the virus in the memory of the PC ("Warning: Virus active in memory. Power down...etc."). This seems to be the same "problem" that occurs with reading the directory of an infected disk or with using SCAN (v.99) on an infected disk - the virus, or at least it's signature - is left in memory and the subsequent CLEAN operation aborts as a result. Incidentally, CLEAN also has a somewhat confusing message when it is being run with the /MANY option. If the virus is detected and removed on a floppy and the next disk is in fact okay, CLEAN will give a message that it has found one virus but that there is no virus on the new disk. We eventually worked out that it is probably just giving a cumulative count of what it has found as you feed disks through the drive. BUT, the first time you see the message in an atmosphere charged with suspicion, concern, and a great deal of ignorance, it is pretty bloody confusing! I think McAfee could do a bit better than that. Any comments from people who know out there? - -- Ian Staples | Internet : ianst@qdpii.comp.qdpi.oz.au c/- P.O. Box 1054, | Fax : +61 (0)70 923 593 MAREEBA Queensland 4880 | Voice : +61 (0)70 921 555 Australia. | Home : +61 (0)70 924 847 ------------------------------ Date: 15 Jan 93 14:01:00 +0000 From: pcb!amyleigh.clarke@batpad.lgb.ca.us Subject: Re: Known virus that tweaks PC date function? (PC) AMN@vms.brighton.ac.uk(Anthony Naggs) writes: >student, asks: >In the office where I work, we recently purchased a 286 clone.. >Over the past few weeks, the computer's internal clock has been losing > days. [...] > > Has anyone heard of a virus that would produce these symptoms? If > not, does anyone have any other ideas about how to fix the problem? AN> AN>I don't remember any viruses like that, the only time I've seen AN>anything similar was on a 'true blue' IBM AT which needed a new AN>battery for the clock. If you bought this new then contact your AN>supplier saying you have a clock problem, if it's previously been AN>used then just replace the battery. I know that a lot of AT class (286) clones had this problem - it was really prevalent if a machine was left on all the time. Sometimes it would miss a midnight rollover. If memory serves me correctly, it was a problem in the BIOS. - --- . WinQwk 2.0b#0 . Unregistered Evaluation Copy - ---- //////////////////////////////////////////////////////////////////////// /////// This article originated at The Batchelor Pad PCBoard BBS /////// // Long Beach, CA ///// 1200-14,400 V.32bis+HST ///// +1 310 494 8084 // //////////////////////////////////////////////////////////////////////// ------------------------------ Date: 15 Jan 93 23:39:00 +0000 From: bill.lambdin%acc1bbs@ssr.com (Bill Lambdin) Subject: Re: Vshield vs Virstop (PC) Quoting from St29701@vm.cc.latech.edu to All About Re: Vshield vs Virstop (P on 01-15-93 S> VSHIELD with the /CF option to check for a file validation information S> will not catch a file infecting virus like INTRUDER (very generic) S> untill after it has infected. I would have hoped it could chatch it S> while the infection was trying to occure. I may be wrong, but I thought the parameter was /CV. Its been a while since I used VShield. Vshield can detect new and unknown viruses except for two types. 1. Stealth 2. Companion infectors. When a stealth virus is running, It will disinfect infected files on the fly when they are opened for any reason, then re-infect the files when they are closed. You could get Vshield to detect a stealth virus, but it would require two things. 1. a known clean write protected bootable diskette. 2. a known clean copy of Scan. Scan c: /CV. This compares the CRC of the file against the CRC stored in the file. Companion infectors do not infect files. They create small .COM files with the virus. DOS always looks for a .COM file first, then goes back, and looks for the .EXE file. The small .COM file with the virus is run first, then it loads the accompanying .EXE file. Bill - --- * WinQwk 2.0 a#383 * Intel sent Michelangelo on copies of LANSpool ------------------------------ Date: 15 Jan 93 23:06:00 +0000 From: bill.lambdin%acc1bbs@ssr.com (Bill Lambdin) Subject: Re: Untouchable (PC) Quoting from Vesselin Bontchev to All About Re: Untouchable (PC) on 01-13-93 VB> I has improved much since then. And I even don't have the latest VB> version... I had 1.1 myself, and FGS sent me an update notice, and I dowmloaded the 1.13 upgrade from their BBS. All they updated in the 1.13 version was the TSR, and scanner. VB> I have not seen a recent version of Victor Charlie, so I cannot VB> comment on that. (I saw on a few years ago and it was very poor, but VB> have heard that the product has been completely redesigned.) Integrit VB> Master is undoubtedly the best shareware integrity checker around, bu VB> it is still MUCH worse that the integrity checker in Untouchable... I have both the commercial, and share ware versions of Integrity Master 5.0, and I found the Integrity checking to be pretty good. I would like it better if Victor Charlie stored the database of CRCs on a rescue diskette. Personally; I like Integrity Master better than the integrity checking in Untouchable for the following reasons. 1. IM creates two CRCs per file 2. integrity Master creates can create CRCs for all files instead of just the subset of executable files. Granted Integrity Master can be improved. In fact I'm trying to talk Wolfgang into updating the scanner in IM to detect boot sector droppers. Untouchable doesn't detect droppers either, and I consider them to be a fairly large security hole. Prevention is always the best policy. Bill - --- * WinQwk 2.0 a#383 * JERUSALEM (Phenome) activates any Saturday ------------------------------ Date: 15 Jan 93 23:44:00 +0000 From: bill.lambdin%acc1bbs@ssr.com (Bill Lambdin) Subject: Re: Untouchable (PC) Quoting from Y. Radai to All About Re: Untouchable (PC) on 01-15-93 YR> This was due to a bug in UTScan. I'm told it will be fixed in Versio YR> 27. This is good to hear. Not that there was a bug, but that you are aware of the problem, and at work on a solution. YR> UTScan (like the rest of the Untouchable package) is, as you probably YR> know, developed in Israel. Israeli subscribers automatically get YR> updates at the beginning of each even-numbered month, so we have had YR> Ver. 26 for over a month now. I have no idea when updates reach the YR> U.S. market, but I presume there's a delay of a week or more. Yes: I knew that Untouchable was an Israeli product called UnVirus, and sold by BRM Technologies, then redistributed in the U.S. by Fifth Generation Systems under the name Untouchable. Bill - --- * WinQwk 2.0 a#383 * FATHER CHRISTMAS activates Dec 19 - Dec 31 ------------------------------ Date: Mon, 18 Jan 93 07:41:20 -0500 From: HAYES@urvax.urich.edu Subject: new PKZIP problems? (PC) Hello. Just received a lot of mail on the BBS where I moderate the virus awareness sub-board, all related to the new PKware PKZIP/PKUNZIP, now distributed as PKZ204C.EXE (self-extracting archive) and the update files for Symantec Norton's ANTIVIRUS (two files). Seems that the new PKUNZIP finds a virus, the _maltese amoeba_ and then stops de-archiving. I myself downloaded the two files, unzipped them with no problems, and verified them with both McAfee's Scan (v.99) and Frisk's F-prot. No virus found by both AV programs. Two questions: a) Does anyone know which type of AV PKware now adds to their program? b) Are there other reports of similar behavior from PKzip/PKunzip? Thanks in advance, Claude. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Claude Bersano-Hayes HAYES @ URVAX (Vanilla BITNET) University of Richmond hayes@urvax.urich.edu (Bitnet or Internet) Richmond, VA 23173 ------------------------------ Date: Sun, 17 Jan 93 12:50:00 +0000 From: Amir_Netiv@f120.n9721.z9.virnet.bad.se (Amir Netiv) Subject: New Virus (PC) Daphne Rosenhouse writes: > It looks like a variant of te WHALE, but larger, and > harder to remove Whell, it could be as you say (a variant of the WHALE), but it would be rather surprising, since the Whale is an old one and from a viral point of view... an unsuccessful one. I find it hard to believe that someone will use this as a base virus for modifications. Did you considered the posibility that you have a case of several viruses infecting togather or mabe one that infects files more then once ? Call me on voice sometime and I'll try to determine the nature of your virus. * Amir Netiv. V-CARE, Anti-Virus, Head team. * - --- FastEcho 1.21 * Origin: <<< NSE Software >>> Israel (9:9721/120) ------------------------------ Date: Thu, 14 Jan 93 23:41:31 -0800 From: rslade@sfu.ca Subject: Internet Worm - Media (CVP) HISVIRR.CVP 921215 The Internet Worm - the Media Media coverage of viral programs, and major infestations, has been consistently, and depressingly, inaccurate. An enduring mystery remains from the Internet Worm -- how did the media do so well at reporting it, a record which has never been equalled, either before or since? Highly accurate newspaper reports on the Worm were appearing even in regional newspapers as early as November 5th. Although some errors appeared in some stories, the errors tended to be minor. Although some very erroneous reports appeared, the ones that got printed tended to be the more correct. How did the information get out so quickly, and how was the media able to discriminate between the stories so well? (Even the erroneous stories that were carried contained exceptional information. A story from the New York Times on Sunday, Nov. 6th stated that Morris was able to track the progress of the Worm because "[e]ach second each virus broadcast its location to a computer named Ernie at the University of California". While this was not correct, it *was* true that the Worm was designed to have packets sent to ernie.berkeley.edu. The code which was to have done this was faulty, but, had certain programming been in place at Berkeley, it would have been possible to get rough estimates of progress.) John Markoff has come to be widely recognized for the excellence of his reportage in technical matters. An examination of his article of November 8th, 1988 is very instructive. While the technical details of his report could not possibly rival that of Spafford, or Eichin and Rochlis, the general concepts are present, clear and well presented. While experts could quibble over some of the details (he describes the sendmail debug option as a "trapdoor", and is rather free with assignment of motivation) I suspect they would have to admit that the important points are all there. Still, what contributed to this unprecedented, and so far unequalled, media accuracy? One of the factors is undoubtedly the number of researchers who were involved. Across the country, dozens and perhaps hundreds of people were involved in a detailed examination of the worm. Very little other work was being done until the problem was resolved. (Let's face it, for many people little work *could* be done until it was resolved.) Even those who were not actually engaged in research as to what the bug did were following the developments closely so as to be able to disinfect systems that they were responsible for. At the same time, there was not as much time for misinformation to spread via "friends of friends" who had once seen a copy ... copyright Robert M. Slade, 1992 HISVIRR.CVP 921215 =================== Vancouver ROBERTS@decus.ca | "Power users think Institute for Robert_Slade@sfu.ca | 'Your PC is now Research into rslade@cue.bc.ca | Stoned' is part of User p1@CyberStore.ca | the DOS copyright Security Canada V7K 2G6 | line." R. Murnane ------------------------------ End of VIRUS-L Digest [Volume 6 Issue 11] *****************************************