From abacus.hgs.se!mikael Sun Mar 28 02:34:52 1993 remote from vhc Received: by vhc.se (1.65/waf) via UUCP; Sun, 28 Mar 93 01:37:15 GMT for mikael Received: from Abacus.HGS.SE by mail.swip.net (5.65c8-/1.2) id AA27714; Sun, 28 Mar 1993 01:35:03 +0100 Received: by abacus.hgs.se (5.65c/1.5) id AA04467; Sun, 28 Mar 1993 01:34:52 +0100 Date: Sun, 28 Mar 1993 01:34:52 +0100 From: Mikael Larsson Message-Id: <199303280034.AA04467@abacus.hgs.se> To: mikael@vhc.se VIRUS-L Digest Thursday, 25 Mar 1993 Volume 6 : Issue 49 Today's Topics: Legal Net Monthly Newsletter (All) Mixed IBM & MAC LANs Re: Results of updated MtE tests (PC) Re: Looking for OPCODE lists (PC) WordPerfect File growth etc. (PC) scanners. (PC) Michelangelo (PC) Ignorance is curable (mostly PC) Central Point and Stacker (PC) Virus signature determination. (PC) Re: Virus that infects while Scanning? (PC) virus-map (PC) Re: EXE/COM switch (PC) Singaporean car dealers & Mike (PC) VirusCheck 3.0 looking for Beta testers (PC) Catch from DIR? (PC) michelangelo (PC) michelangelo (PC) Re: Partition table virus (PC) McAfee's Clean-output (PC) Virus Catalog update/New VirusBase 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: Tue, 23 Mar 93 15:21:07 -0500 >From: fergp@sytex.com (Paul Ferguson) Subject: Legal Net Monthly Newsletter (All) Opinion, editorial and news worthy submissions are currently being (sought and) accepted for a new start-up electronic news journal. This monthly compilation will be called 'The Legal Net Monthly Newsletter' and will focus on the legal and ethical aspects of computer networking. Legal Net Monthly will be a non-biased, open forum electronic newsletter keeping in step with the networking environment of the '90's and will be availble by E-Mail subscription. Legal Net Monthly is aiming to release it's first issue on May 1st, 1993. Articles on the following topics are especially welcome: o Defining "Criminal Mischief" on the Nets o Authoring/Distributing Computer Viruses: Legal Implications o Legislative news around the world Send all sumissions, subscription requests and correspondence to: fergp@sytex.com 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, 23 Mar 93 17:39:32 -0500 >From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) Subject: Mixed IBM & MAC LANs While "cross-polinating" viruses have not appeared as yet (and are difficult to write), such a client/server network can spread viruses very quickly among homogeneous clients unless precautions are taken. Further, while "first-generation" anti-virus programs exist for the Novell Netware/IBM environment, I know of no such top-level defense for MACs. As a result, and since MACs will only access MAC software (except for DOS boxes) and IBMs will access only IBM software, if anything, the mixed nature of such a heterogeneos system makes it *more* likely to become infected by a virus than a single platform system, and less likely to have a proper defense. Artisoft LANTASTIC was also mentioned (have 4.1 but not 5.0 - yet) and it shares the limitation of any peer-peer network in not having login scripting capacity & such is yet another step down from client/ server in robustness. I do not know of any heterogeneous peer-peer LANs as yet though daya sharing is certainly possible. Warmly, Padgett ------------------------------ Date: Mon, 22 Mar 93 12:31:48 +0000 >From: v902565@gerhardt.si.hhs.nl (Zwienenberg) Subject: Re: Results of updated MtE tests (PC) brunnstein@rz.informatik.uni-hamburg.dbp.de writes: |> As material for my lecture on "Methods and Requirements for Quality Assuranc e |> of AntiVirus Products" in 6th International Computer Security and Virus Conf e- |> rence" (New York, March 11-12, 1993), Vesselin Bontchev kindly repeated the |> MtE tests published in Virus-L last year. Here are the major changes: |> |> In November 1992, CATCH-MTE 1.5, F-PROT 2.05, FINDVIRU 6.01 |> and VirScan 2.2.3A detected *all* instances (2000 each) |> of CoffeeShop, Cryptlab, Dedicated, Fear, Groove/EXE, |> Groove/COM, Pogue and Questo. |> |> On March 7, 1993, CATCH-MTE 1.8, F-PROT 2.06a, FINDVIRU 6.10, |> and VIRSCAN 2.2.3A |> AS WELL AS: HTScan 1.19, PC Vaccine Professional 1.13, |> SCAN V100 and TBScan 4.3 detect *all* |> (8*2000) instances on the same testbase. |> |> Moreover, VirX 2.6d detects *all instances but 1 Pog ue |> This significant improvement in recognition quality of AV products may be re |> garded as a result of the public discussion on test results published (and |> somehow controversially discussed) last year by VesselinBontchev. VTC plans |> to update it's procedure to also test recognition of 8 new MtE-based viruses. Of course, a good thing to keep this going, but what about TPE detection? The just released 1.14 version of our product PCVP detects the TPE as well as the next TBSCAN. I think that now almost all packages do detect the MtE, people will start to use TPE (and future engines) as it is stupid to use a mutation engine which already is detected by the majortity of scanners. [RiZwi] Computer Security Engineers Ltd R&D P.O. Box 45610 2504 BA The Hague The Netherlands +31-70-3622269 (voice) +31-70-3652286 (fax) ------------------------------ Date: 22 Mar 93 13:55:54 +0000 >From: alan@saturn.cs.swin.OZ.AU (Alan Christiansen) Subject: Re: Looking for OPCODE lists (PC) chowes@sfu.ca (Charles Howes) writes: >Someone recently mentioned 'serializing' an executable program by using >alternate opcodes as binary ones, to the regular opcodes' zero. >That was in comp.security or alt.security. >I thought 'Hey, the folks in comp.virus know a lot of this technical stuff, >I'll ask them!'. This could also be tied in to the earlier discussion of >polymorphic viruses, if necessary. >My question: > What are some opcodes that have two possible numeric values? > This is for the 80x86 family of machines. >(I want to serialize software, not write viruses, polymorphic or otherwise.) All the XCHNG R,R should be suitable There are a number of CMP AL,#immediate type instructions that have one and 2 byte versions. so th one byte version and a NOP should be swappable with the 2 byte version. Jmp short NOP and Jmp dd where dd and d are signed displacements can be inter changed etc >Thank you! >Charles Howes -- chowes@sfu.ca ------------------------------ Date: Mon, 22 Mar 93 12:18:52 -0500 >From: Brian Seborg Subject: WordPerfect File growth etc. (PC) I have seen the same problem with WordPerfect file growth in a Banyan environment. We have traced it to users exiting WordPerfect abnormally. Meaning that they either use cntrl-alt-delete to exit, or they turn off their machines while still in WordPerfect. This causes WordPerfect to create a huge file sometimes in excess of available disk space. The only way to prevent this from happening is to educate your users not to abnormally exit from WordPerfect. This is a known bug by WordPerfect, I imagine that they will address it in the next release if enough people complain. Regarding a comment that Richard Ford made about using FDISK or SYS while a virus is memory resident. It is not always the case that this will cause the disk to be re-infected if the system has booting from the floppy disabled. In fact, several viruses can successfully be eradicated using this technique although it is not advised. The reason for this is simple. Many viruses like the Michelangelo will perform an "are you there call" before attempting to infect the MBR. If they find that they are there in memory already, then they assume that they have already infected the MBR and no longer need to do this. Therefore, if you replace the MBR with these type of viruses in memory and then shut down the machine and reboot you should come up clean. Again, this is not true for all MBR viruses, but it is true for some like the Michel- angelo. Brian Seborg VDS Advanced Research Group (Makers of VDS Pro 1.0 and CatchMtE) ------------------------------ Date: Fri, 19 Mar 93 10:55:13 +0100 >From: Malte_Eppert@f6051.n491.z9.virnet.bad.se (Malte Eppert) Subject: scanners. (PC) Hi Inbar! > I see what you mean. I thought 'slow' only refered as to the > speed of the damage the virus causes. Can you think of an idea > (or is there one already) to bypass this? I'm sorry I don't know of one. Maybe Vesselin does, he has more practice than me :-) >> The DOS file fragmentation, a theoretically possible infection described > But still. If the virus DOES manipulate things, those > manipulations should be caught, no? > the fat or not, eventually one of the files' clusters won't be > the same, and I should catch that. You can't by normal, file-based means... The DOS image of the file is the same as before, while the physical image, which is relevant at boot time, has changed :-(. cu! eppi - --- GEcho 1.00 * Origin: No Point for Viruses - Eppi's Point (9:491/6051) ------------------------------ Date: Fri, 19 Mar 93 00:34:06 +0100 >From: Chris_Franzen@f3020.n491.z9.virnet.bad.se (Chris Franzen) Subject: Michelangelo (PC) > Hi Vesselin! >> BTW, I am very curious how many Michelangelo hits have happened >> this year... > I know about at least two. One in Braunschweig, another one in the > Vechta area, both Northern Germany. Oh come on. There is NO town in Germany where Mich could not be found. > cu! > eppi Chris, The Blast I - --- GEcho 1.00/beta+ * Origin: You wanted junk -- so I drop some. (9:491/3020) ------------------------------ Date: Mon, 22 Mar 93 12:51:00 +0100 >From: Amir_Netiv@f120.n9721.z9.virnet.bad.se (Amir Netiv) Subject: Ignorance is curable (mostly PC) To: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) Quating Amir_Netiv@f120.n9721.z9.virnet.bad.se (Amir Netiv): >>> my previous posting With the rise of companion and stealth viruses, to be >>> sure in checking the low levels you must first authenticate the path to >>> disk >>How exactly do you do that? If a virus has been loaded and is chained to INT >>13h, so that when you look for Sector-X Cyl-Y Head-Z it will replace it with >>another location and you will never know ! Padgett answers: > Read Andrew Shulman's "Undocumented DOS". Int 2F Fn 13 will return the path > to Int 13 DOS found when loading. If it does not point to the ROM BIOS or a > controller card ROM, you have a problem (how you WILL know). If your program > runs at the BIOS level like mine do, the table vector *must* point to the > ROM BIOS or a disk controller if the machine is clean. > At BIOS time, high RAM does not exist and every Intel processor is in REAL > (8086) mode. Things are very predictable. Well dear Padgett, it seems like you didn't quite get my idea: There is no problem in checking that the original INR-13 ISR is located on the BIOS area ( except if you are using some smart PC that does the shadowing of the BIOS to another area in RAM location and completely remapps the adresses), However that is not the issue here. When you know the location of the original INT-13 ISR is when the system is already booted (or in the process) but *AFTER* the IO.SYS is loaded (unless your Anti Virus is also an operating system which you will excuse me for not believing it is so). Therefor, your program cannot tell you that the original boot sector or partition table is replaced! Remember that AFTER what you call BIOS time (nice term) the BIOS usually does not necessarily continue to supply INT-13 services. AN: >>Any way that you might point out as the total solution to the problem, I can >>show a hole that viruses (naturally) may (or alredy do) use. Padgett answers: > A virus can intercept an interrupt vector. It cannot intercept as FAR CALL. > All you need to know is where to make the far call to (the exercise is > left to the student). *No* virus can infect ROM memory unless > built in at the factory. A. I agree that a virus does not intercept a FAR CALL, but only hooks an interrupt. B. To know where to make the far call to, you should be a Gypsy and own a crystal ball to consult with. Because what ever YOU consider predictable is not so in reality. The "original" procedure is located somwhere in the system depending which program took it. You cannot assume that the INT-13 ISR is in a constant place nor can you assume it is a part of the BIOS, because if you do, your program is likelly to crach a lot of PCs especially those that use special low level programs like Access control to disks, and several Network tools. So much for predictions. C. Did I ever say that the virus infects the ROM ? You have to be very ignorent to say so. D. I'd reccomend that the student will learn a little more about programs and utilities before writing programs that makes the PC a solid rock with no flexibility (interrupts hooked in place forever by some Anti-Virus). > As a consequence, the fact that the A-V is checking the STACed drive boot > sector means more than just an error is being flagged each time, it would > make me concered that the real boot sector may be skipped. >>Not necessarily so, but quite likely. > Would you care to bet your PC on it ? Perhaps I was being too gentle. EVERY > A-V I have seen that flags the compressed drive has been missing the real > DBR. Further, with the possible exception of the DOS 6.0 compression > (haven't gotten that far in studying it yet, it blew up on the > test XT) every one of the compression schemes I've looked at have layered > their driver on top of DOS and intercept INT 25 & 26, not 13. If you > use 13, you will never see the compressed disk boot sector. Is that clear > enough ? I'm sorry to be the one that lets you know that int-25 & 26 are translated eventually into INT-13. Just as INT-21 Fn 02 (write char) is translated into INT-10. So you see, what you wrote is incorrect. Ther is *NO* are on the formatted disk surface that is not acessible via INT-13. AN: >>As for myself, I do not recommend using these double-diskers, >>since the problem that you mentioned (and viral problems >>in whole) is only a small portion of possible problems to happened. And >>believe me - you don't want to be the owner of a disk when it crashes. Padgett answers: > Legitemate opinion. Mine is that compressed drives make so much sense that > they will become a standard. The key is in the recovery programs and they > are maturing nicely. As Darwin said, eventually if the environment is hostile the species that will survive is the one that will adapt. But the question should be: Is that the right thing to do here? We (software makers) are so anxious to supply the users with what they want, that we tend to disregard the consequences. AN: >>It remindes me of the EXPANDED memory cards that people used to buy once, >>and got stuck with it immediatelly since EXTENDED memory has emerged. >>Get a bigger (faster) and reliable disk. Padgett answers: > I have not yet reached the point of being able to treat PCs as disposable > items, nor would I want to. Who said you should? > Extended memory is a valuable attribute for > 386 and higher machines. I still have 2 XT class and 1 AT class machines > that see regular and valuable use. It seems you do not read the things you reply to! I said that the EXPANDED memory cards that used to be, were out of fassion before they were able to be sold in large quantities. I truelly hope that the same will happen with the disk-doublers. > My next *major* purchase > will be a parallel port ethernet adaptor for my laptop. I suspect that > like myself, most readers are not independantly funded. Good for you. Hope N.Y. was not too cold for you. Regards * Amir Netiv. V-CARE Anti-Virus, head team * - --- FastEcho 1.21 * Origin: <<< NSE Software >>> Israel (9:9721/120) ------------------------------ Date: Mon, 22 Mar 93 13:23:00 +0100 >From: Amir_Netiv@f120.n9721.z9.virnet.bad.se (Amir Netiv) Subject: Central Point and Stacker (PC) Donny Gilor writes Quating Amir_Netiv@f120.n9721.z9.virnet.bad.se (Amir Netiv): AN: >> 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). Donny: > Most TSR writers disagree with you especially since DOS is built for > TSRs. If you're right you should be warning anybody using any sort of > TSR with Stacker (including keyboard handlers, EMM386, Windows, etc). Since you are new here, let me first welcome you. As for TSRs, I think you are way out of time in starting again the encient discussion of TSRs or not. Juust to remind you V-CARE is equipped with a TSR for quite some time already, and as a TSR writer myself, I think I may express my poinion about them. Second thing: your *"DOS is built for TSRs"* flag ship is not correct ( historically speaking). "DOS supports TSRs" is a much better term. However the main problem is that DOS is an operating system that suffers from the lack of standartization, thus causing conflicts and crashes between programs, and since TSRs use system resources in the most intensive way they are the main cause for conflicts. Evidently it seems you've missunderstand my view on TSRs and so you keep answering to things I do not say. Thired: You do not have to warn anybody using other TSRs like keyboard handlers since they do not tamper with the set of interrupts used to acess the disk. As for QEMM386 I'm surprized that a man with such an experiance as you claim to have does not know thet EMM386 has many conflicts, which makes a lot of users switch to QEMM (which also has a lot of different conflicts). Last but not least: If it didnt happened to yet I truelly hope it never will, but Double disk for example conflicts with several optimization programs and some utilities, the result is fatal, I've experianced it myself several times. Regards * Amir Netiv. V-CARE Anti-Virus, head team * - --- FastEcho 1.21 * Origin: <<< NSE Software >>> Israel (9:9721/120) ------------------------------ Date: Mon, 22 Mar 93 16:01:31 +0000 >From: runefr@ifi.uio.no (Rune Fr|ysa) Subject: Virus signature determination. (PC) I'm planning to expand an anti-viral utility to include file scanning, like Mc'Affe's scan program does. Therefore I would be interested in more information of how I determine the signature of any virus, including mutating ones. I know that I could allow one virus to infect multiple files, and then do a file comparsion to find the equalities between the files. This however would probably result in very long signatures (if not the entire virus, which would make it fatal to distribute the signature file). Just taking the very first bytes of the virus into account, would however cause to many false alarms. Is it also possible to get signature files from somewhere and implement them in the package? (The format of the files would ofcourse be of ultimate interest.) - -Rune (runefr@ifi.uio.no) PGP 2.x public key available on request. ------------------------------ Date: Tue, 23 Mar 93 15:47:41 +0000 >From: antkow@eclipse.sheridanc.on.ca (Chris Antkow) Subject: Re: Virus that infects while Scanning? (PC) rkolter@csuohio.edu (Ryan Kolter) writes: >I don't know if there is a virus out there that does this. Is there? >If so, is there a way to protect against it? He said that Mcaffee didn't >pick it up. (I don't know what version he used). Some virus scanners do protect against these types of viruses (I believe ViruScan does this somehow...). YES! There are viruses out there that do this. I don't know about "Removing" themselves from memory, but the way that many of the techniques are accomplished, are by not infecting the Scanner (To avoid a faulty CRC check), and then using the scanners Func. 3Dh/INT 21h (Open file) call in order to infect the file. Some viruses that do this are later versions of DataRape (Aka: Sunday 2), NPOX (NukePox), and I believe Horse does this as well (Can't really remember, I don't have the source code handy...) Also, any other disinfect-on-the-fly virus is able to do this as well (NPOX v2.0+, 1963...) They do exist... Cheers... Chris antkow@eclipse.sheridanc.on.ca "Smash the control images, Smash the control machine" - William S. Burroughs ------------------------------ Date: Tue, 23 Mar 93 11:23:44 -0500 >From: jilka@GBAWS4.ZAMG.AC.AT Subject: virus-map (PC) Hi all, is there a kind of map, report, list, whatever about the places in the world where specific viruses usually can be expected to be found ? Some of them are probably all over the world, but every now and then I read, that virus X is not even in the wild, virus Y might be the culprit, as the PC stands in South Africa. Can someone give me a pointer ? TIA, Alfred - -- ############################################################################### Alfred JILKA # This place intentionally left blank! This place i Geological Survey, Austria # ntentionally left blank! This place intentionally KARGRA@GBA930.ZAMG.AC.AT # left blank! This place intentionally left blank! JILKA@GBAWS4.ZAMG.AC.AT # This place intentionally left blank! This place i #################Don't cut here, you'll damage the screen !#################### ------------------------------ Date: Tue, 23 Mar 93 11:31:52 -0500 >From: Donald G Peters Subject: Re: EXE/COM switch (PC) JR sent me a scathing letter (which was cross posted here) saying that the EXE/COM switch was "simply dangerous" to use. There was no explanation, but one could infer that JR was concerned about having a false sense of security that the EXE/COM switch would give because it would only work against "stupid" viruses. Of course no SINGLE mechanism which JR uses is sufficient to prevent a virus infection. Surely JR uses a variety of techniques. In this case, I once threw out an estimate that this would work against 50% of all viruses. To my regret, nobody attempted to produce a more accurate figure. I guess I could make a tabulation based on lists like the one in CPAV, but I didn't want to use figures from a source that people seem to dislike on this forum. If I came up with a device that could prevent 50% of all plane crashes, would that also be a "dangerous" device because it would give a false sense of security? For people who use scanners, I don't think the EXE/COM switch buys much. It wouldn't "add another 50%" in that case. For people who know enough to poke values into COMMAND.COM to change COM to CCC, this method probably wouldn't help much either. These people probably have other defenses set up. The EXE/COM switch is only useful for a certain group of people, like maybe my parents, who had to call me the other day to ask which way they stick a 3.5" floppy diskette into the drive. :-) However even they, like me, don't share executeables, so not even a scanner would do us much good. ------------------------------ Date: Tue, 23 Mar 93 23:16:25 +0000 >From: hiscrp@nuscc.nus.sg (C R Pennell) Subject: Singaporean car dealers & Mike (PC) I shouldn't have done it. It's my punishement for wishing ill of car-dealers. Anyway lots of people want copies of the article on virus attacks on those nice people who help us buy cars in Singapore. BUT I posted the article ages ago, and only today has it surfaced so I'm not sure I can find the article so easily (This is an explanation, not a criticism of our ref., who probably has better things to do) I'll try and locate it. But bear in mind that the people who write on viruses in the STRAITS TIMES are no better than the people who write on viruses in newspapers anywhere. . . . Richard Pennell History NUS ------------------------------ Date: Tue, 23 Mar 93 21:12:48 -0500 >From: jaflrn!jaf@uunet.UU.NET (Jon Freivald) Subject: VirusCheck 3.0 looking for Beta testers (PC) VirusCheck 3.0 is well underway and looking for BETA TESTERS. What is it? VirusCheck is a watchdog/shell for McAfee Associates ViruScan virus scanning software. It eliminates the need for many custom batch files to accomodate different machines and eliminates the need for the user to sit and watch while his system is being scanned. VirusCheck is designed around US Marine Corps anti-virus policies, yet is flexible enough to be in use by many agencies and thousands of users world-wide. It will insure that the entire system gets scanned. (How many of your network users or temporary employees know how many partitions are on the system(s) they use?) It will monitor the exit code returned by ViruScan and lock the system if a virus is found. VirusCheck also includes "policy enforcement tools" for the local area network administrator to use. Using this utility (affectionately named "the Enforcer") will deny network access to any user who does not comply with the established anti-virus policy (as long as that policy is the use of VirusCheck/ViruScan). VirusCheck 2.3b has been in production use throughout the US Marine Corps and on tens of thousands of other systems since November 91. Version 3.0 is a complete, ground-up re-write with many new and improved features. If you are interested in BETA TESTING this new version, you can obtain it in the following ways: Download from my BBS -- dial (516) 483-5841, settings n81, 300-9600 V.32, login "guest", password "guest", download /public/dos/virus/vc3beta.exe Via mail-server -- send mail to "mail-server%jaflrn@uunet.uu.net" the subject line will be ignored, include the text "get dos/virus/vc3beta.exe"; if you also need ViruScan, "get dos/virus/scanv102.zip" will get it. The files will be sent to you via return e-mail in multiple UUEncoded segments. Snail-mail -- send a stamped, self-addressed diskette mailer and your preferred format diskette (360K through 1.44M) to: Jon Freivald 269 Mitchel Ave East Meadow, NY 11554 ============================================================================= Jon Freivald ( jaf%jaflrn@uunet.UU.NET ) Nothing is impossible for the man who doesn't have to do it. PGP V2 public key available on request ============================================================================= ------------------------------ Date: Wed, 24 Mar 93 06:52:57 +0000 >From: cftdl@ux1.cts.eiu.edu (Terry Lundgren) Subject: Catch from DIR? (PC) I have received some excellent replies to my posting on catching a virus. Basically the question is this: Assume my system is clean and I have an infected disk. I put the disk in the drive and do a DIR. Then I take the disk out. Can my system be infected now? The responses are running about 1/3 saying no way and 2/3 saying it is possible. I would really like to get a definitive answer. If a virus can be passed in this way, would someone please describe how it might happen? Or not. Thanks. - -- Terry Lundgren, Administrative Information Systems, EIU ------------------------------ Date: Wed, 24 Mar 93 03:39:36 -0500 >From: bill.lambdin@frenchc.eskimo.com (Bill Lambdin) Subject: michelangelo (PC) >From: streb@ee.rochester.edu (Chuck S.) Subject: Re: Michelangelo (PC) Dido We had a drive die just as it was turned on Sat. Mikey was not announched this time around and got us! chuck - -------------------------------------------------------------------------- I'm sorry to hear that tou were affected by Michelangelo. CNN posted a little blurb about Michelangelo on March 5th. Apparently their informant wasn't very well informed. but they did spread the word about Michelangelo set to attack on March 6th. But Michelangelo is not a file infector. Michelangelo is a variant of Stoned, and hides in the boot sector of diskettes, and the partition table of hard drives. Bill - --- * WinQwk 2.0 a#383 * SICILIAN MOB activates after December 31st 1991 ------------------------------ Date: Wed, 24 Mar 93 03:47:40 -0500 >From: bill.lambdin@frenchc.eskimo.com (Bill Lambdin) Subject: michelangelo (PC) >From: tac@world.std.com (Tackey Chan) Subject: Michelangelo Virus (PC) I was wondering if anyone can tell me about how this virus works? Does it only affect that one day or does it tag allow somwhow onto things posted on "nn"? Anything you can tell me would be appreicated do that I can know what to look for. - -------------------------------------------------------------------------- Michelangelo is a variant of Stoned. Meaning that it hides in the boot sector of diskettes, and partition table of hard drives. Michelangelo is detectable, and removable by most if not all scanners. When the hard drive is infected, the virus goes resident, taking about 2K of memory below the 640K limit. It will infect diskettes (even high density diskettes) as they are accessed in A: Bill - --- * WinQwk 2.0 a#383 * KENEDY activates Nov 18th ------------------------------ Date: Wed, 24 Mar 93 03:47:53 -0500 >From: bill.lambdin@frenchc.eskimo.com (Bill Lambdin) Subject: Re: Partition table virus (PC) Date: Mon, 08 Mar 93 16:55:41 +0000 >From: theodore@unity.ncsu.edu (Andrew M Smith) Subject: [Stoned] (PC) Has anyone heard of the [Stoned] virus and if so, then what does it do? Also, I have an odd question concerning infected disks...If I have an infected disk and run a magnet across it, will all data (and the virus) be erased??? - -------------------------------------------------------------------------- Stoned is a rather benign virus except for when it infects irregular hard ware. Stoned hides in the boot sector of floppies, and the partition table of hard drives. McAfee's Clean can remove the virus from hard drives, and floppies. the command is CLEAN C: [STONED] substitute the drive letter when removing Stoned from diskettes. Bill - --- * WinQwk 2.0 a#383 * SATURDAY THE 14TH activates Saturday 14th ------------------------------ Date: Wed, 24 Mar 93 06:19:29 -0500 >From: Rutger van de GeVEL Subject: McAfee's Clean-output (PC) Dear networkers, I'm not sure if this is the right place to ask this, but I'll do it anyway. Maybe some of you have noticed that the screen output from both SCAN.EXE and CLEAN.EXE (from McAfee Associates) is different from the output produced when the /REPORT option is used. The output in the report file is very brief and (for example) doesn't show if a virus is (or isn't) removed: it only tells that a virus has been found. Why is this? The reason why I ask this is that I would like to process the report files from SCAN.EXE and CLEAN.EXE in order to automatically eliminate any virus that is found with a self-written program. So IMHO the output in the report files should be more elaborate or at least the same as the screen-output (this applies to both SCAN.EXE and CLEAN.EXE). Example: Output on the screen from CLEAN.EXE when cleaning [Stoned]: Cleaning [stoned] Scanning for memory resident viruses. Scanning 64K RAM...... Drive B: has no volume label. Scanning boot sector of disk B: Found the Stoned [Stoned] Virus in boot sector. Virus cannot be safely removed from boot sector. <--- Yes, message is there Found 1 file containing viruses. This McAFEE(TM) software may..... Copyright (c) McAfee Associates 1989-1993. All Rights Reserved. Output in the report file by CLEAN.EXE (with /report option) when cleaning [Stoned] (the same disk with the same virus): Options: b: [stoned] /a /m /chkhi /nopause /unattend /report c:\clean.log Drive B: has no volume label. Found the Stoned [Stoned] Virus in boot sector. - ---> Am I missing something here? <---- Found 1 file containing viruses. So perhaps this could be fixed in futures releases. Thanks, Rutger ******************************************************************************* Three Accounts for the Super-users in the sky, * Rutger van de GeVEL, Seven for the Operators in their halls of fame, * Student Information Nine for Ordinary Users doomed to crie, * Management & Technology, One for the Illegal Cracker with his evil game * Tilburg University, Holland In the Domains of Internet where the data lie. *********** Email address: One Account to rule them all, One Account to watch them, * rutger@kub.nl One Account to make them all and in the network bind them * Phone : (66)2049 In the Domains of Internet where the data lie. * Office: B512 ******************************************************************************* ------------------------------ Date: Tue, 23 Mar 93 11:31:09 -0500 >From: brunnstein@rz.informatik.uni-hamburg.dbp.de Subject: Virus Catalog update/New VirusBase The new version of Virus Test Center' *Computer Virus Catalog* is now available for ftp (ftp.informatik.uni-hamburg.de). The following files may be downloaded: INDEX.ZIP the new index file (INDEX.293), listing all 283 viruses in 5 platforms yet described AMIGAVIR.ZIP the cumulative AMIGAVIR files, now describing 77 AMIGA viruses (15 new ones) MSDOSVIR.ZIP the cumulative MSDOSVIR.files, now classifying 156 MSDOS viruses and trojans (32 new ones) MACVIR.ZIP the cumulative MACVIR files; no update since July 1992 (.792) as no new viruses were found ATARIVIR.ZIP the old AtariVir files (20 viruses) not updated as we have no new viruses for analysis. The single UNIX virus (AT&T Attack) will be sent on request (on ftp soon). In the new MSDOSVIR.293 file, the following new PC viruses are classified: 10_past_3 (2), Adolf, Alabama, Chemnitz, Exe_Bug (2), Flip, Hey_You, Kampana=Spanish Telecom (2), Minimal (15), Techno, VOID_POEM, V-163 and V-Sign/CANSU. Moreover, characteristic features of viruses generated by the following author- ing packages are also classified: PS-MPC and VCL. As announced last year, the new *machine readable CVC version* called CVBASE is also available for downloading: cvbase-293.zip. CVBASE allows to display all CVC entries (in total 288, on Amiga, Atari, Mac, MsDos and the single UNIX virus), under option VIRUS, but also gives an OVERVIEW and STRAIN relationsship about All (about 2,200) viruses in the CARO/VTC collections (using CARO naming scheme) as well as the VTC collection on Amiga (77), Atari (20), Mac (35) and Unix (1). From STRAIN, one may read available CVC entries. *Any suggestions how to improve this version are welcome* Klaus Brunnstein (U-Hamburg, Virus Test Center, March 22,1993) ------------------------------ End of VIRUS-L Digest [Volume 6 Issue 49] *****************************************