Received: from fidoii.CC.Lehigh.EDU by abacus.hgs.se (5.65c/1.5) id AA26453; Mon, 8 Mar 1993 13:42:56 +0100 Received: from (localhost) by Fidoii.CC.Lehigh.EDU with SMTP id AA24689 (5.67a/IDA-1.5 for ); Mon, 8 Mar 1993 07:13:41 -0500 Date: Mon, 8 Mar 1993 07:13:41 -0500 Message-Id: <9303081215.AA11146@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 #41 Status: RO VIRUS-L Digest Monday, 8 Mar 1993 Volume 6 : Issue 41 Today's Topics: Re: polymorphic a-v stuff anti-virus procedures Re: Sale of Viri Re: Scanners getting bigger and slower Re: Scanners getting bigger and slower WordPerfect Virus? (PC) Re: Central Point Antivirus and Stacker (PC) Re: standardization (PC) Re: PC Magazine on Anti-Virus Software (PC) Re: problems with f-prot's virstop. (PC) Re: viruses that fiddle with CMOS (PC) Re: EXE/COM switch (PC) F-PROT (PC) Partition table viruses (PC) Mutating Engine concerns (PC) Re: standardization (PC) Re: New disinfector for Slow/Zerotime virus. (PC) Re: scanners. (PC) Re: Effect of Form (PC) DBase virus (PC) Michelangelo (PC) 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: 04 Mar 93 10:53:37 +0000 From: duck@nuustak.csir.co.za (Paul Ducklin) Subject: Re: polymorphic a-v stuff Thus spake houle@nmt.edu (Paul Houle): > I think that the polymorphic compiler approach is still >stronger than that of the existing polymorphic engines. It also has >the advantage that it will work fine in operating systems and >environents that don't like self-modifying code. The compiler could You don't need self-modifying code to use polymorphism at install time. All that happens is that the installation script takes what you might call the "canonical" form of the a-v executable and installs it in a randomly permuted form. There'd be nothing "stronger" in a polymorphic compiler. And [surely?] each user would need to use your polymorphic compiler at each installation -- and a full compiler kit is going to be a bit bulkier and more painful than an install utility! Think about it -- most of today's install scripts permute the binaries between original discs and the discs to which they're installing. Ever wondered how Borland C++ 3.x ships on as few [*gasp*] discs as it does? The install discs read a compressed archive and spit out a whole directory tree with grillions of files onto the target disc. Same sort of idea as Vesselin's polymorphic installer... - -- - --..--..--..--..--..--..--..--..--..--..--..--..--..--..--..--..--..--..-- Paul Ducklin duck@nuustak.csir.co.za CSIR Computer Virus Research Lab * Box 395 * Pretoria * 0001 S Africa ------------------------------ Date: 04 Mar 93 10:52:46 +0000 From: duck@nuustak.csir.co.za (Paul Ducklin) Subject: anti-virus procedures Thus spake bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev): >Disclaimer: the opinions expressed below are entirely my own. The >VTC-Hamburg might or might not agree with them. In any case, we do not >want to be accused in starting another virus scare. Ditto with my remarks below [though replace "VTC-Hamburg" above with my employer's name :-)] >1) Get a good, up-to-date scanner and run it at least once. Computer >viruses -do- exist. It is rather unlikely, but one of them might be on >your computer, or on that nifty game your kid just copied from a >friend. We've just finished a clean-up at a client's site. They'd paid for and received an a-v package _months_ ago -- largely, it would seem, because of the hype about Michelangelo last year, which "heightened their awareness" of viruses. Well. The a-v software was in a cupboard [they had bought a corporate licence for a good whack of PCs...], along with the upgrade discs that had arrived by mail in the interim. The cupboard was locked [they were playing safe to prevent piracy, I suppose...]. OK, we dug out the discs and started showing them how to install and protect their site. And guess what? Michelangelo, all _over_ the show. About 1000 infected floppies showed up -- luckily, a week before the "deadline". Moral: you can't be too careful. Moral2: if you've gone to the trouble of getting a-v software, _use_ it. >2) Back-up your data. Don't delay it until you finish that other "more >important job", or it might be too late. Devise a good backup strategy >and follow it strictly. Yes. A trillion [the British sort, which is a _lot_] times Yes. Every time there's a virus scare, and every time we get an escalation in the number of calls for help [including people who _have_ been wiped out by virus onslaught], we get a corresponding escalation in the number of callers with dead or dying drives. Your drive _will_ fail! Moral: back it up now. It can't wait. >5) Try to follow those guidelines during the whole year, not only a >single day. After you get used to them, you'll see that it's not that >difficult at all. Yes. Once again, when a specific virus [eg: Michelangelo] is being hyped in the press, we get a substantial increase in calls for help with other viruses. In other words, people are checking for viruses only when they're panicked into it. Moral: what's worth doing today is worth doing every day [see "Backup" :-)]. - -- - --..--..--..--..--..--..--..--..--..--..--..--..--..--..--..--..--..--..-- Paul Ducklin duck@nuustak.csir.co.za CSIR Computer Virus Research Lab * Box 395 * Pretoria * 0001 S Africa ------------------------------ Date: Fri, 05 Mar 93 19:31:35 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Sale of Viri JDG111@PSUVM.PSU.EDU (Doug) writes: > You are simply mistaken, sir. Distributing virus code to those who want it > is NOT a very wrong thing which should never be done. You are talking about > censorship. Actually, I am talking about precaution, not about censorship. > Virus code is NOT "taboo" except to a few who believe in their > heads that by preventing it from getting out, they will make the problem > disappear. Oh, most of us are more intelligent than you expect... :-) We don't believe that by not distributing viruses we'll make the virus problem disappear. We do, however, believe firmly, that by distributing viruses freely one makes the problem -worse-. > I learned a LOT about viruses - not from reading comp.virus, or Well, maybe you have just not read carefully the articles on comp.virus, or didn't ask the right questions. There are several virus experts reading this newsgroup, who readily answer to all kinds of questions about viruses. I dare to believe that the contents of the newsgroup has educated at least some people about the virus problem. Just reading the FAQ could prove valuable enough. Sorry if it hasn't worked for you. > available. I used to be paranoid about viruses, simply because I didn't > understand them. I no longer am. Unfortunately, there are many who don't > understand them. If we educate these people, viruses will no longer be the > fearful things they are. Education about viruses alone is not a silver bullet, as you seem to imply in the above paragraph, but I agree with you that it is important to educate the people about the problem - this always helps to some extent to reduce the problem. However, this can always be done without distributing virus code. The regular readers of this newsgroup know that I am trying to answer any kinds of questions and to explain every technical detail that it not clear enough. Yet, I have never felt the need to publish virus code, in order to explain to some of the readers what exactly the viruses are and how they work. Maybe those who insist that publishing virus code is necessary for user education about viruses just do not command their own language well enough to communicate that information in simple words... > You are correct in saying that not everyone is > compitant enough to handle viruses. I will not disagree. but there are > PLENTY of people who are MORE than compitant enough, but are still "not > allowed" to handle them, because they "could do evil things" with them. You Problem is, from my point of view, I am not able to evaluate (a) how competent exactly you are (I've seen even experts doing silly things when dealing with viruses) and (b) that your purposes are legitimate. Look, I -want- to believe you, but I have no way to know it for sure, thus I simply refuse to take the (unnecessary) risk. > are telling ME, and the rest of us, that we are not as knowledgeable about > virus code as you are, therefore we may not have it, but you can. This could be put in a slightly different way: I have no way to determine that you, and the rest of you, are as knowledgeable about virus code as it is necessary, therefore, I refuse to take the responsibility to give virus code to you. Besides, if you are so knowledgeable, why do you need the virus code in the first place? > I don't like that. I'm afraid that it won't help... :-) > Nor do a lot of others. I'm afraid that it won't help either... :-)) > You may personally censor all the > information you want, but there are plenty of others who are willing to > share. Well, that's exactly what I am doing. So, what's your problem, then? > You're fooling yourself if you think keeping the general public > ignorant will help them. But I don't think so! Just the opposite, I am always willing to explain what the different viruses do, what can be done against it, and so on. By no means I am keeping the general public ignorant. Actually, some people are accusing me for being too open... However, I do keep the viruses themselves from the general public... And the general public from the virus code... :-) > That will only help line the pockets of the > anti-virus software publishers. (Which may well be what you're shooting > for) A heavy-sounding and pompous phrase, but completely unfounded. You probably don't know me well, otherwise you would know that I do not sell any anti-virus program, a few utilities I've written are available for free, and people do not pay me consultation fee when I am answering their questions... In fact, I am taking your suggestion as an insult. > The "censor it and it'll fix it" attitude is not that of everyone. As I wrote above, my attitude is more exactly "don't censor it and the problem will become worse". > Thank God there are still those who > believe in TRUE education, and not the idea that "ignorance is bliss". Maybe we just happen to have different understanding of what true education is? And, if the people that you mean are those running virus exchange BBSes - well, I don't see them to be (a) knowledgeable (gosh, most "virus collections" on them are such a horrible mess... Those people can't tell CHKDSK from a virus...), or (b) very helpful and effective to reduce the problem. Just the opposite - because of them every scanner must bother to check for obscure viruses that have never been found in the wild, but are present on those BBSes, so any malevolent person could download them and infect somebody's machine... What a valuable contribution to the society, isn't it? And how it helps to "educate" those people who have urgent work to do and don't want to bother to convert their machine into the electronic equivalent of Fort Knox... 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: 06 Mar 93 16:43:11 +0000 From: frisk@complex.is (Fridrik Skulason) Subject: Re: Scanners getting bigger and slower Inbar_Raz@f210.n9721.z9.virnet.bad.se (Inbar Raz) writes: >You know, Vesselin, I thought of a different approach to be used, when the day >comes that there would be too many viruses. >Instead of having one big huge turtle speed scanner, you would have, say, 4 >scanners. So what ? Remember - for any decent scanner the speed does (almost) not depend on the number of viruses. Creating 4 scanners will simly mean that the time will increase by a factor of 4, if you ran them all - and any one of them would be of the same speed as the original one. Remember, not all scanners are turtles... - -frisk - -- Fridrik Skulason Frisk Software International phone: +354-1-694749 Author of F-PROT E-mail: frisk@complex.is fax: +354-1-28801 ------------------------------ Date: Sat, 06 Mar 93 20:37:51 +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: > You know, Vesselin, I thought of a different approach to be used, when the day > comes that there would be too many viruses. > Instead of having one big huge turtle speed scanner, you would have, say, 4 > scanners. > One for stealths, one for common viruses, one for encryptive and one for rare. > Thus, you would use them in different frequencies, and each would run faster > and better. This is not very convenient from the user's point of view... But the idea could be changed a bit to achieve practically the same thing - there could be one scanner, with many overlays. The users will be able to select how "secure" they want their scanner to be, thus selecting which of the overlays will be executed during the scanning process. However, the differentiation does not to be by stealth/encrypted/etc. it only needs to be based on how common the viruses are. This will be much like the today's option in many scanners for "secure"/"turbo" scanning mode, the former usually meaning that the whole file is scanned, while the latter means that only those places of the files are checked, where a virus is likely to be present. 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: Thu, 04 Mar 93 19:51:03 -0500 From: Michael_Kessler.Hum@mailgate.sfsu.edu Subject: WordPerfect Virus? (PC) Like Gerry Santoro, I also am getting seeing strange behavior on WordPerfect. In this case, running on a 3+Share LAN with a Zenith 386SX/20 station, the text was replaced by random characters. The cursor freezes and the only soIution is a cold reboot with a complete loss of text (the backup was blank). Is this a WordPerfect problem? F-PROT 2.07 did not find anything. Michael_Kessler@HUM.SFSU.EDU ------------------------------ Date: Fri, 05 Mar 93 03:12:52 +0000 From: troj@cwis.unomaha.edu (Kevin Trojanowski) Subject: Re: Central Point Antivirus and Stacker (PC) Amir_Netiv@f120.n9721.z9.virnet.bad.se (Amir Netiv) writes: >Hi. >You write: > > I use stacker, and recently have begun Internet, etc. >more... > > Are Central Point Antivirus and Stacker compatible? >Well: I truely recommend NOT to optimize your disk too frequently, and >make frequent backup for ALL the DATA on your disk BEFORE using the >TSR parts of that Anti Virus. Remember that stacker (or any other >disk doubler) uses the DOS environment to do what ever it is doing, >and so does Anti Virus TSRs (especially those that use many interrupt >monitoring). A conflict might be fatal (generally speaking). I can attest to the fact that F-Prot & Stacker coexist just dandy. I've been using the two of them together for about a year now, and haven't run into any problems. Don't know 'bout CPAV, though -- I've never tried it. Why pay such a large amount of money, when I can get a product which I consider superior for free? - ------------------------------------------------------------------------------- - - "She had what it took: great hair, a - - - Kevin Trojanowski profound understanding of strategic lip - - - Internet: troj@cwis.unomaha.edu gloss, the intelligence to understand - - - CI$: 70521,312 the world and a tiny secret interior - - - US Snail: 1905 Thurston Ave, #8 deadness which meant she didn't care." - - - Bellevue, NE 68005 -Douglas Adams - - - _Mostly Harmless_ - - ------------------------------------------------------------------------------- ------------------------------ Date: Fri, 05 Mar 93 06:02:27 +0000 From: 007 Subject: Re: standardization (PC) Amir_Netiv@f120.n9721.z9.virnet.bad.se (Amir Netiv) writes: > > bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) writes: > > > First, somebody has to come up with a good naming > > scheme. But what is a "good" naming scheme? For instance, for me, a good > > naming scheme is a scheme that allows two people to understand each > > other that they are talking about a particular virus variant. That is, > > when I'm saying Jerusalem.AntiCAD.4096.Mozart, Frisk knows what I > > mean. > >I would differentiate the interests of Virus researchers from this of >the common user. You would very much like to have a scanner that >supplies the NAME the full CHAIN of parrential viruses and sub viruses >etc... while the common user's only wish would be to know what desease >he has, and ger cured! Suppose you tell a user: "You have the >Parkinson.AtzeliCholine.Flue desease" (not that such exists), what do >you think his/her reaction will be? I suggest that an ambulance will >be on stendby when breaking the news to such a patient. I agree that CARO names tend to be somewhat unwieldly for "general" reporting, which is part of the reason I suggested to frisk a /CARO command-line switch rather than ALWAYS including them. Perhaps only the tail end of the CARO name could be used by default? For example, report Jerusalem.AntiCAD.4096.Mozart as "Mozart". If ambiguity results, back up the chain until it is unambiguous. Another possibility would be to limit reported names to a certain number of characters. I agree that seeing "Dark_Avenger.2000.Traveller.Zopy" pop up on the screen while scanning could panic out an unsuspecting individual. Reporting this virus as "Rocko" seems a bit TOO brief. Viruses with shorter names like Cascade.1704.A should be reported in full, as this seems short enough not to cause a panic. The users that I have worked with tend to be rather curious about the viruses they find. The first question I get right after "Which one was it?" is typically "What does it do?" Without proper identification of the virus I can't answer this fully. Fortunately, with F-prot answering this question is pretty easy, but it would be nice to give more details. > > But the producer of product XYZ does not like it, because it > > takes too much memory in its resident scanner to keep such long > > names. Anyway, >What is the purpose of telling the virus name in a TSR. Is it not >enough to tell the user "You've got a problem, Check it !" ? I tend to agree. A TSR scanner need not have super-precise identification. Just giving the family should be plenty. (I.e. "Jerusalem" or "Dark_Avenger".) Save the down and dirty identification for the non-TSR scanners. > > The second problem is that different producers of > > virus scanners use different approaches to scan for viruses. >....... > > the scanner ZYX, who calls all the 200 Jerusalem subvariants > > "Jerusalem-B". So, obviously, he is not likely to adopt this naming > > scheme. >Do you think its a wise idea to give aname to each variant of Jerusalem (from >the example that you used) a name of its one? This is why the CARO standard uses the heirarchical format. It is easy to add variants to a base name. >Do you know how manny variant of >the virus exist that you don't even know about? Another reason for using a standard. Without a standard and careful checking a potentially harmful variant can get mis-identified as a less harmful parent virus, take Stoned and Michelangelo for instance. >Doeas it cause any problem in >cleaning these viruses from an infected site even if their name is simply " >Jerusalem-B" ? People tend to want to know what the virus does, so they can be on the lookout for the future, or just out of curiosity. For example, if a person just recovered from a massive infection of Jerusalem, they might notice that some of their executables keep growing and growing earlier than if they had no idea what the virus did. People tend to be curious, perhaps in a large office workplace a busy boss might just want to get the damn things out, but people at home might want to learn a bit more about what their new "friend" is capable of. Proper ID is essential for this. >I think there is already a naming scheame present. >It gose like this: >McAfee gets a virus, Releases the next VIRLIST.TXT, and >everyone just uses it. If a new virus apears that is not >there, a name is given to it according to its behaviour, >and so on... Yes, and if he doesn't like the name, he changes it. This way nobody really knows exactly what they have. :( I certainly wouldn't consider the information in VIRLIST.TXT anything more than decorative. It is close to impossible to cross-reference to any substantial information list. It does cross reference to VSUM pretty well, but I wouldn't trust the information in VSUM as far as I could spit it. But I've discussed that enough... ;-> I also wouldn't say that "everyone" uses McAfee's VIRLIST.TXT. :-) -- 007 - -- 000 000 7777 | sbonds@jarthur.claremont.edu 0 0 0 0 7 |----------------------------------------------------------- 0 0 0 0 7 | Childhood is short... 000 000 7 | ...but immaturity is forever. ------------------------------ Date: 05 Mar 93 07:43:54 +0000 From: frisk@complex.is (Fridrik Skulason) Subject: Re: PC Magazine on Anti-Virus Software (PC) smd@hrt216.brooks.af.mil (Sten M. Drescher) writes: > Fridrik> Well, they did not want to include any shareware programs at > Fridrik> all (quite silly, because they are the most popular ones) - > Fridrik> therefore no SCAN, and F-PROT only got included because we > Fridrik> have an expanded, commercial version available. I am not > Incorrect - McAfee was represented by an expanded, commercial >version called Pro-Scan. What do you mean by "incorrect" ? I said "no SCAN", not "No McAfee software"... > Fridrik> Anyhow, I wrote them a 4-page letter about this... > I hope that they have the balls to print an accurate portion of >your letter. Well, my letter was not intended for publication - it included some suggestions if they should ever decide to do another anti-virus review. - -frisk - -- Fridrik Skulason Frisk Software International phone: +354-1-694749 Author of F-PROT E-mail: frisk@complex.is fax: +354-1-28801 ------------------------------ Date: 05 Mar 93 07:46:23 +0000 From: frisk@complex.is (Fridrik Skulason) Subject: Re: problems with f-prot's virstop. (PC) TAWED@etsu.bitnet (ed) writes: >Here is a common problem that I have detected with f-prots virstop... >When a program loads and virstop finds a virus it doesn't remove that program >from memory and thus leads to further infection unless rebooted.. Huh ? You are misunderstanding something. When Virstop finds a virus, it STOPS the virus - it is never executed, and therefore it cannot "lead to further infection". The virus code may be read into memory, of course - Virstop has to read parts of the file, in order to perform a scan, but the code is inactive. - -frisk - -- Fridrik Skulason Frisk Software International phone: +354-1-694749 Author of F-PROT E-mail: frisk@complex.is fax: +354-1-28801 ------------------------------ Date: 04 Mar 93 10:51:54 +0000 From: duck@nuustak.csir.co.za (Paul Ducklin) Subject: Re: viruses that fiddle with CMOS (PC) Thus spake cjkuo@symantec.com (Jimmy Kuo): >Many viruses fiddle with CMOS bits, some fiddle with it >incorrectly and corrupt certain values. But none that I >am aware of deliberately go and reset all the CMOS values. Anticad? That's fairly deliberate! And fairly complete! Payload [I prefer Roger Riordan's term "warhead", actually, as payloads aren't inherently hideous, unlike warheads...] includes writing 0xFF all over the 64 "compatible" bytes of the CMOS RAM. This virus family was pretty widespread in South Africa at one time -- which is where my knowledge of the CMOS RAM map comes from :-) - -- - --..--..--..--..--..--..--..--..--..--..--..--..--..--..--..--..--..--..-- Paul Ducklin duck@nuustak.csir.co.za CSIR Computer Virus Research Lab * Box 395 * Pretoria * 0001 S Africa ------------------------------ Date: 04 Mar 93 11:02:03 +0000 From: duck@nuustak.csir.co.za (Paul Ducklin) Subject: Re: EXE/COM switch (PC) >> I will also leave it to an enterprising individual to >> determine wither COMMAND.COM will run if it is renamed >> to COMMAND.EXE (with the appropriate change to the COMSPEC >> variable in CONFIG.SYS). Personally, I doubt it, but >No need to doubt it - DOS can run just anything as a command >interpreter, if you put the appropriate line in CONFIG.SYS. Quite true. Interestingly, the COMMAND.COM which comes with Digital Research's DR-DOS 6.0 is an .EXE file -- but I suppose that they realised people are _very_ used to the file called "commandcom" and that COMMAND.EXE would be a stressful culture change! - -- - --..--..--..--..--..--..--..--..--..--..--..--..--..--..--..--..--..--..-- Paul Ducklin duck@nuustak.csir.co.za CSIR Computer Virus Research Lab * Box 395 * Pretoria * 0001 S Africa ------------------------------ Date: Fri, 05 Mar 93 09:49:18 -0500 From: "Marie-Andr\e Giroux" Subject: F-PROT (PC) Hi! I need some information about VIRSTOP from F-Prot. That program is suppose to let you know if a virus is trying to do some dammage on your disk. I was reported to me that VIRSTOP 2.07 did not detect the presence of the Monkey virus. If anyone has experienced such a problem let me know about it or of any solution to it. Thank you Marie-ANdree Giroux ------------------------------ Date: 05 Mar 93 17:20:52 From: sarel@ford.ford.ee.up.ac.za (Sarel Lugtenburg) Subject: Partition table viruses (PC) We had just an outbreak of a virus that infects the partition table. It trigger on any date in March. Reformatting the hard disk and running fdisk, changing everything, has no effect. You have to low level format the harddisc (IDE). I was always under the impression that a high level format from a clean , booted floppy would be enough but this is apparently not so. Can someone tell me what happens during the whole boot process from poweron. Where does this virus get into the chain of the bootup sequence ? - -- - --------------------------------------------------------------------------- | Sarel P. Lugtenburg | "I wish to God these calculations | | Tel : (+27-12) 420-2983 | had been executed by steam" | | Fax : (+27-12) 420-2983 | - Charles Babbage, 1821 | ------------------------------ Date: Fri, 05 Mar 93 15:38:49 +0000 From: exucad@exu.ericsson.se (Charles Dobbins) Subject: Mutating Engine concerns (PC) I am curious if any of the experts out there can help me out here. I am concerned about the possibility of getting hit with one of these with our current level of protection, we are installing NAV 2.1 after using Certus for some time with constant problems with virus infections. A big concern for us is memory at the wotkstation since we are running Lanman 2.1 there isn't room for some of the larger TSR's that seem to offer better protection against unknown virus technology. At this point we cannot consider a different antivirus product at the workstation due to the fact that money has already been spent on NAV so what I am concerned about is what sort of threat to the mutating engine type virus pose at this point? We are always getting the usual collection such as Yankee Doodle,Dark Avenger,Stoned, Liberty and Michelangelo. Our company has alot of data being moved around on floppies which cannot be changed so I am a bit concerned since we definatly have seen that they get brought in on a regular basis. Any help in this area would be greatly appreciated. Charles - ------------------------------------------------------------------------------ Charles Dobbins Ericsson Network Systems, Inc Systems Programmer P.O. Box 833875 Richardson, TX 75083-3875 (214) 997-0982 - ------------------------------------------------------------------------------ ------------------------------ Date: Fri, 05 Mar 93 19:32:30 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: standardization (PC) Inbar_Raz@f210.n9721.z9.virnet.bad.se (Inbar Raz) writes: > lot of ways. For example, a protective shield that is mounted on a file. True, > it's effective only against the normal end-of-file-leaching viruses, but still > a lot of them DO work like that, including the new ones. It will actually work with almost any non-stealth file infector. Nevertheless, attaching integrity modules to the executable files is not a good idea. First of all, there are files to which you must not attach anything, or they will break. Such files include Windows applications, EXE files with internal overlay structure, very big COM files, programs, containing debugging information (e.g., symbol tables), and so on. It is much better to store the information about those files in an external database and run an external program to check it. > Making CRC checks from a BOOTING FLOPPY will also catch ANY virus, provided it > hasn't infected your floppy yet. Unfortunately, this is not true. There are lots of issues that have still to be considered, like implementing the CRC correctly (if you use a fixed algorithm, a virus could forge it), like taking into account the possible virus attacks against integrity programs (described in my paper; plug), and so on. You should be EXTREMELY careful, when speaking about catching ANY virus... > > Yet there are programs that detects new viruses while attempting to > > execute (such is IRIS's TSR module, and some optional McAfee's VSHIELD > > functions, and there are others...) Our software for example, will > > detect new viruses, and even eliminate them while they are completelly > > unknown to the program. > The problem with TSRs is, that as simple as they are to INSTALL resident, they > are also easy do remove from memory. I think you are talking about different things there. The original poster seems to refer to resident scanners (unless I'm mistaken). Resident scanners can catch KNOWN viruses before those viruses get any chance to run, so obviously they won't be able to remove the scanner from memory. Of course, if it is a new virus, the scanner will not detect it (if it is only a scanner), but then it is useless for the virus to remove the scanner from memory - it doesn't stop the virus anyway, so why bother? > The moment a virus writer acquires your module, he can write a relatively > small piece of code that will unload your TSR, without it knowing about it. > A friend of mine once wrote an 80byte routine to unload Carmel's TSafe. I 80 bytes? So many? :-) Well, I don't remember what exactly the program did when it used to be called "TNTVIRUS", but VSafe that comes with CPAV can be removed from memory with just 8 bytes of code... :-( 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, 05 Mar 93 19:35:18 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: New disinfector for Slow/Zerotime virus. (PC) EM436861@ITESMVF1.RZS.ITESM.MX (Mario Rodriguez (virus researcher)) writes: > Hello, I'm a virus researcher of Mexico. I made a disinfector for Slow/Zerotim > virus. This virus seems to have striked in Australia. The disinfcetor is name > NOSLOW v1.0 and is available to any one who ask for it via direct mail. > I uploaded it garbo.uwasa.fi but I think it would take to much to become a > ailable in there. I aslo send it to a some of the main researchers, so it's po > sible that soon their vacsines will detect and remove the virus too. > Unfortunately, NOSLOW only removes the virus from .COM files. .EXE files a > e renamed to .VIR. What is the problem with the EXE files? This virus is a Jerusalem variant and it simply appends itself to the EXE files... Disinfecting them shouldn't be a problem, except that the file size might remain up to 15 bytes bigger than the original... But, anyway, why re-inventing the wheel? There are already several anti-virus programs which are able to disinfect both types of files from this virus... I just made a quick test of F-Prot 2.07, CLEAN 102, and FindVirus 6.15. Here are the results. First of all, there are several closely related variants of this virus. Those of them that I know are: (1) Jerusalem.Zerotime.Australian.A (2) Jerusalem.Zerotime.Australian.B (3) Jerusalem.Scot's_Valley Virus #: F-Prot: CLEAN: FindVirus: - -------- ------- ------ ---------- (1).COM Disinfects Disinfects Does not disinfect (1).EXE Disinfects Disinfects Does not disinfect (2).COM Does not disinfect Does not recognize Does not disinfect (3).COM Disinfects Does not disinfect Does not disinfect (3).EXE Disinfects Does not disinfect Does not disinfect As usual, F-Prot is best in disinfecting viruses, while FindVirus provides exact identification. CLEAN calls the virus (1) "Slow [Slow]" and the virus (3) "Scott's [2133]". It doesn't detect at all the virus (2), F-Prot calls it "New variant of Zerotime", and FindVirus calls it "TPE" (?!). 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, 05 Mar 93 19:36:18 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: scanners. (PC) Amir_Netiv@f120.n9721.z9.virnet.bad.se (Amir Netiv) writes: > > when I'm saying Jerusalem.AntiCAD.4096.Mozart, Frisk knows what I > > mean. > I would differentiate the interests of Virus researchers from this of > the common user. Don't be so quick to underestimate the interests of the common user. When this user asks for assistance, it is not very helpful if he tells you "The product XYZ found the Generic Boot virus on my machine. How to remove this virus and what the hell does it do?"... I agree that the two most important questions for the user are "Am I infected?" and "If I am, how to get rid of it?", but the third most important question is "What has it done to my data?"... If it were not like that, everybody would use an integrity checker, instead of scanners - the integrity checker tells you that you are infected, and often can repair the infection, but is unable to identify the virus and to tell you what else to expect... > You would very much like to have a scanner that > supplies the NAME the full CHAIN of parrential viruses and sub viruses > etc... while the common user's only wish would be to know what desease > he has, and ger cured! Yes, that's it! S/he wants to know -what- disease s/he has - what exactly. I do not claim that a full genealogic name must be supplied - but the name must be -unique- and -exact-. When designing the CARO naming scheme we found helpful to group the viruses according to their code similarities. This grouping is reflected in the full CARO name of a virus. Of course, you don't need to specify the full name each time, it is enough to use a part that identifies a virus uniquely. For instance, you can say just Mummy.1_2, if you know that this virus is part of the Jerusalem family. The full path is needed only when communicating the information to somebody else who does not have this knowledge (maybe he has not heard about the Mummy viruses at all). So, by telling him that you are talking about Jerusalem.Mummy.1_2, you are communicating not only information sufficient to identify the virus in the naming hierarchy - you are also telling him that the virus is part of the Jerusalem family (thus, might infect files in a similar way), that it has several variants (this particular one is 1_2) and so on. Consider the alternative to just telling him that you are talking about the "Mummy" virus. Which Mummy? What does it do?... > What is the purpose of telling the virus name in a TSR. Is it not > enough to tell the user "You've got a problem, Check it !" ? Alas, it isn't. Most users insist in obtaining the information instantly, NOW!, when the virus is about to infect their machine. They don't like the idea to spend a few minutes in powering down the machine, running an off-line scanner that takes 3 minutes just to check itself, and so on... > > the scanner ZYX, who calls all the 200 Jerusalem subvariants > > "Jerusalem-B". So, obviously, he is not likely to adopt this naming > > scheme. > Do you think its a wise idea to give aname to each variant of Jerusalem (from > the example that you used) a name of its one? Yes, definitively. > Do you know how manny variant of > the virus exist that you don't even know about? How many? Usually, when a new variant appears, we learn about it pretty quickly... Gosh, we receive averagely several new viruses every day... And, if we don't know about some obscure variant, then the scanner won't catch it (the scanners catch only known viruses), so no need to bother about the fact that the virus is not yet named... > Doeas it cause any problem in > cleaning these viruses from an infected site even if their name is simply " > Jerusalem-B" ? Yes, it does. A lot. The different variants are, unfortunately, er... different. :-) You cannot remove them in exactly one and the same way. And, removing the wrong variant can be (and often is) disastrous! Of course, we keep saying that infected files shouldn't be disinfected, but replaced with clean copies instead, however, the users keep using disinfection programs... For that purpose, we need exact identification. Besides, people often use more than one anti-virus product. If two products report two different names, this enforces the general confusion. Sometimes it is even worse - one product reports more than one virus when only one is present... And so on... > It is our responsibility (SCANNERs developers) to make sure that a virus is > cleaned or detected. No matter if you call it "Poteto" and we call it "Potato " > (phonetically expressed) as long as the cleaning procedure is working well. Then, according to your logic, why don't you call all of them just "Virus"? Why do you still use names (and many different ones) in your scanner? Problem is, the users want to know -what- is on their system. You cannot just tell them "This seems to be one of the many Jerusalem variants" - they want to know whether it will delete files on Friday the 13th, or will format the disk in year 2000, or whatever. > I think there is already a naming scheame present. > It gose like this: > McAfee gets a virus, Releases the next VIRLIST.TXT, and > everyone just uses it. Argh, you used a bad example... First, there are many names in VIRLIST.TXT that SCAN never reports - they are left there from previous versions. Second, there are many names that SCAN reports, but which are not in VIRLIST.TXT. Third, there are many different viruses that SCAN reports with one and the same name (e.g., both Number_of_the_Beast and Compiler.1 are reported as "512 [512]"). Fourth, there are many closely related viruses that SCAN reports with completely different names. Fifth, for many viruses SCAN reports more than one virus in the infected file, while only one is present. Naw, I wouldn't use VIRLIST.TXT as a reliable reference for virus names... > If a new virus appears that is not > there, a name is given to it according to its behaviour, > and so on... How nice and simple, isn't it? I begin to wonder - how often do you receive new viruses? There are dozens that do just nothing particular, except replicate! How do you pick a name for them? A numeric name is not good, because people have difficulties remembering numeric names... We used to name them after trees, after fishes, after the first object we could think about, after the secretary's dog, after.... But with a dozen or so new viruses every week your fantasy begins to exhaust itself... 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: Sat, 06 Mar 93 13:55:59 +0000 From: adb91pbe@hfb-aes.hfb.se (Pontus Berglund) Subject: Re: Effect of Form (PC) >> This brings me to my next qestion: I it possible to obtain a file >> somewhere giving a brief description of the action of various vira. I > > How about 300K of ZIP ? :-) Where do I get this file? - -- [Pontus begin 644 sig F"BTM(%-E>"!I2!O;FQY(&EF(&1O;F4@ +64 (6) 357-9245 New Zealand "A wet and windy place in the South Pacific" ------------------------------ Date: Sat, 06 Mar 93 16:43:32 +0000 From: d91-cni@nada.kth.se (Christer Nilsson) Subject: Michelangelo (PC) A friend of mine couldn't boot his computer today (6:th of March). Could it be the Michelangelo Virus? An inspection of the first sectors of the disk showed that they were completly blank. Does Michelangelo behave in that way? The partition of the drive was wiped away. How do one recover the information on the disk? Funny note 1: This morning they talked about the Michelangelo virus on the news on national Swedish radio. Exactly at the same point, my friends father booted his computer and got the shock! Funny note 1: My friends father is a high-school teacher in computer science. Right now he's probably glad that no computers are run in school on saturdays! Me on the other hand, regularly uses av-toolkits... - -- - ----------------------------------------------------------------------------- Christer Nilsson, CS at The Royal Institute of Technology, Stockholm, Sweden -The reason it`s a cliche is because it`s true.- - ----------------------------------------------------------------------------- ------------------------------ End of VIRUS-L Digest [Volume 6 Issue 41] *****************************************