From lehigh.edu!virus-l Tue Apr 13 05:29:20 1993 remote from vhc Received: by vhc.se (1.65/waf) via UUCP; Tue, 13 Apr 93 18:01:31 GMT for mikael Received: from fidoii.CC.Lehigh.EDU by mail.swip.net (5.65c8-/1.2) id AA10226; Tue, 13 Apr 1993 16:01:17 +0200 Received: from (localhost) by Fidoii.CC.Lehigh.EDU with SMTP id AA19983 (5.67a/IDA-1.5 for ); Tue, 13 Apr 1993 09:29:20 -0400 Date: Tue, 13 Apr 1993 09:29:20 -0400 Message-Id: <9304131158.AA29788@first.org> Comment: Virus Discussion List Originator: virus-l@lehigh.edu Errors-To: krvw@first.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 #60 VIRUS-L Digest Tuesday, 13 Apr 1993 Volume 6 : Issue 60 Today's Topics: New Mac Virus Announcement - INIT-17 (Mac) Virus vectors of infection Scanners getting bigger and slower Re: Scanners getting bigger and slower Re: IDES'93 [Dick Lefkon] Vshield V102 Bug? (PC) Scanners and exe/com file compressors? (PC) VI-SPY VS Central Point AntiVirus (PC) DOS v6.0 and Virus Functionality (PC) Re: Optimum Strategy for Virus Checking (PC) Re: Port Writes (PC) Re: Scanners and exe/com file compressors? (PC) Re: Scanners and exe/com files (PC) Re: Catch from DIR? (PC) Re: Virus signature determination. (PC) Re: VI-SPY VS Central Point AntiVirus (PC) Re: WIndows Virus (PC) Re: Which CRC/scanner to use. (PC) New signature for TBAV (PC) Re: April Viruses? (PC) Re: Unknown little virus? (PC) Re: Uruguay on PS/2 ref disk (PC) Numbers and weighting (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.org 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, krvw@first.org ---------------------------------------------------------------------- Date: Mon, 12 Apr 93 12:42:05 -0500 From: spaf@cs.purdue.edu Subject: New Mac Virus Announcement - INIT-17 (Mac) New Macintosh Virus Discovered 12 Apr 1993 Virus: INIT-17 Damage: Alters System and applications files; may crash some Macs. See text below. Spread: unknown Systems affected: All Apple Macintosh computers, under both System 6 & System 7 The INIT-17 virus was recently discovered and analyzed. It spreads to the System file and many applications as they are run, and is likely to spread quite quickly on an infected machine. The infection is accomplished by altering existing program code, but the virus code that does this contains several bugs of various types. These bugs, coupled with the behavior of altering applications and the System file, may result in damage to those files. On some older Macs (e.g., Mac Plus, SE, Classic), the presence of the virus will cause those systems to crash during execution of infected applications. The only overt action by the virus is to display an alert message in a window entitled "From the depths of Cyberspace" the first time an infected machine is rebooted after 6:06:06 pm, 31 Oct 1993. The authors of all other 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: Central Point Anti-Virus Status: Commercial software Revision to be released: 2.01d Where to find: Compuserve, America Online, sumex-aim.stanford.edu, Central Point BBS, (503) 690-6650 When available: immediately Comments: The MacSig file will be dated 4/10/93 Tool: Disinfectant Status: Free software (courtesy of Northwestern University and John Norstad) Revision to be released: 3.1 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: immediately Tool: Gatekeeper Status: Free software (courtesy of Chris Johnson) Revision to be released: No new revision needed; 1.2.7 works 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: immediately Tool: Rival Status: Commercial software Revision to be released: INIT17 Vaccine 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: 3.5.5 Where to find: CompuServe, America Online, Applelink, Symantec's Customer Service @ 800-441-7234 When available: immediately Comments: Updates to various versions of SAM to detect and remove INIT-17 are available from the above sources. Tool: Virex Status: Commercial software Revision to be released: 3.92 Where to find: Datawatch Corporation, (919) 490-1277 When available: immediately Comments: Virex 3.92 will detect the virus in any file, and repair any file that has not been permanently damaged. All Virex subscribers will automatically be sent an update on diskette. All other registered users will receive a notice by mail. Datawatch's BBS number is: (919) 419-1602. UDV Code for INIT 17 ----Guide Number = 11583776 1: 0310 0011 2006 9230 / 7A 2: FE84 7520 0056 4952 / 4C 3: 7900 3400 11A9 A081 / D5 4: 0210 0001 30FE 8475 / F6 5: 2000 5649 5279 0034 / 89 6: 0011 A9A0 8182 8090 / 91 Tool: VirusDetective Status: Shareware Revision to be released: 5.0.8 When available: immediately Comments: VirusDetective is shareware. Search strings for the new virus will be sent only to registered users. 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. If you are otherwise unsure of who to contact, you may send e-mail to spaf@cs.purdue.edu as an initial point of contact. 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 have received criminal convictions for their actions. This is yet one more way to help protect your computers. ------------------------------ Date: Tue, 06 Apr 93 02:29:32 +0000 From: bediger@nugget.rmnug.org (Bruce Ediger) Subject: Virus vectors of infection My question is, "how do viruses spread?", and the followup question is, "are there any pointers to quantification of such spread?" It would seem that the only information on this is contained in the post-mortem reports on the 1988 Internet worm and the various DECnet worms. There are two likely, but unacceptable, answers to the question and its followup. 1. Thundering silence. 2. An insistence that Fred Cohen's original papers demonstrate that viruses spread due to information transitivity. Answer 1 is really a non-answer, making me think that such information doesn't really exist. This can't be true, given the amount of verbage generated by things like the threat of Michelangelo on March 6th. Answer 2 is a lot like asking what causes cholera and getting the answer of "bacteria", rather than "contaminated water supplies." Of course computer viruses spread because of information transitivity. Of course cholera is caused by bacteria. But we try to prevent cholera by promulgating clean water and sanitation standards. We don't try to catch cholera bacteria as they individually exit the drinking tap. It strikes me that there are several actual "vectors of infection". An incomplete enumeration might be: A. Networks. B. Media transfer from infected machine to uninfected machine. It may be necessary to break this down into two classes: "informal transfer", such as bringing a diskette full of games to work, and "formal transfer", when a vendor ships mass-produced media with a viral passenger. C. "Virus Exchange" bulletin boards. D. Source code published in books. E. Malicious individuals gain access to computers and insert viruses manually. Clearly, all are subsumed by the generalization "transitivity of information". Once a list such as that above is made, stopping viruses via "limiting information transitivity" seems a bit more of a productive approach. The November, 1988 worm and the DECnet worms used network related methods to spread. The geography of the spreading is irrelevant because of network connections, but based on the public reports, it appears fairly easy to determine that the worms spread via network protocols. The also seem to be of short duration and low number of hosts infected. According to the GAO/IMTEC-89-57 report, the Nov 88 worm infected 1000-3000 hosts. RFC 1135 says that within 48-72 hours, all instances of the worm had disappeared. In the report SPAN-027, the "Father Christmas" DECnet worm is said to have been on the loose approximately one day, and infected around 40 hosts. According to CIAC Advisory A-4, the "OILZ" variant of the WANK DECnet worm "attacked 60 hosts". This compares to estimates of tens of thousands of PCs infected with the Michelangelo virus a year ago. It would seem that if "Virus Exchange bulletin boards" are important, then outbreaks of new viruses would be contemporary, yet widely spread geographically. If a malicious individual gains access to computers and inserts viruses manually, there should be a series of geographically localized outbreaks of nearly identical viruses. I suppose "series" presumes that the malicious individual performs the act several times. Infection via media transfer would look very different if some vendor provided distribution media that was already infected than if someone just brings an infected disk home from a user group meeting, or to his/her office. Depending on the scale of the vendor's distribution, outbreaks might be provincial, national, continental or international. The virus itself should be identical everywhere. If viruses spread via publishing of source code, then inevitable typographical errors would creep into the code during transcription. Multiple similar, but not identical, variants should appear over a long period time, given the persistent nature of reference books. The geographic spread should be mostly coincident with the languages the reference book is published in. The "Vienna" virus is often cited as having many, many variants, and this is claimed to be so because of the source code published in Ralf Burger's books. The DECnet worms may illustrate a case of publishing of source code. I gather from SPAN report SPAN-027, CERT Advisory CA-89:04, and CIAC Advisory Notice A-4, the DECnet worms were all quite similar, and all were written in DCL. Thus each infected site had full source to them. The WANK worm also happened about a year after the Father Christmas worm. A counter-example might be Mark Ludwig's "Little Black Book of Computer Viruses." Source code for several viruses is provided. If the "timid" virus is made into several variations, publication of source code might be considered an effective vector of infection. If the "Little Black Book" viruses don't collect imitations over the years, publication should not be considered a threat. Since Ludwig's book is more accessible that Burger's, the "Vienna" virus variation would have to be considered in a different light. It seems to me that it would pay off to identify the most prevalent methods of spreading and attempt to hinder spread of infections by those methods. Naturally, this implies that there is interest in stopping virus spread. If the interest is making money by selling software and books, or through consultation fees, then identification of vectors of infection is not the best idea. - -- ------------------------------ Date: Wed, 31 Mar 93 08:55:00 +0100 From: Inbar_Raz@f210.n9721.z9.virnet.bad.se (Inbar Raz) Subject: Scanners getting bigger and slower frisk@complex.is (Fridrik Skulason) writes: >>The whole point of having more than one scanner, is that there is a >>considerable amount of viruses which are considered rare, or extinct, whose >>chances of infecting you are unreal. > Unreal ? Well, the problem is that almost all "extinct" or "research only" > viruses are generally available on the virus exchange BBSes - so somebody > could download one of them and spread it. I see your point. However, the way I see it, when we're discussing protection of BIG companies, as opposed to the protection of private people, the chances of someone downloading a virus from a board in order to deliberately upload it, are much smaller, if existant at all. If a company is wise enough to enfore a prohibition of disk exchange, and capable of doing it, then the networks/modem connection are the only way to get infected, and assuming those links are reliable links with reliable sources, this reduces the chance even further. > As I have said before - the number of viruses should not affect the speed > significantly - memory shortage is a problem, however - in 5 years a virus > scanner might require more than 640K of memory to run....but so what ? > I think it is reasonable to expect "everybody" to have more memory than > that in 5 years.. I see your point. Well, I don't think I have the slightest idea about what 5 years from now will look for, in whatever concerns virus techniqes, virus availability and degree of common, and so on. This is is a fast business... Inbar Raz - - -- Inbar Raz 5 Henegev, Yavne 70600 ISRAEL. Phone: +972-8-438660 Netmail: 2:401/100.1, 2:403/100.42, 9:9721/210 nyvirus@weizmann.weizmann.ac.il - --- FastEcho/386 1.25/Real! * Origin: Inbar's Point - Home of the UnTinyProg. (9:9721/210) ------------------------------ Date: Tue, 06 Apr 93 15:13:41 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Scanners getting bigger and slower Inbar_Raz@f210.n9721.z9.virnet.bad.se (Inbar Raz) writes: > However, the way I see it, when we're discussing protection of BIG companies, > as opposed to the protection of private people, the chances of someone > downloading a virus from a board in order to deliberately upload it, are much > smaller, if existant at all. Why do you think so? Just the opposite, a directed attack is the most probable thing that a disgruntled employee of a big company will do... It is difficult to detect, almost impossible to stop, and often impracticable to trace. > If a company is wise enough to enfore a > prohibition of disk exchange, and capable of doing it, then the networks/mode m > connection are the only way to get infected, and assuming those links are > reliable links with reliable sources, this reduces the chance even further. Problem is, this is very difficult to enforce... What are you going to do - searching the people each time they enter the company? A 3.5" floppy fits in a wallet... And, in the worst case, a virus could be brought in as a hex dump on a sheet of paper and the attacker could manually type it in! 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.2 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: Tue, 06 Apr 93 12:44:24 -0400 From: brunnstein@rz.informatik.uni-hamburg.dbp.de Subject: Re: IDES'93 [Dick Lefkon] Having been associated with the preparation of IDES'93 (and, despite of my remote connection, sharing somehow the responsibility of this year's "perfor- mance"), I regard "Buford Buckeye's" report a nice understatement of what happened: plainly a "disaster". For those lucky non-participants, here are only three "happenings": 1) Absence of ANY printed program: nobody, neither conference secretariat nor session chairpersons nor speakers nor participants had the slightest information which paper would be presented in what session. Moreover, as some speakers (whom to know was the singular privilege of Mr. Lefkon) didnot show up, Dick sometimes intervened session chairs by introducing new speakers (sometimes for totally different themes). Conference pro- ceedings were not available at the conference, and even today (23 days AFTER the conference), three participants from Hamburg did not receive the proceedings, said to be distributed on last day! 2) Registration and Keynote session: All started with long registration queues (despite attempted improvements of 1992's even worse queuing problems), and procedures overlapped heavily with keynote session. The announced keynote session on World Trade Center disaster began so late that the invited speaker (Sally Meglatherry) had to leave after 10 minutes talk! Despite of special advertisement, only 2 of the announ- ced 4 speakers appeared! 3) Unconvivial atmopshere: Two well-known AV experts, having been speakers in earlier years, whose photos were used to attract participants to "meet the experts" were escorted out-of-conference without justification and (as Mr. Lefkon said) "without any order" from the overall chairman, (Dick Lefkon chaired the conference, intervened in sessions, directed the organisaing committee, conference secretariat and program committee) Mr. Lefkon argues that "... the way the conference is run is being reorganized from the ground up". I wished so much that Mr. Lefkon were right!!! BUT: I've worked very hard, within IDES-94 Committee, to prepare a recovery from this year's disaster, including a report on the shortcomings, separation of organisation from program committee, and setting clear objectives before making personal decisions. After carefully observing, for 3 weeks, that NONE of the basic faults were changed, I decided (April 5,1993) to leave program committee. Some well respected experts had taken this step before - Harold Highland, Padgett Peterson, Fridrik Skulason - and others - Eugene Spafford, Ken van Wyk - followed me. I'm so unhappy because I always liked the idea to meet the experts (even if the scientific "value" was NOT comparable to other conferences on Security, Safety and Malware matters :-) As many experts have expressed their decision NOT to go to IDES-94 and their demand to meet next year at some nearby place (Philadelphia?) around March or April 1994, a new opportunity to meet AV experts is presently being prepared. Announcements will be made on Virus-L and related electronic fora in due time. Klaus Brunnstein (U-Hamburg, April 6, 1993) ------------------------------ Date: Mon, 05 Apr 93 19:41:15 +0000 From: sbarber@bach.udel.edu (Scott Allen Barber) Subject: Vshield V102 Bug? (PC) I am running a Pionex Goldseries 486DX Computer with AMI Bios and am having a "problem" with VSHIELD. It seems that if I load VSHIELD, when I go to do a warm boot (ctrl-alt-del) it will cause my computer to access the A: drive and restart the cold-boot memory check. It seems that some part of memory is written over when VSHIELD becomes resident, because SCAN's memory scan function will not cause this to happen. Does anyone else know about this problem??? Thanx...and please reply thru e-mail if possible... I will post a summary of all replies..... Scott Barber sbarber@brahms.udel.edu ------------------------------ Date: Fri, 02 Apr 93 12:38:02 +0100 From: Inbar.Raz@f2.n405.z111.virnet.bad.se (Inbar Raz) Subject: Scanners and exe/com file compressors? (PC) > From: phil@wearbay.demon.co.uk (Philip Coull) > Do virus scanners "unpack" exe/com files that have been > packed/compressed? If they do, how do they cope with all the various > packing programs? I'm absolutely sure that most "average" users are > totally unaware that some of their executables are modified in such a > way. Does it compromise the ability of scanners? I've never seen the > ability of scanners to deal with such programs mentioned in any reviews. > Even more worrying, is the following quote from PKWare's PKLite > documentation, when discussing the Professional PKLite version: > It uses a slightly different algorithm, which also scrambles the > excutable file. This scrambling makes the executable data more > resistant to disassembly or "reverse engineering" procedures. After a > file is compressed using this method, it cannot be expanded to match > the original executable file. Well, in Israel there is a company called B.R.M., marketed by PF1. They have an anti-virus program called 'UnVirus'. UnVirus is currently capable of scanning relatively SIMPLE compressed files - PKLITE (with the obvious exception of 1.15), LZEXE DIET Also: ARJ PKZIP (with the exception of 2.04) LHA The exceptions were correct as for August. I believe they are no longer existing. Aside from this fact, if I were you, I wouldn't pay much attention to the aledged warning by PkLite. Extracting the PkLited files, extra compressed or not, is really an easy thing to do. In simple words - Why should I bother trying to figure out the algorithm, if the PkLited file already has a mechanism to expand the code? This is a foot-thick clue, and I'll say no more. Regarding the Professional PkLite, though, there are dozens of programs lurking around the PC Market that allow you to successfully extract PkLited -e files. As a matter of fact, I once wrote one myself, but I no longer have it. Inbar Raz - - -- Inbar Raz 5 Henegev, Yavne 70600 ISRAEL. Phone: +972-8-438660 Netmail: 2:401/100.1, 2:403/100.42, 9:9721/210 nyvirus@weizmann.weizmann.ac.il - --- FMail 0.94 * Origin: Inbar's Point - Home of the UnTinyProg. (111:405/2) ------------------------------ Date: Mon, 05 Apr 93 23:31:10 -0400 From: barnold@watson.ibm.com Subject: VI-SPY VS Central Point AntiVirus (PC) minchin@rumba.seas.upenn.edu (Min-Chin Hsiao) asks > Just wondering if anyone has this problem? Is it just coincidence that > Flip's signature was found in CPAV files? Yes, this is a perennial (literally) problem between CPAV and other scanners, especially scanners that scan all parts of files. I first saw it with the Flip virus. Basically, CPAV appears to include search patterns for "polymorphic" viruses that can be found with wildcarded search patterns, and these search patterns are stored "in the clear" in program files. The search pattern representation used is hard to distinguish from a real virus degarbler (decryptor); metacharacters of some sort are apparently used to represent wildcards. This wasn't clear-cut when the only hit was on the Flip virus(es), but after a half-dozen other virus degarblers were "found" in CPAV files, the pattern became clear, without any reverse engineering required (or done). I'll let others pronounce judgment on whether or not this is a reasonable practice. Bill Arnold barnold@watson.ibm.com (IBM AntiVirus development) ------------------------------ Date: Tue, 06 Apr 93 04:24:03 -0400 From: fergp@sytex.com (Paul Ferguson) Subject: DOS v6.0 and Virus Functionality (PC) Greets. Has anyone had an opportunity to tinker with MS DOS v6.0 and it's "capacity" for existant virus functionality? No, I'm not referring to Microsoft's sad attempt to implement Central Point's CPAV (MSAV), but rather the architectural changes in the OS. I'm curious, although I'm not going to rush out and obtain a copy merely to satisfy my curiosity. Given the impact that DOS v5.x had on many existant viruses when it was introduced, (many existant viruses would simply not run under DOS v5.x), I'd garner that much of the same "non-functionality" will appear with the architectural changes to the DOS v6.0 implementation(s). I'm of the opinion that keeping your toolkit of third-party products current beats the tar out of relying on Microsoft to provide it for you in the DOS v6.0 "upgrade". In fact, I've been hearing that several folks have had problems while logged in under Netware 3.11, on both 4Mb Token Ring and Ethernet LANs after thet rushed to "upgrade" to DOS v6.0 .... But then again, what do I know? Cheers. Paul Ferguson | "Sincerity is fine, but it's no Network Integration Consultant | excuse for stupidity." Centreville, Virginia USA | -- Anonymous fergp@sytex.com (Internet) | sytex.com!fergp (UUNet) | 1:109/229 (FidoNet) | PGP 2.2 public encryption key available upon request. ------------------------------ Date: Tue, 06 Apr 93 09:19:27 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Optimum Strategy for Virus Checking (PC) riordan@tmxmelb.mhs.oz.au (Roger Riordan) writes: > 5. By default VET will check the first 50 executable files it > finds. Most program viruses will spread rapidly, so this will > detect nearly all infections the next time the PC is booted. Uh, what do you mean exactly by "the first"? Because, for a non-resident virus that traverses the directory tree like Old_Yankee, "the first" files is one thing and for a non-resident virus that infects the files in the directories listed in the PATH variable (like the Vienna viruses), "the first" might mean something completely different... Again, for a non-resident virus (like Pixel) that infects all COM files in the current directory, "the first" could have a third, again completely different meaning. Make the virus resident and the picture changes again... > The author of the locally written Gingerbread virus went to > inordinate lengths to hide it, but if it infected a PC with VET > installed the user would be warned in the normal boot that the top > of memory had been changed. After a clean boot VET would also warn > that the MBR and the VET file were corrupted. You've had luck that the author has not used the method used by the Necropolis (1963) virus to remain resident... 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.2 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: Tue, 06 Apr 93 09:25:27 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Port Writes (PC) Inbar_Raz@f210.n9721.z9.virnet.bad.se (Inbar Raz) writes: > A couple of days ago, I first succeeded in compiling and running a routine to > access disk using port writes only, therefore avoiding any interrupt > whatsoever. [stuff deleted] > Is there any EXISTING control program to inhibit such access? Yes. Most modern hard disk controllers issue a hardware interrupt to indicate "device ready" when they are done with the request. You could count the access requests that have passed "naturally" through INT 13h and check whether the number matches the number of "device ready" interrupts from the hard disk controller. If there are more "device ready" interrupts than INT 13h requests, this means that something has accessed the disk in a non-natural way, so you raise an alert. At first look it might seem that this way you can only -report- the disk write after the fact. Fortunately, for each Write request the controller actually performs -two- actions - Seek and then Write. It issues "device ready" after each of them, so you'll be able to raise the alert after the Seek and before the Write. Unfortunately, this does not work on all controllers (I've seen at least one which is dumb enough not to issue "device ready" interrupts) and theoretically a virus could disable your program that is listening to the device ready interrupt, but this tends to screw things up...) > If a virus were > to use port writes, no anti-virus shield would be able to stop it. This will also make the virus rather non-portable. Unfortunately, it will still work on many computers and the virus writers don't seem to care about portability anyway... (I've seen a virus that is able to infect correctly only 17-byte files...) BTW, note that many hardware anti-virus products -will- be able to stop this kind of disk access, if they can be installed between the computer and the disk controller or between the disk controller and the bus... 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.2 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: Tue, 06 Apr 93 09:35:41 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Scanners and exe/com file compressors? (PC) phil@wearbay.demon.co.uk (Philip Coull) writes: > >It cannot be expanded by PKLITE, that is...expanding it with a special > >program is not a problem at all. > I think what you're saying here is that pklite can't expand it, but its prett y > easy to write one that does!(?) Almost. Read carefully the PKLite documentation. It says that the files compressed with the extra compression option cannot be decompressed to match the original. This is true - often such files cannot be recovered EXACTLY to their original state, because some information is lost during the compression... But it does not mean that they cannot be decompressed to an EQUIVALENT state. The only difference is in the relocation items of the EXE header... There are several programs available that are able to decompress the files, compressed with the extra compression option of PKLite. DISLITE and UNP are two of them; both are available from Simtel20. > If that is the case there seems to be little > point in using PKLITE Pro! Yes, if your aim is to obscure the contents of the file. Don't forget that the extra compression option compresses slightly better than the "normal compression", so there -is- some point of using it... > As an aside, and without giving away any "trade secrets". Can you use the > compressed programs built-in ability to uncompress itself, or do you have > to write a de-compressor totally from scratch?? Any of the two approaches can be used. 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.2 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: Tue, 06 Apr 93 09:45:58 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Scanners and exe/com files (PC) shakib.otaqui@almac.co.uk (Shakib Otaqui) writes: > You're so right. Some idiot recently posted on the Fido-Net > Batchpower echo the debug script for what was described as a tiny > disk cache program. At least two users have reported that the > program trashed their drives, even though it had been scanned. Well, if they are relying only on a known-virus scanner for anti-virus protection, they could be successfully attacked by any new virus - regardless whether it has been compressed or not. > Investigation showed that the file was compressed with PKLite > 1.15, and that a hex editor was used to replace the PKLite > signature with null characters. This apparently defeated SCAN, > which treated it as an ordinary file. After uncompressing the > file with PKLite, one user said SCAN apparently identified it as a > virus, though I suspect it's more likely to be a trojan. Hm, I just tried the same with F-Prot 2.07. It succeeded to recognize that the file is PKLited, but didn't try to scan inside it... Why, Frisk? 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.2 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: Tue, 06 Apr 93 10:01:57 +0000 From: louis_rs@bruny.cc.utas.edu.au (Louis *grin* siuoL) Subject: Re: Catch from DIR? (PC) Malte_Eppert@f6051.n491.z9.virnet.bad.se (Malte Eppert) writes: >Hi Frisk! > > There is, however, one way to run a program from a diskette by > > just doing a DIR, >Ugh... if this isn't too special, can you or someone else post how this could >be possible? I just know about an ANSI bomb which will execute a file from >disk if you hit the 'hot key' next time. Do you mean this? That may be one way. A method that I KNOW WILL WORK is, to trap DOSs findfirst and findnext services, and infect any files that are returned via thos services. Is as easy as traping DOSs Exec services, which is what a large number of virii do. - -- Louis Solomon Internet: louis_rs@postoffice.utas.edu.au FidoNet : 3:670/216 ------------------------------ Date: Tue, 06 Apr 93 09:54:16 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Virus signature determination. (PC) Malte_Eppert@f6051.n491.z9.virnet.bad.se (Malte Eppert) writes: > I always use the term 'polymorphic' in a different way to 'encrypting'. What > you describe under 2) is an encrypting virus, what you mention under 3) is a > polymorphic one. You are correct; just a minor nit-picking: we call "encrypted" any virus that uses any kind of encryption ("encoding" is the more exact word). Those of them that use a different key each time, but a constant decryptor, are called "variably encrypted" viruses. Those that also modify the decryptor are called "polymorphic". There is some fuzzy class of viruses like Bad_Boy or Commander_Bomber, which do not use encryption at all, but instead swap/generate (unencrypted) parts of themselves, but they are currently not of much concern... > Isn't the term 'polymorphic' specifically reserved for viruses who > have their encoder changed along with every copy by exchanging instructions > etc. in a way that there can be no signature extracted? Yes, except that for -some- polymorphic viruses (e.g., the Phoenix viruses), it -is- possible to pick a (possibly wildcard) scan string from the variable decryptor... 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.2 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: Tue, 06 Apr 93 10:11:35 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: VI-SPY VS Central Point AntiVirus (PC) minchin@rumba.seas.upenn.edu (Min-Chin Hsiao) writes: > Vi-Spy consistently pick the Central Point Antivirus files like > vsafe.com or Vsafe.sys saying that Flip virus is found. I think I have used a > Virus scanner from Taiwan Eten group which report the same thing. Read the FAQ, question C6, the last sentence of the second paragraph. It answers to your question. Maybe we should put it in a separate FAQ entry... > Just wondering if anyone has this problem? Yes, about everybody who is using CPAV and some other scanner... :-) > Is it just coincidence that > Flip's signature was found in CPAV files? No, it is not. 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.2 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: 06 Apr 93 10:20:50 +0000 From: rogera@compnews.co.uk (Roger Allen) Subject: Re: WIndows Virus (PC) Thanks for all the help I have received from everyone, I even received an email address for Macfee etc from someone. I have a file which I think may be the culprit; I say this cos I havn't mangaged to get the virus back properly. It did start to fade the screen but now it won't at all (no it wasn't a screen fault). Anyway, I'll be sending out this file to people who requested it and in the mean time I'll check all the other files I received around that period to try and find the infected file if it isn't the one I thought it was. Roger ------------------------------ Date: Tue, 06 Apr 93 10:20:48 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Which CRC/scanner to use. (PC) btf57346@uxa.cso.uiuc.edu (Byron Faber) writes: > I currently use f-prot/virstop/ and Integrity master on my machine. > (a 386/40 pc). I was curious if anyone could give me their opinions > as to which scanner would be the best to use. According to my experience, F-Prot detects more viruses than the scanner in the Integrity Master package. From IM you should use mainly the integrity checker. > I have been in a > high risk group for computer viruses and have found that Integrity > master's crc checks and f-prot's heuristic scans have done pretty well. > If anyone has opinions on my setup, or could suggest any other > alternatives please mail me. If you are protecting yourself from a highly probable, but random (i.e., not directed against your particular installation) attacks, then the above set of programs is OK. Just use F-Prot to ensure that the system is virus-free before installing the IM's integrity checker and then use F-Prot to scan any incoming software. Also, install IM in the most secure mode, with the information saved on a floppy and checked after a clean boot. 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.2 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: Tue, 06 Apr 93 13:15:18 +0000 From: v922340@dorrestein.si.hhs.nl (Snaaijer) Subject: New signature for TBAV (PC) Althoug i posted reasently that there will be no more VIRSCAN.DAT I found on the TBBBS (Thunder Byte BBS) a new signature file vsig9303.zip and a new Beta version TBAVB510.zip unfortunaly the new signature file doesn't detect Terminator II (althoug v5.10b does detect it for a while). The vsig9303.zip file isn't made by Frans Veldman, but as it is available on his BBS I assume it's checked by him. I mailed the files to Timo Salmi, because I can't use ftp fully. The files will hopfully be available soon. Ivar. - ----------------------------------------------------------------------------- Rule one in program optimization : Don't do it. Rule two in program optimization (for experts only) : Don't do it yet. Rule three in program optimization (for athlets only) : Just do it. - -- E-mail : v922340@si.hhs.nl ... i can't help it, i'm born this way ... - ----------------------------------------------------------------------------- ------------------------------ Date: Tue, 06 Apr 93 15:10:32 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: April Viruses? (PC) mikael@vhc.se (Mikael Larsson) writes (about VSUM): > That listing contains info about all know viruses, activation dates, > origin countries etc.. it's quite good. It for sure cannot contain "info about all known viruses", because new viruses appear averagely three per day and it is updated monthly. But this is not the only problem - I have found almost all articles in VSUM to be very inaccurate, incomplete, verbose, and just plain wrong... So, no, I don't agree that it can be considered to be quite good... 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.2 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: Tue, 06 Apr 93 15:18:05 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Unknown little virus? (PC) motreba@mat.torun.edu.pl (Maciej Otreba) writes: > Last time I had virus in my PC. It came from Internet probably with one > from shareware games. Uh, according to my experience, the executables on the net are usually virus-free... In fact, they are even more reliably virus-free than the files on a local BBS, which are known to be more reliably virus-free than the shrink-wrapped software distributed by some companies... :-) > The problem is that teh virus was not detected by any > program. I tried to find it by Scan 100, F-Prot 2.07 and Polish AV program > MkSVir (available at FUNET with on-line translator). This virus caused Scan and F-Prot can find almost even self-spreading nasty that is internationally know and MkSVir probably can find all local Polish nasties (haven't tested a recent version soon, but it seems to be rather good). Chances are that you don't have a virus problem. > Paintbrush, MS Word 2.0 and System Editor. It was probably very small. I > think it took 32 bytes of base memory (difference between memory with and > without virus). There's no way to fit a memory-resident virus into 32 bytes... Several cases of missing 16 bytes of memory are mentioned in the FAQ; I am not sure what exactly can cause 32 bytes of memory to be missing... > I throw it out by formatting HD and setting up system As usual, this is never necessary. > again. My question is: has anyone heard/seen anything about this virus? Is I would bet that the problem has not been caused by a virus. > Which programs in Internet might be infected? None, I guess... 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.2 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: Tue, 06 Apr 93 15:26:58 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Uruguay on PS/2 ref disk (PC) bill.lambdin%acc1bbs@ssr.com (Bill Lambdin) writes: > KL| There is something funny F-Prot has given false alarms on several > KL| different files about Uruguay-virus and when I tried whether it will > KL| really find the Uruguay-virus - it didn't find not at least the sampl > KL| I have - funny. > This is a known bug in F-Prot 2.06. You should upgrade to the 2.07 > revision. Problem is, now F-Prot 2.07 does not detect this virus reliably... :-( On the other side, the virus has never been found in the wild and its author is always sending the samples only directly to the anti-virus researchers... So, maybe it is not worth the effort to detect it, especially having in mind how polymorphic it is... At least not unless somebody uploads it to the virus exchange BBSes... 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.2 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: 05 Apr 93 22:06:00 -0600 From: "Rob Slade" Subject: Numbers and weighting (CVP) PRTAVS2.CVP 930404 "Numbers" and "Weighting" Before going into detail on the specific types of programs, I would like to address some issues which can be applied to reviewing any antiviral software. Aside from the specific efficacy against large numbers, and certain types, of viral programs, there are considerations of "user" aspects of the system in question. This does not relate solely to the chimera of "user-friendliness", but to the fact that a given system is intended not only to be somehow effective against viral programs, and must be used by a "user population" in a given work, social and technical environment. It is very easy to "rank" antiviral software on the basis of how many viral programs or strains that it will identify. It is not quite as easy to assess many other, more important, features. Although there may be more than 2000 different strains of viral programs in the MS-DOS "world" (fewer in the other environments), one percent of that number are likely responsible for ninety nine percent of infections. Thus it is of far greater importance that, for example, one particular antiviral program does not prevent infection by the "Stoned" virus (as of this writing the most common virus), than that it "protects" against literally thousands of others. Thus the choice of a "test suite" is made more difficult than it might be otherwise. Certain programs are very significant in terms of danger of attack, and therefore must hold higher ranking than others. It is not possible to say that any collection of eighty viral programs is better than any collection of ten. If the eighty happen to be all "basement variants" of Jerusalem, that "test suite" is virtually useless. First, a decent antiviral program should deal with variants. Second, "basement variants" have a generally low survival rate "in the wild", and are not likely to be a threat. Third, "basement variants" tend to mutate "non-functional" aspects of viral programs through the insertion of "NOP" codes and the changing of text. The test suite should, however, contain a range of viral programs which are functionally distinct. A good test suite should contain programs from different categories of programs, such as boot sector infectors versus file infectors and "master boot record" infectors versus boot sector infectors. Self-encrypting, polymorphic, stealth, tunneling, multipartite and companion viral programs should all be represented. Some of these programs are very rare "in the wild", and so the value of their inclusion may be questionable. (Indeed, there is some evidence that the more "sophisticated" a virus is, the less likely it is to be "successful".) However, it would be well to test antiviral programs against the known "possible" viral technologies. If at all possible, some rare, or even unknown (ie. you make it up) viral programs should be included in the test suite. The assertion by some software producers that they can catch all "known and unknown" viral programs should never be left unchallenged. copyright Robert M. Slade, 1993 PRTAVS2.CVP 930404 ============== Vancouver ROBERTS@decus.ca | "A modern US Navy cruiser now requires Institute for Robert_Slade@sfu.ca | 26 tons of manuals. This is enough Research into rslade@cue.bc.ca | to affect the vessel's performance." User p1@CyberStore.ca | "New Scientist" article Security Canada V7K 2G6 | on the "paperless office" ------------------------------ End of VIRUS-L Digest [Volume 6 Issue 60] *****************************************