Return-Path: Received: from IBM1.CC.Lehigh.EDU by abacus.HGS.SE (SunOS 4.1/SMI-4.1-01) with sendmail 4.1/SMI-4.1-01 id AA16444; Thu, 2 Jul 92 00:14:09 +0200 Message-Id: <9207012214.AA16444@abacus.HGS.SE> Received: from LEHIIBM1.BITNET by IBM1.CC.Lehigh.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 8635; Wed, 01 Jul 92 18:04:54 EDT Received: from LEHIIBM1.BITNET by LEHIIBM1.BITNET (Mailer R2.08) with BSMTP id 2113; Wed, 01 Jul 92 18:04:37 EDT Date: Wed, 1 Jul 1992 18:02:26 EDT Reply-To: VIRUS-L@IBM1.CC.LEHIGH.EDU Sender: Virus Discussion List From: "Kenneth R. van Wyk (The Moderator)" Subject: VIRUS-L Digest V5 #124 Comments: To: VIRUS-L@ibm1.cc.lehigh.edu To: Multiple recipients of list VIRUS-L Status: R VIRUS-L Digest Wednesday, 1 Jul 1992 Volume 5 : Issue 124 Today's Topics: WARNING: New Mac virus (Mac) IMPORTANT ANNOUNCEMENT - new list address! Anti-virus recommendatinos for LANs? (PC) re: GROOVE Virus (PC) re: NAV killed, etc (PC) McAfee 91 versions (particularly VSHIELD) (PC) Re: Imprecise scanners (PC) Re: 1530 Virus (PC) Groove Virus (PC) Memory decrasing 1K (PC) Re: Zipped Viruses (PC) Azusa (PC) 696/Scr2/Enemy (was Re: Scream II virus help?) (PC) Re: Info wanted. (PC) Re: Virus-l stuf of late What ever became of the AMC? Re: Looking for CRC checksum formula 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. 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: Tue, 30 Jun 92 20:17:34 -0500 From: Gene Spafford Subject: WARNING: New Mac virus (Mac) New Macintosh Virus Discovered 30 June 1992 Virus: T4-A, T4-B Damage: altered boot code; altered/damaged applications Spread: possibly significant Systems affected: Apple Macintosh computers. All types, but see text. A new virus has been discovered, in two slightly different strains. These were included with the game application GoMoku, versions 2.0 and 2.1. These files were posted to the Usenet comp.binaries.mac newsgroup, and uploaded to various ftp archives, including the one at sumex-aim.stanford.edu. [Note: the game was distributed under a falsified name. The name used in the posting, and embedded in the game, is that of a completely uninvolved person. Please do not use this person's name in reference to the virus. The actual virus author is unknown, and probably used this person's name as a form of harassment.] When invoked, the virus attempts to alter the System file. This alteration attempt will be noticed by the SAM antivirus program (and possibly by Gatekeeper, depending on settings). The alert message that is displayed indicates that "Disinfectant" is trying to make the alteration -- whether Disinfectant is installed on the system or not. This is evidently an attempt to fool users into approving the modification attempt, thus allowing the virus to infect. The change to the System file results in alterations to the boot code under both Systems 6 and 7. The damage may render some systems unbootable, but will usually result in INIT files and System extensions (respectively) not loading. The virus also attempts to modify application files on the system disk. These alterations may damage some applications by overwriting portions of the programs with the virus code. These damaged applications *cannot* be repaired but must be reinstalled from distribution or backup media. Once installed and active, the virus does not appear to perform any other overt damage. At least one version of the virus may print a message when run after a certain number of files are infected by it. This message identifies the infection as the T4 virus. [Note: Although this note is unrelated to the T4 virus, we feel it appropriate and important to remind Mac users that neither Apple System 7 nor 7.0.1 should be used UNMODIFIED because they have the "disappearing folders" bug. Users should be sure they have installed the (free) System Tuner 1.1.1 from Apple on these systems; versions 1.0 and 1.1 of the Tuner are outdated or buggy and should not be used. Tuner 1.1.1 is available from authorized Apple dealers, from many user groups, from commercial networks, and on several places on the Internet. Also, System 7.0.1 is *not* the same as System 7 with the Tuner installed; 7.0.1 is a later release of System 7. System 7.0.1 also needs the update installed.] Authors of all major Macintosh anti-virus tools are planning updates to their tools to locate and/or eliminate this virus. Some of these are listed below. We recommend that you obtain and run a CURRENT version of AT LEAST ONE of these programs. Some specific information on updated Mac anti-virus products follows: Tool: Disinfectant Status: Free software (courtesy of Northwestern University and John Norstad) Revision to be released: 2.9 Where to find: usual archive sites and bulletin boards -- ftp.acns.nwu.edu, sumex-aim.stanford.edu, rascal.ics.utexas.edu, AppleLink, America Online, CompuServe, Genie, Calvacom, MacNet, Delphi, comp.binaries.mac When available: soon (probably by July 6) Tool: Gatekeeper Status: Free software (courtesy of Chris Johnson) Revision to be released: 1.2.6 Where to find: usual archive sites and bulletin boards -- microlib.cc.utexas.edu, sumex-aim.stanford.edu, rascal.ics.utexas.edu, comp.binaries.mac When available: soon Tool: Rival Status: Commercial software Revision to be released: T4 Vaccine, Rival Refresh 1.1.9w Where to find it: AppleLink, America Online, Internet, Compuserve. When available: Immediately. Tool: SAM (Virus Clinic and Intercept) Status: Commercial software Revision to be released: ??? Where to find: CompuServe, America Online, Applelink, Symantec's Bulletin Board @ 408-973-9598 When available: immediately Notes: User definition information: Virus Name: T4 Resource type: CODE Resource ID: Any 0 Resource size: >= 5600 Search String: Hex 2F2EFFD02F2EFFC43F3CA97B486E String offset: >= 714 from end Check value should be 'E7FA' if all fields entered correctly Tool: Virex Status: Commercial software Revision to be released: 3.82 Where to find: Microcom, Inc (919) 490-1277 When available: 6 July 1992 Comments: Virex 3.82 will detect the virus in any file, and repair any file that has not been permanently damaged by the virus. All Virex subscribers will automatically be sent an update on diskette. All other registered users will receive a notice with information to update prior versions to detect T4. The information necessary to update immediately is also available on Microcom's BBS: (919)419-1602 and on America OnLine. The update string follows: Guide Number = 7381312 1: 0230 FEAC 7500 00A9 / 36 2: 7B48 6EFF D62F 0E4E / BE 3: BA81 0230 FEA0 7500 / 3A 4: 00A9 7B48 6EFF D62F / 5D 5: 0E4E BA81 8280 9090 / 25 Tool: VirusDetective Status: Shareware Revision to be released: 5.0.5 Where to find: Usual bulletin boards will announce a new search string. Registered users will also get a mailing with the new search string. When available: Immediately. Comments: search strings are: Resource CODE & Size > 3900 & Pos -1200 & WData 3F3CA9CC*31BC4E71 ; For finding T4 If you discover what you believe to be a virus on your Macintosh system, please report it to the vendor/author of your anti-virus software package for analysis. Such reports make early, informed warnings like this one possible for the rest of the Mac community. Also, be aware that writing and releasing computer viruses is more than a rude and damaging act of vandalism -- it is also a violation of many state and Federal laws in the US, and illegal in several other countries. If you have information concerning the author of this or any other computer virus, please contact any of the anti-virus providers listed above. Several Mac virus authors have been apprehended thanks to the efforts of the Mac user community, and some are awaiting trial for their actions. This is yet one more way to help protect you computers. ------------------------------ Date: Wed, 01 Jul 92 11:48:59 -0400 From: Kenneth R. van Wyk Subject: IMPORTANT ANNOUNCEMENT - new list address! To ALL VIRUS-L readers: Since the first VIRUS-L message was posted on Fri, 22 Apr 1988 at 07:48:39 EDT, a trusty (but rusty) IBM 4381 mainframe computer has been dutifully distributing all VIRUS-L messages and digests. This machine, IBM1.CC.Lehigh.edu (aka LEHIIBM on BITNET), is going to be going away in the near future. Not to worry, however, since it is going to be replaced - by a series of IBM RS/6000 systems running AIX. This will mean that some changes will occur to the mailing list. Note that the comp.virus newsgroup should NOT be affected. The short term changes are as follows: o Next week (6 July 1992), I will be moving all current VIRUS-L subscriptions over to the new (UNIX-based) LISTSERV. When I do this, I will lock the old LISTSERV to prevent any new subscriptions from being added to the old list. All such errors will be sent to me, and I will deal with them manually (fun fun fun). o Once the old list is locked, all subscription (addition or deletion) requests must go to the new LISTSERV. The address of the new LISTSERV is: LISTSERV@Lehigh.edu. IMPORTANT: DO NOT SEND ANY SUBSCRIPTION REQUESTS TO THAT ADDRESS BEFORE NEXT WEEK; THEY WILL BE DELETED. o Note that some of the user-level commands are going to be somewhat different with the new LISTSERV. If you are not familiar with the UNIX LISTSERV that we'll be using, send mail to LISTSERV@LEHIGH.EDU saying "HELP". You will then get a list of valid LISTSERV commands, along with some general information. o VIRUS-L submissions sent to the old LISTSERV will be forwarded to me as normal, but this functionality will eventually disappear. IMPORTANT: Thus, all VIRUS-L submissions should be sent to VIRUS-L@LEHIGH.EDU as of 6 July 1992. o Note that the new addresses (virus-l@lehigh.edu for submissions, listserv@lehigh.edu for LISTSERV requests) are not on BITNET. Therefore, BITNET users are going to have to route their e-mail to the new Internet addresses. Contact your site administrators if you have questions on how to do this. o Submissions sent to virus-l@lehigh.edu before I've installed the subscription list will be rejected by the new LISTSERV. As with all new systems, there will no doubt be some teething problems associated with this switchover. I would appreciate everyone's cooperation and patience in dealing with whatever problems arrise. Duplicating the subscription list, for example, is going to be a partially manual process, since the two LISTSERVs do not use the same data formats. There are bound to be some dropped or otherwise mangled subscriptions. Also, there will be further changes related to the switchover. I will announce those as they are implemented. Thanks, Ken Kenneth R. van Wyk Moderator VIRUS-L/comp.virus Technical Coordinator, Computer Emergency Response Team Software Engineering Institute Carnegie Mellon University krvw@CERT.ORG (work) ken@THANG.PGH.PA.US (home) (412) 268-7090 (CERT 24 hour hotline) ------------------------------ Date: 27 Jun 92 09:37:53 -0600 From: STRASHEA@ZENO.MSC.Colorado.EDU Subject: Anti-virus recommendatinos for LANs? (PC) I would like to hear any comments from the network administrators out there who have used any of the ANTI_VIRUS programs for their networks specifically. We are currently pursuing a much more complete solution to the problem with something like Fifth Generations "Untouchable" product that was just advertised. We do have a site license agreement with McAfee for their NETSCAN, but something that would monitor the network on a consistant basis is preferred. - -Andrew Strasheim Metropolitan State College of Denver strashea@zeno.mscd.edu ------------------------------ Date: Sat, 27 Jun 92 21:48:00 +0100 From: Anthony Naggs Subject: re: GROOVE Virus (PC) Eric Essman (74656.557@CompuServe.COM) says: > Has anyone heard of a new MTE virus called GROOVE? I have a sample > here and I have comfirmed that it will infect EXE as well as COM > files. In addition, most A-V products that detect MTE miss this > one. Lastly, this product seems to target A-V products in much the > same way that PEACH does except this one targets multiple products. I am not aware of a virus called GROOVE, those of us producing or developing anti-virus products, particularly scanners, can only develop and test detection for viruses we have samples of. It sounds particularly urgent that you forward a sample if it is using an undetected variation of MtE and/or subverting a-v products. (Anyone discovering a 'new' virus) - - - - - - - - - - - - - - - - - - While you are likely to forward a copy to the publisher of your favourite a-v software, it may be helpful (both to the product publisher and their users) to send copies to publishers of other products. Obviously there is balance to be struck between bypassing the political barriers that stop some developers exchanging materials and the artificial proliferation of viruses. It would be helpful to those researchers that you forward a sample to to include details of other researchers to whom you have sent samples and the method employed (email, air mail, etc), so that they can decide who else to inform. Providing details such as how you acquired the virus, whether you still have a problem clearing it up and observed conditions for infection will help researchers in deciding how dangerous the virus is and the priority to be given to its analysis. If you are a regular reader of comp.virus/virus-l you can probably find contact details for a number of a-v developers & researchers fairly easily. However here are a few that commonly appear, and you may wish to consider forwarding samples to, (alphabetically): Bontchev, Vesselin (researcher) bontchev@fbihh.informatik.uni-hamburg.de Chess, David (IBM) chess@watson.ibm.com Ducklin, Paul (developer) duck@frcs.Alt.ZA Goretsky, Aryeh (McAfee Associates) mcafee@netcom.com Greenberg, Ross (author of Virex-PC, Flushot) 72461.3212@CompuServe.COM Jordan, Glenn (Virex-PC Development Team) trent@rock.concert.net Naggs, Anthony (developer) xa329@city.ac.uk Skulason, Fridrik (producer of FPROT) frisk@complex.is Wells, Joe (CERTUS) 0004886415@mcimail.com Yetiser, Tarkan (VDS Advanced Research Group) TYETISER@ssw02.ab.umd.edu [Hope I haven't missed anyone out] (Yes, Ken I know the rules say I shouldn't ask for viruses in here, I hope the above list and it's purpose are acceptable to you). [Moderator's note: Postings soliciting viruses will, in general, be rejected. This posting is being accepted because it is from a reputable source and provides useful information to people who believe that they have found a new virus.] Regards, Anthony Naggs Internet: amn@vms.brighton.ac.uk or xa329@city.ac.uk Janet: amn@uk.ac.brighton.vms ( cbs%uk.ac.brighton.vms::amn ) or xa329@uk.ac.city ( cbs%uk.ac.city::xa329 ) ------------------------------ Date: Sat, 27 Jun 92 21:49:00 +0100 From: Anthony Naggs Subject: re: NAV killed, etc (PC) Vern Chibber (chhibber@andromeda.rutgers.edu) reports: > Hi! Last night I was trying to install windows on my > 386-40MHz and I came across a very interesting dilema. It ran the > first time without a problem. The second time it told me that > win386.exe was corrupt. I run NAV.EXE (Norton Anti Virus) and it said > that it was corrupt too. I downloaded another copy from a friend and > the file increased by 1808 bytes. I copied it to another directory > and it increased by another 1815 bytes. I copied it over twice more > and the size stayed the same. Also, my machine appeared to slow down > somewhat. I also got a rectangle 6 lines by 12 rows of a different > color on the screen. This box also moved the text above it by a few > lines. Well any increase in executable file sizes indicates that a virus infection is probable. The sizes quoted, and the additional symptoms of system slow down & scrolling window, indicate that you have the Jerusalem virus or a close variant, (also known as "Friday 13th" as it deletes programs as they are run on any Friday the 13th). All Windows programs will be corrupted, as will some applications such as Word Perfect, these must be deleted, later restored from backups or original disks. Whether you can 'disinfect' and recover other programs will depend on the features of the A-V software you are using. What you should do now is find the MS-DOS/DR-DOS diskette supplied with your system, hopefully you write-protected it before or at least have done so now. (Note MS-DOS 5 upgrade disks are not bootable, which is extremely stupid & awkward in this situation). Boot your PC from the DOS diskette, do NOT run any software from the hard drive, now load Norton Anti-Virus from it's original diskette, (I presume this was supplied write-protected, if not protect it before use). If you hear a grinding sound this indicates that the virus is trying to infect Norton Ant-Virus, this means that your DOS diskette is infected, (in particular a program called in your AUTOEXEC.BAT, or otherwise run before before NAV). I hope that Norton searches system memory and will report finding Jerusalem virus in memory if it is there. As Jerusalem virus only infects programs when they are run it should be safe to scan the hard drive with NAV even if Jerusalem is in memory. As Jerusalem is one of the oldest PC viruses all anti-virus scanners should detect it, unless you a have a new variant. If NAV doesn't detect the virus you have several choices: contact Norton/Symantec; get a shareware A-V product from a reputable archive on the net (eg FPROT); contact a virus researcher with a copy of an infected file, (I have just posted a list to comp.virus). Hope this helps, Anthony Naggs Internet: amn@vms.brighton.ac.uk or xa329@city.ac.uk Janet: amn@uk.ac.brighton.vms ( cbs%uk.ac.brighton.vms::amn ) or xa329@uk.ac.city ( cbs%uk.ac.city::xa329 ) ------------------------------ Date: Sun, 28 Jun 92 03:46:24 +0000 From: rslade@sfu.ca (Robert Slade) Subject: McAfee 91 versions (particularly VSHIELD) (PC) There has recently been much confusion regarding the validity of the 91 version of McAfee's antiviral suite, particularly the VSHLD module. I have found there to be at least two versions of the VSHLD91.ZIP archive in circulation. Both contain the McAfee "authentic verification" envelope, and both are identical with the exception of the VSHLD91.DOC file. The older version of the doc file (May 27th) indicates that VSHIELD.EXE should (via the VALIDATE.COM check) result in 33DA for check method 2. The real result, as noted in the later (May 28th) doc file, is 11CF. SCANV91.ZIP and CLEAN91.ZIP archives, obtained from the same source as the "early" VSHLD91.ZIP show no problems. None of the files show any sign of tampering, viral infection or "trojanization". ============== Vancouver ROBERTS@decus.ca | "A ship in a harbour Institute for Robert_Slade@sfu.ca | is safe, but that is Research into rslade@cue.bc.ca | not what ships are User CyberStore Dpac 85301030 | built for." Security Canada V7K 2G6 | John Parks ------------------------------ Date: Mon, 29 Jun 92 10:45:00 +1200 From: "Mark Aitchison, U of Canty; Physics" Subject: Re: Imprecise scanners (PC) MC0170@mclink.it (Stefano Toria) writes: > bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) says: >> SCAN is -very- unreliable for virus identification.. >.. I would be very much interested in some detailed > facts, such as names of strains and variants that SCAN and/or Solomon > get mixed up with. I agree that virus detectors tend not to do a good job of identifying the viruses, (especially SCAN - but you could say their names are right and everyone elses are wrong:-). Of course their main job is to spot and get rid of viruses, and exact names might not be important (although I can think of one time when F-Prot and Scan's confusion of a virus name caused me trouble, and I think neither had it "right"). I presume Vesselin will follow with where to find the reports he has prepared listing CARO names for viruses plus the names given by some virus scanners. Here's a bit of his report (a condensed version of the start, rather than selected to show just the disagreements, so reasonably typical of the degree of match between these products)... I don't know what the latest version of SCAN calls them. Standard CARO name: | FindVirus 4.12: | F-Prot 2.03a name: | SCAN 89-B name : ------------------ | ----------------- | ------------------ | ------------- 10_Past_3 | 10past3 | 10 past 3 | 748 [748] 10_Past_3 | 10past3 | 10 past 3 | 748 [748] Thirteen_Minutes | Thirteen minutes.2| Thirteen minutes | Generic [GenF] 4870_Overwriting | Overwriting 4870 | 4870 Overwriting | 487 [487] Seventh_Son.284 | Seventh Son.284 | Seventh son (284) | 7thSon [7S] Seventh_Son.332.Germ | Seventh Son.332 | Seventh son (332)-G*| 7thSon [7S] Seventh_Son.332 | Seventh Son.332 | Seventh son (332) | 7thSon [7S] Seventh_Son.350.Germ | Seventh Son.350 | Seventh son (350)-G*| 7thSon [7S] Seventh_Son.350 | Seventh Son.350 | Seventh son (350) | 7thSon [7S] Eigth_Tunes | Eight tunes | Eight tunes | 1971 [1971] Ada | Ada | Ada | Ada [Ada] AIDS_II | like Aids 2 | AIDS II | AIDS II [A2] *=name truncated a lot to fit the screen here. At this point I could mention that I think it is silly for all these virus detectors to use different names, and how standard names (like CARO, or my own automatically-generated names) are a good idea, or how you can get my UPDATED freeware program BOOTID via anonymous ftp from newton.phys.canterbury.ac.nz [132.181.40.1] in /pub/local to identify at least boot sectors. Automatically generating names for file infectors is much harder (well, I can do it, but the name doesn't stay constant from infection to infection). I suspect that, with the likes of the Mte, it will be impossible for an automatic namer to work without at least some knowledge of the engine or a large collection of viruses that are supposed to be given the same name; the alternative is automatically generated names that are different for at least some infections, I expect. Mark Aitchison, University of Canterbury, New Zealand. ------------------------------ Date: Mon, 29 Jun 92 12:10:00 +1300 From: "PAULSTG@otago.ac.nz" Subject: Re: 1530 Virus (PC) >>Just recently, I found a few .COM files on my system infected with the >>1530 Virus. Norton AV and an old version of scan wouln't detect it, >>only scan90 and scan91 found it. Can someone tell me more about this >>particular virus or where to find detailed info on it? > > I recognize no "1530" virus, but there is one variant of the Dark > Avenger which is 1530 bytes long - and known as "CB 1530". I assume > this is the same program. I don't know if it is the same. From a brief inspection... This 1530 infects .COM files only, including COMMAND.COM. At some stage it writes to the screen (in teletype mode ie int 10h) a message which is encrypted (not by any complicated method) in the code at the end: DataRape! v1.1 (c)1991 Zodiac RABID, USA Smaller .COMs aren't infected (eg 100 bytes size and less), and when it infects COMMAND.COM, things slow down noticeably, especially a DIR, which (at least in DOS 5) requires a few keypresses to get through. The thing goes TSR whenever an infected COM file is run, and the memory change is noticeable. Newly infected COM files increase in size by about 900 bytes or so. Anyone know more about this one? /----------------------------+---------------------\ | Paul St George, | Paulstg@otago.ac.nz | | Information Science Dept, | Ph. +64 3 4798-135 | | University of Otago, | Fax +64 3 4798-311 | | PO Box 56, | | | Dunedin, | <---H---> | | New Zealand. | | +----------------------------+---------------------+ | "When you gaze into the Abyss, the Abyss gazes | | also into you..." | \--------------------------------------------------/ ------------------------------ Date: 28 Jun 92 21:32:12 -0400 From: ESSMAN <74656.557@CompuServe.COM> Subject: Groove Virus (PC) Just as a follow up to the GROOVE Virus. (New MTE) The virus is, of course, encrypted, but the following text appears in memory: Dont wory, you are not alone at this hour. This virus is NOT dedicated to Sara Its dedicated to her Groove (...Thats my name) This virus is only a test virus therefor be ready for my next test. Pretty spooky isn't it ...Eric Essman ------------------------------ Date: Mon, 29 Jun 92 10:38:58 +0500 From: Ege University Obs. Subject: Memory decrasing 1K (PC) We have an IBM PS/2 Model 30 in our Department. IBM DOS 5.0 was installed on it. Recently I tried to install DR DOS 6.0 but memory decreased 1K. I realized that Dr DOS diskettes carried a virus to the computer and I decided to reinstall IBM DOS 5.0. We have the original IBM DOS 5.0 diskettes so I was sure that the problem will be solved. When I install it the problem remained unchanged. I formatted the disk (20 MB) and tried reinstall DOS 5.0 but I failed. I scanned the disk with SCAN91 and it could not find any virus. Does anyone have any comment ? Is this a kind of virus ? Varol KESKIN Ege University Observatory Bornova, Izmir, TURKEY 35100 e-mail : EFEAST01@TREARN.BITNET ------------------------------ Date: Mon, 29 Jun 92 17:08:05 +0000 From: exuptr@exu.ericsson.se (Patrick Taylor) Subject: Re: Zipped Viruses (PC) David_Conrad@MTS.cc.Wayne.edu writes: >From: David_Conrad@MTS.cc.Wayne.edu >Subject: Re: Zipped Viruses (PC) >Date: 6 Jun 92 11:09:18 GMT >In VIRUS-L v005i111 Magnus Olsson writes: [stuff about infected virus scanner spreading a virus] >Not if the afore mentioned virus is a new one which the scanner does not >yet detect. In that case, you're in big trouble. Note that this is not >merely a problem with McAfee's scanner, but with any; also note that the >memory check is a excellent idea, it just isn't perfect. Of course, you can always run your virus scanner from a write-protected floppy ! ;-) "This must be Thursday. I never could get the hang of Thursdays" - D Adams - Patrick Taylor Ericsson Network Systems exuptr@exu.ericsson.se "Don't let the .se fool you" alternately, exuptr@ZGNews.Lonestar.Org ------------------------------ Date: Tue, 30 Jun 92 17:33:42 -0800 From: Jimmy Kuo Subject: Azusa (PC) Vesselin writes: >Mike 'the one with the grenade' Potaczala writes: >> I am trying to find out more information about the Azuma virus. I >> could not find anything on it in the McAfee documentation and McAfee >> did not detect it. Norton Anti-Virus did find it, but the person who >> has this virus problem does not have documentation for Norton >> Anti-Virus and therefore I wasn't able to check it. I would >> appreciate any information on this virus that is available. >Hmm, there is a virus, called "Azusa", but SCAN should detect it. Are >you sure that what your friend has is really a virus and not a false >positive, caused by NAV? The Azusa virus as detected by NAV is a boot sector virus which is memory resident. A repair is also provided if you are using NAV 2.0. Although the chance of a false detection exists always, chances that the Azusa definition in NAV might create a false positive is very small. The definition requires approximately 30-some bytes to match exactly and specifically over a 40-some byte range. Jimmy Kuo Norton AntiVirus Research cjkuo@ccmail.norton.com [I am the same person who used to be cjkuo@locus.com or CJKUO at BCRVM1/LOSANGEL within IBM.] ------------------------------ Date: Wed, 01 Jul 92 00:30:17 +0000 From: mjbrown@magnus.acs.ohio-state.edu (Mike J. Brown) Subject: 696/Scr2/Enemy (was Re: Scream II virus help?) (PC) I wrote: >My PC is infected with what Scan91 reports as "SCR2" which I assume >means Scream II (which is not listed in the virlist.txt file, of >course). I've got 124 .EXE and .COM files infected so far on one of >my hard drives. In the time since writing that, another hundred files got infected, accounting for about all of the .EXE and .COM files on the one hard drive. I obtained F-PROT which reported that the virus is Enemy, not Scr-2. Either way, the virus was supposedly unremovable. >If I do get a disinfectant, how can I expect to use it if the virus is >going to infect it as it starts up? Scanners/Disinfectants tend to >cease execution if they detect viruses in themselves... I figured out that I could PKUNZIP the files to a 3.5" disk without them getting corrupted in the process. So I did that and write-protected the 3.5" disk, then rebooted from a 5.25" (can't boot from B:), then ran the scanners from the 3.5". See, just gimme a minute and I'll figure these things out :) The scanners didn't detect the virus in memory when booting from the floppy, whereas they did when booting from the hard drive even without CONFIG.SYS and AUTOEXEC.BAT. An anonymous tip from another victim of this virus told me that it was actually neither Scr-2 nor Enemy, but was actually a variant of 696. He said (this was relayed through a couple of people, actually) that 696 could be removed with McAfee Clean. So... I got Clean and tried it out, like this: B:\> clean c:\dos\command.com [696] It reported that it "Found Scr-2 Virus [696]" and successfully removed it. A check of the file size showed it was back to normal, so I figured "success!" and proceeded to work on cleaning up everything on C: drive. B:\> clean c: B:\> clean c: /a <--I did this afterwards to be doubly-sure... Here's where the new set of problems began. 1. After booting from A: (the 5.25" drive) I had access to A:, B:, and C:, but not D:, which is the second hard drive. If I boot from C:, I can access D:, but not if I boot from A:. Booting from C: means I get the virus. Can I access D: after booting from A:? 2. F-PROT assumes that the virus it detects is what is really there. So F-PROT was useless to me. There were no discrepancies between what files it said were infected and what files McAfee Scan and Clean said were infected... just what the infection was. This is a complaint I hope the F-PROT people will take into consideration... :) 3. F-PROT said I had Enemy, Scan & Clean both said I had Scr-2. Well, which is it? And if it's 696, or something else... agggh. I heard there was I place I could send infected files to for diagnosis. Is there such a place? An FTP site maybe? 3. Every time I ran Clean it scanned memory for "critical viruses." Fine. But it stopped at 640K. Why didn't it scan my other 512K? This is a complaint I hope the McAfee people... :) 4. Clean successfully removed whatever the virus is from all but about 35 out of 225 files by the above process. Unfortunately, it took forever to do, because of what looks like a bug in Clean. (No, it wasn't infected, remember, I was running it from the write-protected 3.5" on a system freshly booted from an uninfected, write-protected 5.25"...) When Clean would find an .EXE file that it couldn't safely remove the virus from, it would stop and ask if I wanted to delete it. No matter what my answers were it would crash on every THIRD time it encountered one of these files. The third time it would tell me it couldn't safely remove it and ask me for Y/n to delete or not, like the other times. But if I said yes, it would say "Sorry, can't re-open file ...". If I said no, it didn't say anything. But whether the answer was yes or no, it would do the same thing: it went on scanning the rest of the drive (or the rest of the directories and files specified in the command line) but didn't look at any of the files like it did before. It zipped right through and skipped right to the end, telling me I had x number of files infected, y number disinfected, etc. etc. It didn't even see the rest of the infected files!!! So I had to keep running Clean over and over and over to get through all the files. Very frustrating. Anybody have any theories as to why it did this? McAfee people...? :) 5. Here's the killer. After getting rid of every un-disinfectable file and disinfecting the rest, then rebooting and running both Scan and F-Prot to make sure C: was not infected [D: was not accessed ever], I re-renamed config.sys and autoexec.bat to their proper names, and rebooted. (all of these reboots are cold, by the way) My config.sys lists several device drivers, all of which were previously infected. Some of them didn't work after disinfection. First it told me that \DOS\SETVER.EXE was invalid or missing (not true!) but didn't crash there. Then it loaded a few other drivers including GMOUSE.COM without complaint. It crashed (hung up entirely) upon loading the Directory Scanner driver. Okay, I thought, I don't use DS much, I'll remove that line from CONFIG.SYS. Getting that done was a task unto itself. Eventually I succeeded and was able to reboot. This time it crashed after loading the mouse driver. Great, I thought, and turned off the computer, flipped it off (y'know what I mean :), and went to bed. I haven't touched it since then. Next step will be re-scanning, which I'll have done by the time all of you are still with me get to read this. 6. It occurred to me that there are probably infected Hidden files... Why aren't these files scanned by any of the programs? Well, that's about all for now. I hope somebody can help me. Please zing some Email my way if you can. Thanks, Mike - -- Mike Brown mjbrown@magnus.acs.ohio-state.edu "The Universe is a spheroid region 705 meters in diameter." ------------------------------ Date: 01 Jul 92 08:09:20 +0000 From: frisk@complex.is (Fridrik Skulason) Subject: Re: Info wanted. (PC) vaughan@plymouth.ac.uk (Vaughan.Bell) writes: >I am looking for information on the following viruses or at least >where I can get info on the following viruses. The viruses are : >Virusoft 2 >Scorpio >No Rezid >Clipper >Beeper or Russian Mirror >Bad Taste >Anti Faggot >VSUM does not have info on these viruses or not under any name I >recognise, also I don't trust VSUM's info 100%. You don't say.... :-) Anyhow...I recognize a few of the names.. Scorpio is garbage. It is intended to be a virus, but as far as I can see it does not replicate, and never will. Russian Mirror: works ok - a 482 byte virus (Resident, Com files only), which I have never analysed in detail. Bad Taste is just one of the many variants of the Murphy virus - not terribly interesting, 1188 bytes long. Anti Faggot is based on the Vienna virus, but I have never figured out why it does not replicate - must be a bug somewhere in the code. - -frisk ------------------------------ Date: Mon, 29 Jun 92 15:16:00 +0300 From: Y. Radai Subject: Re: Virus-l stuf of late In his posting under the above subject, Fred Cohen says a lot of things with which I agree, and my sympathies for integrity checking are well known. However, when we get into the details, there are a few points in his posting on which I have doubts, especially in the following paragraph of his: > I am somewhat taken aback by the claims that integrity >checkers get substantial numbers of false positives or that they >require users to make decisions when they don't know how. IT has >never produced a false positive to my knowledge, and with a decent >implementation, we can easily automate all of the decisions to the >values set by corporate policy makers. On the other hand, people who >need to know about changes should have tools that let them know what >they need to know automatically. The point is that the claims against >integrity checkers don't wash - they are apparently just product >specific problems that require some better design work. Let's start with the statement "IT [Cohen's Integrity Toolkit] has never produced a false positive to my knowledge ...." That would seem to depend on what is meant by a "false positive". If it means the sounding of an alarm by an integrity checker even though the file has not been *modified*, then the claim is certainly believable, though hardly significant. So I shall assume it means the sounding of an alarm even though the file has not been *infected*. But under that definition, there are situations (e.g. after replace- ment of an existing version of a program by a new version, modifica- tion of setup info in an executable, etc.) in which the great majority of integrity checkers will give false positives. True, in *most* such cases, knowledgable users will be able to identify such situations and to realize that while there has been a modification, there has not been a virus infection. However, Fred seems to be suggesting that a well implemented integ- rity checker doesn't require users to make such decisions, and that the decision process can be fully automated (relative to the values of policy makers). I know of one integrity checker which in effect differentiates automatically between viral infections and other modifications and does a pretty good job of it, but it isn't perfect and I doubt that there is any other integrity checker which does as well (or does it at all). Moreover, it is possible to have a virus which exploits this diffi- culty of differentiation and causes a true positive to masquerade as a false one, namely a virus which does not infect a file *except when that file is being modified (or created) by normal means*, so that the user will think that the modification was solely the result of his own deliberate actions, and therefore will ignore the alarm. Examples of suitable conditions for infection would be during copying of files, compilation of programs, and formatting of diskettes. Unfortunately, integrity checking as such cannot distinguish between normal modification and infection by such viruses. (I'm not saying this could never be done by *any* means; in fact, I'll mention a couple of methods below which *partially* solve the problem, but it would no longer be pure integrity checking, at least as I understand the term.) When I first thought of such viruses four years ago, I called them "ambiguity" viruses since they exploit the ambiguity of the situation. However, when they began to actually appear during the last year or so (Darth Vader, Compiler and StarShip, though the latter two are not *pure* ambiguity viruses), they were called "slow" viruses by Vesselin, since they spread rather slowly. In any case, while no program can detect such viruses by modifica- tion detection alone, fortunately there are some other (partial) measures which can be taken against them. Viruses which infect when files are copied could be caught by comparing the source and target files after each copy. However, one would want the comparison to be performed *immediately* after every copy since the target file might be on a diskette which is about to be passed on to another computer (like those which StarShip infects), and there would have to be assu- rance that the virus wasn't distorting the comparison by stealth tech- niques. In the case of viruses (like Compiler) which attack newly compiled executables, one could adopt the rule of never releasing the result of a compilation unless it has been performed immediately after cold booting from a clean diskette (and that the compiler and loader are also clean). Unfortunately, there is no solution which is gua- ranteed to work in all cases of ambiguity viruses and which is not too inconvenient. Still, most of us agree anyway (even without the lesson of ambiguity viruses) that no one anti-viral technique is sufficient by itself. Y. Radai Hebrew Univ. of Jerusalem, Israel RADAI@HUJIVMS.BITNET RADAI@VMS.HUJI.AC.IL ------------------------------ Date: Tue, 30 Jun 92 18:00:00 From: (Steven W. Smith) Subject: What ever became of the AMC? Awhile back (late January?) an announcement was made on this list of the "Antivirus Methods Congress". I sent mail to the supplied address (amc@well.sf.ca.us) and in short order got a reply indicating that my membership was being processed, or somesuch. Well, months went by... about 5 weeks ago I sent another message to amc. It didn't bounce, it didn't elicit a response, and I'm fairly certain that I didn't imagine all of this. Did this group fizzle immediately? Are they doing wonderful, humanitarian things? Anyone know "what's the deal" with the AMC? Anyone care? _,_/| \o.O; Steven W. Smith, Programmer/Analyst =(___)= Glendale Community College, Glendale Az. USA U SMITH_S@GC.BITNET smith_s@gc.maricopa.edu Yes, that's my brand of coffee on the left. See how the spoon stands up in it? ------------------------------ Date: Wed, 01 Jul 92 17:30:00 +0300 From: Y. Radai Subject: Re: Looking for CRC checksum formula Ed Southard writes: > I would like to obtain the following formulas: > >a.) CRC-4 ?if possible >b.) CRC-8 ?if possible >c.) CRC-16 >d.) CRC-32 >e.) CRC-64 ?if possible > >Thanks. >-Ed > >[Moderator's note: Please reply directly to Mr. Southard via e-mail.] (I will ignore the moderator's note since this is going to be a short reply.) It all depends what you mean by "formula". (1) Basically, CRC-n is computed by considering the file as a poly- nomial with coefficients limited to {0,1}, multiplying this by x^n, dividing the result by a given monic n-th degree "generator" polynomial using modulo-2 arithmetic, and using the residue as the hash value. Translating this into English, it means appending n binary zeros to the file (considered as a binary number), dividing the result by a given (n+1)-bit number with leading bit = 1 using "long division" slightly modified (e.g. subtraction is replaced by XOR), and taking the remainder as the checksum. (2) Here's a simple algorithm, written in a pseudo-high-level language, which treats the file and the generator (excl. the leading 1-bit) as *bit vectors* F (of length m) and G (of length n), resp. (C is an auxiliary vector of length n+1): For j=1 to n+1 do C(j) := F(j); For i=1 to m do { K := C(1); For j=1 to n do C(j) := C(j+1) XOR (K AND G(j)); If i < m-n then C(n+1) := F(i+n+1) else C(n+1) := 0 } and the n bits of the CRC value are given by the first n bits of the final value of C. (Remark: The first statement of the algo- rithm assumes that m > n; if this is not the case, C must be padded with zeros.) (3) If by "formula" you mean a practical program, that's another matter .... Y. Radai Hebrew Univ. of Jerusalem, Israel RADAI@HUJIVMS.BITNET RADAI@VMS.HUJI.AC.IL ------------------------------ End of VIRUS-L Digest [Volume 5 Issue 124] ******************************************