Received: from fidoii.CC.Lehigh.EDU by abacus.hgs.se (5.65c/1.5) id AA18232; Thu, 25 Feb 1993 21:03:25 +0100 Received: from (localhost) by Fidoii.CC.Lehigh.EDU with SMTP id AA18624 (5.67a/IDA-1.5 for ); Thu, 25 Feb 1993 14:35:38 -0500 Date: Thu, 25 Feb 1993 14:35:38 -0500 Message-Id: <9302251934.AA06239@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 #35 Status: RO VIRUS-L Digest Thursday, 25 Feb 1993 Volume 6 : Issue 35 Today's Topics: WARNING: Two new Mac viruses (Mac) Re: Sale of Viri [sic] your opinions on virus legality polymorphic compiler Re: general entertainment Re: How to measure polymorphism Detecting Michelangelo (PC) Rebuilding partition tables (PC) Re: EXE/COM switch (PC) Effect of Form (PC) Re: Michelangelo detect/removal instructions (PC) Re: PC Magazine reviews virus scanners (PC) Re: Scanning memory (PC) Help - GenB and GenP virus problem (PC) (long) Re: Question about Patricia Hoffman and John McAfee (PC) Michelangelo Functions (CVP) Re: Virus Survey Results 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: Thu, 25 Feb 93 11:30:55 -0500 From: spaf@cs.purdue.edu Subject: WARNING: Two new Mac viruses (Mac) Two New Macintosh Virus Variants Discovered 25 Feb 1993 First Virus (variant): CDEF Damage: as with CDEF Spread: unknown Systems affected: Apple Macintosh computers running pre-Version 7. A minor variant of the CDEF virus has been discovered. The damage and effects are identical to the original CDEF virus. CDEF viruses only affect Macintoshes running a version of the Mac OS prior to Version 7. Almost all Macintosh anti-virus tools already detect this new strain of CDEF. The authors of all other major Macintosh anti-virus tools are planning updates to their tools to recognize this virus variant. Some of these are listed below. We recommend that you obtain and run a CURRENT version of AT LEAST ONE of these programs. Second Virus (variant): T4-C Damage: altered boot code; altered/damaged applications; damaged system Spread: unknown Systems affected: Apple Macintosh computers. All types. The T4 virus was discovered in June of 1992. A previously unseen variant, being called T4-C, has recently been discovered. Many machines at the discovering site have been affected by T4-C, and the potential for wider dissemintion exists. Like the other T4 strains, this virus attempts to modify system boot code, and also changes the names of some applications to "Disinfectant". The virus does not work as (we assume) the author intended, and files may be left with changed names and possibly other damage. The system file may also be altered, and the damage may render some systems unbootable. The virus also attempts to modify application files on the system disk. These alterations may damage some applications by overwriting portions of the programs with the virus code; as a result, some damaged applications may need to be reinstalled after the virus has been removed. Once installed and active, the T4-C virus does not appear to perform any other overt damage. The virus, when active, may print a message indicating that the system is infected with the T4 virus. Some Macintosh anti-virus tools already detect this new strain of T4. 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.01c Where to find: Compuserve, America Online, sumex-aim.stanford.edu, Central Point BBS, (503) 690-6650 When available: immediately Notes: Users do not need a revision of the AV application. Users need to obtain the 2/24/93 version of the MacSig file. Tool: Disinfectant Status: Free software (courtesy of Northwestern University and John Norstad) Revision to be released: 3.0 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 Note: release 3.0 is *not* a major new release of Disinfectant. Be sure to read the release notes for details of the version number change. Tool: Gatekeeper Status: Free software (courtesy of Chris Johnson) Revision to be released: No new revision needed; 1.2.7 works for both. 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: All current versions starting with 1.1.9w are effective; no new release is needed. 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.3 Where to find: CompuServe, America Online, Applelink, Symantec's Customer Service @ 800-441-7234 When available: immediately Notes: SAM 3.5 and SAM Intercept 3.0 both recognize these viruses, and both can remove the CDEF strain. An update is required to remove the T4-C strain from undamaged files. This may be obtained from the locations listed above, or by ftp from rascal.ics.utexas.edu in the mac/virus-catchers/SAM directory. Tool: Virex Status: Commercial software Revision to be released: Current version is effective: 3.91 Where to find: Microcom, Inc (919) 490-1277 When available: February 28 Comments: Virex 3.91 will detect the viruses in any file, and repair any file that has not been permanently damaged. Users of Virex, version 3.82 or greater, are already able to detect the T4-C infection. The CDEF virus is detected and repaired in versions 3.0 and greater. 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. Tool: VirusDetective Status: Shareware Revision to be released: no new release is needed; current version is 5.0.6 When available: immediately 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: Wed, 24 Feb 93 17:12:24 -0500 From: mha@baka.ithaca.ny.us (Mark Anbinder) Subject: Re: Sale of Viri [sic] Tom Zmudzinski says... >> I am just wondering if you got a virus, and passed it on accidently, >> could you be held civilly at fault for thousands of dollars of >> damage say if it got into a business? > > First, let me say that I am NOT a lawyer (my parents are married), but > the answer is an otherwise unqualified (and rather loud) *Y*E*S* !!! Sadly, I have to agree. I, also, am not a lawyer, but I'm aware of at least one case in which a company's employee was held responsible for unintentionally introducing a computer virus to his company's microcomputers. He was fired for a breach of security, and alleged evidence tracing the virus infection to his system was used. In this situation he was not made financially or legally responsible in any sense other than being dismissed. Without details regarding the company's policies on computer usage, it's hard to say whether his firing was justified solely on the basis of the virus, or also on violation of company rules limiting his use of diskettes brought from outside the company. I hope that, if a case SHOULD come up with civil or legal action against someone who is alleged to have introduced a virus unintentionally, the courts will realize the extent to which that user is an unwitting agent. Then the burden of proving intent or lack thereof would fall on the prosecution or plaintiff. An interesting thought... could this be tied to cases in which someone has passed on a communicable disease, knowingly or otherwise? - ------------------------------------------------------------------------- Mark H. Anbinder | Technical Support Coordinator BAKA Computers Inc. | mha@baka.ithaca.ny.us 200 Pleasant Grove Road | (or) mha@tidbits.com Ithaca, New York 14850 USA | Phone 607-257-2070 Fax 257-2657 - ------------------------------------------------------------------------- MUGWUMP.. Ithaca's Macintosh User Group. E-mail me for details, or send a note to MUGWUMP, P. O. Box 4735, Ithaca, NY 14852-4735, and we'll be happy to send you a sample copy of CLiCKS, our monthly newsletter. - ------------------------------------------------------------------------- ------------------------------ Date: Tue, 23 Feb 93 19:00:00 -0500 From: Luis Gamero Subject: your opinions on virus legality No. If you keep it in your OWN posession how could it be illegal? You can own a gun and not use it. That's not illegal. - -- Canada Remote Systems - Toronto, Ontario 416-629-7000/629-7044 ------------------------------ Date: Wed, 24 Feb 93 17:45:47 -0500 From: "Paul D. Bradshaw" Subject: polymorphic compiler Am I missing something important about this polymorphic compiler? If the good guys have GOOD polymorphic compilers then won't the bad guys have quality polymorphic compilers as well? Wouldn't this mean that a virus writer could write one simple virus, and compile it n times to release n copies into the wild? It seems to me that virus writers would benefit more from a polymorphic compiler than anti-virus software writers would. Afterall not that many viruses target specific anti-virus software. What if this compiler were applied to the code for an existing successful virus like stoned? - ------------------------------------------------------------------------- Paul D. Bradshaw Computing and Communications Services ACDPaul@VM.UoGuelph.Ca University of Guelph, PaulB@SuppServ.CIS.UoGuelph.Ca Guelph, Ontario, Canada - ------------------------------------------------------------------------- ------------------------------ Date: 25 Feb 93 13:44:43 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: general entertainment I.LEITCH@lshtm.ac.uk (Ian Leitch) writes: > There has been no 'deliberate distortion' of any facts within > the book, except as declared in the Acknowledgements. So they are just mistakes made out of incompetentness, then... > A matter of speculation (such as the identity of 'Diana P') can > hardly be considered 'a factual error'. It may be wrong, but we Oh, I agree with that - that the identity of 'Diana P.' as proposed in the book is pure speculation and has nothing factual in it. I'll just add that this speculation comes from Mr. Clough - it seems unlikely to me that somebody in Bulgaria could tell him such a nonsense... For several reasons... First, as I said, the members of the English high society are not that popular in Bulgaria at all - for instance, I wouldn't be surprised if not all people there know even the name of the Queen. Second, if Darkie meant Princess Diana, he would have written "Princess Diana". Third, it is a common practice in Bulgaria to abbreviate somebody's family name to one letter, if you don't want to reveal his/her identity. Thus, the "P." in "Diana P." is much more likely to mean an abbreviated family name, than a title. > have yet to learn who 'Diana P' is. And, even then, who knows? > One guess is as good as another. Well, having in mind that the virus is written by a Bulgarian, the guesses of another Bulgarian about the meanings of the text there are more likely to be true... > Some of the 'facts' may be disputed but contributors' memories > tend to be selective and self-serving, and it is always difficult > to ascertain 'the truth'. So, does Mr. Clough imply that he knows 'the truth' better than the main participants of the stories described by him? > It would be interesting for Vesselin to identify the > distortions, so that these can be compared with the research > material and recorded interviews. All of them?? OK, by just browsing the chapter about the Bulgarian Threat from the book, I spotted about 50 different mistakes. Some of them are minor ones, but this gives you the idea about how exact the book is. I'll send to the moderator a list of them, but I don't think that it will be appropriate to post that - it's more than 20 Kb! And those are the mistakes only in a single chapter! Several of them are technical mistakes - mistakes that anybody who has analysed the particular viruses could confirm. I'll repeat it again - the book is very well written, it is very readable and entertaining. It's written in that journalistic style, which is characteristic for some newspapers. I guess that Mr. Mungo has helped a lot here. The analysis of the situation, and in general the non-technical and non-factual things are quite deep and correct. However, the technical part of the book has many incorrectnesses - incorrectnesses which are forgivable for a technically incompetent journalist, but not for a security consultant like Mr. Clough. In short - read the book, it is entertaining and you'll have a very good time. Just don't rely on it about technical or factual matters. > Perhaps, he could also identify 'Diana P'? If I could identify her exactly, this would help me to find out who exactly the Dark Avenger is... 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: 25 Feb 93 14:14:37 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: How to measure polymorphism houle@nmt.edu (Paul Houle) writes: > I think that the polymorphic compiler approach is still > stronger than that of the existing polymorphic engines. It also has I meant that there is no need to use such a strong thing. Using a polymorphic package (not necessarily one of the existing ones) will be enough - the installation program will just use the package to encrypt the executables during installation and to prepend a random decryptor to them. > the advantage that it will work fine in operating systems and > environents that don't like self-modifying code. The compiler could Even the currently available polymorphic packages have no problems with self-modification. The MtE- and TPE-based viruses do not modify themselves once generated - the gust generate modified copies of themselves on each infection. > Definitely, the most advanced cryptography technology > availible should be used. I'm not sure what you mean, but in most cases cryptographic strongness is not necessary. A CRC is, for all practical reasons, just as good as a cryptographically strong hash function, if (but only if!) the virus has no way to guess the generator. > The problem is that the keys have to be > laying around somewhere, even if you are using a public key system -- You shouldn't mess virus protection with crypto protection. The keys could pretty well lay around - e.g., on a post-it note attached on your terminal, as soon as the virus has no way to get them from there... :-) > Deleting a checksum database would probably be a bad idea for a virus > - -- and having your integrity checker choke would certainly be a > warning sign. It would make more sense for a virus to alter the CRCs > if it were possible for it to read the altered coefficients, keys, or > whatever it needs to make validation data. What you are saying above is definitively true and based on common sense. Yet, I know at least one commercially available anti-virus package, which provides a checksummer as part of itself. If you just delete the checksums, generated during the installation, and then modify (e.g., infect) some of the files, on the next execution of the package the checksums will be re-generated - on the modified files. :-( And there are already 2-3 viruses which are using exactly this trick to circumvent the package - and successfully, on the top of that... While I have yet to see a virus that tries to forge the CRCs - not that it's not possible when you know the generator - simply nobody has done it yet. 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, 25 Feb 93 01:40:56 -0500 From: "Roger Riordan" Subject: Detecting Michelangelo (PC) greg@ideath.goldenbear.com (Greg Broiles) writes >Greetings - given we are again approaching March 6, I thought it might >be useful to put together some instructions that would allow DOS-savvy >users (yeah, both of them :) to look for Michelangelo without needing >to spend time/dollars tracking down scanning software. > >(And yes, I agree that it's important for folks to take further data >protection measures - but it seems like some protection is better than >none, especially given the wide distribution of Michelangelo.) Please! Michelangelo is only one of 30 or 40 viruses which are moderately common (not to mention the other couplr of thousand in our zoos) and it is not even particularly bad; it only clobbers your hard disk on one day of the year, whereas it can fail catastrophically at any time on any day of the year. If a user hasn't got any AV software(s)he could have any of these viruses, and most of them could cause her/him serious problems under some circumstances. Virtually any AV software is better than fiddling around with homespun formulae to look for individual viruses, and at least one excellent product (F-Prot) is free to private users, and is (I think) readily available on bulletin boards. So if you know anyone who hasn't any AV software tell them to do themselves a favour and get a get a reputable scanner, instead of helping them delude themselves with witchcraft! Roger Riordan Author of the VET Anti-Viral Software. riordan.cybec@tmxmelb.mhs.oz.au CYBEC Pty Ltd. Tel: +613 521 0655 PO Box 205, Hampton Vic 3188 AUSTRALIA Fax: +613 521 0727 ------------------------------ Date: Thu, 25 Feb 93 01:41:17 -0500 From: "Roger Riordan" Subject: Rebuilding partition tables (PC) padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) writes >>Has anyone written a program that will allow you to create a new >>partition table sector from scratch, ... >Well I have all of the pieces, just not ready for Prime Time but others are >welcome. Basically all of the information is there (I include a write-up >in the FixMBR.DOC that comes with the FixUTIL3.ZIP - incidently half of >those are FREEWARE and the rest are on free trial until 7th March again >this year). > >First you have the BIOS information retrievable with Int 13 Fn 08. This will >tell you what the CMOS thinks the whole disk is (tracks, heads sectors). > >Next you have the Partition Table - this lists the logical drive information >for each partiton (starting sector, number of sectors, partition type). > >Then you have the Dos Boot Record which gives the same information as the >partition table for each partition. > >If there are multiple partitions, each will have its own DBR (and a recovery >program could just "walk the disk" looking for them) since DOS 3.0 they >*must* be in the same place. >Thus the information can be found in not one but *four* different places >on a DOS disk (Unix or Novell are different but the info is still there - >just keep fresh batteries in your TI Programmer 8*). You may recall that AntiCad (which goes off either if you access ACAD.EXE, or if you hit C-A-D while the tune is playing) overwrites all tracks on cylinder zero on drives A-D, then further tracks at increasing intervals till it gets to the end of the disk, then fills the CMOS RAM with 'FF's. This may not apply to all versions, but the ones we have seen certainly did, and when they had finished I think all the above sources had gone. I imagine this was the type of situation chowes@sfu.ca (Charles Howes) had in mind in his original query. Anyone got any other ideas? Roger Riordan Author of the VET Anti-Viral Software. riordan.cybec@tmxmelb.mhs.oz.au CYBEC Pty Ltd. Tel: +613 521 0655 PO Box 205, Hampton Vic 3188 AUSTRALIA Fax: +613 521 0727 ------------------------------ Date: 25 Feb 93 08:11:19 +0000 From: frisk@complex.is (Fridrik Skulason) Subject: Re: EXE/COM switch (PC) Peters@DOCKMASTER.NCSC.MIL (Donald G Peters) writes: >Here is an idea I have cooked up to defend against some types >of viruses. It has not (to my knowledge) been in print before. No wonder, as it is of no use... >Now any virus which is tailored to work specifically on >one type of program is not very likely to work... Wrong. Some viruses use the file name, and they will infect the file incorrectly, causing infected files to crash. Other viruses simply check for "MZ" or "ZM", and use that, and would therefore not be affected at all. - -frisk - -- Fridrik Skulason Frisk Software International phone: +354-1-694749 Author of F-PROT E-mail: frisk@complex.is fax: +354-1-28801 ------------------------------ Date: Thu, 25 Feb 93 08:27:40 +0000 From: nimoe@imp.uib.no (ivind Enger) Subject: Effect of Form (PC) We have just discovered that we have been infected by a strain of FORM. We do, however, suffer from lack of informaion about the effects of the virus. The virus infects the boot sector and I just read that it activates on certain days of the month, but what is the actual action of the virus when it activates? 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 know that there are lists like virlist.txt that follows the SCAN program, but I would like a somewhat more extensive description. Another last qestion: Is there any informaiton around about the virus TP4 (TP44)? good health to you all ivind ------------------------------ Date: 25 Feb 93 14:30:44 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Michelangelo detect/removal instructions (PC) greg@ideath.goldenbear.com (Greg Broiles) writes: > Greetings - given we are again approaching March 6, I thought it might > be useful to put together some instructions that would allow DOS-savvy > users (yeah, both of them :) to look for Michelangelo without needing > to spend time/dollars tracking down scanning software. An alternative would be to get one of those free (or free for individual use) scanners or Michelangelo-only detectors, if you are concerned only about this particular virus. There are still a few of them on our ftp site... > Seems like the first check should be the amount of system memory > reported by MEM or CHKDSK - which should be 655,360 on a 640K machine. > If a machine has 640K, and MEM/CHKDSK reports system memory of 655,360 > - - the machine *as running* cannot be infected, since one of the first > things Mich does is to subtract 2K from the total system memory > reported. The only problem with the above is that it can tell you only if the machine is NOT infected. Unfortunately, on many installations the above procedure generates too many false positives to keep the help desk happy... See the FAQ for more information on this subject. > DEBUG > l 0 0 0 1 > [to check a floppy in A: - should be 'l 0 2 0 1' to check C:] Nope, won't work on a hard disk. DEBUG's "l" command can only read logical sectors. That's OK on a floppy, but on the hard disk the virus is in the MBR, which does not belong to any logical partition and thus can be accessed only as physical sector. So, in this case you'll have to write a short assembly-language program that reads the MBR. > Users who find Mich can overwrite it on floppies with the SYS command; > users who find it on hard disks can overwrite it with FDISK /MBR, if their > FDISK supports it. If you are writing this for general distribution, you should specify the version of DOS that supports this - MS-DOS 5.0. 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: 25 Feb 93 15:22:42 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: PC Magazine reviews virus scanners (PC) cwong@cs.cornell.EDU (Christopher Yoong-Meng Wong) writes: > Have others seen the March 16, 1993 issue of PC Magazine yet? Normally, I > wouldn't expect this group to care much, but this magazine has tremendous > influence in the industry. A summary: > 1. Editors' choices are CPAV and NAV. This alone tells enough about the level of competence of the reviewers... I guess they have looked again to the user interface, instead of to the anti-virus features... > 2. The great grandaddy of virus scanners, Mc Afee's Viruscan family, > was not reviewed. Nor was F-prot (though the commercial version was > reviewed), except as an aside: "... for those comfortable with > command line operation ... original F-prot". Maybe they have decided to review only commercial (i.e., non-shareware) products? > 3. Scanning tests involved 11 -- count them -- 11 viruses. And, if I have heard correctly, none of the more recent widespread viruses like Form, V-Sign, Joshi are included. That is, a two-year old scanner would have passed the review rather well... Poor users who have to rely on the results of such scanners and such reviews... > Somehow, this review seems out of sync with almost everything I've read > here about virus scanners. Opinions? It seems to me a letter to the > letters page signed by a major virus researcher (or ten :-) ) would carry > a lot of weight. Good idea. Unfortunately, I am not receiving this magazine, so I have not read the review and therefore cannot write such a letter. Also, a letter by the authors of the programs that didn't score well in the review might also not be the best thing to do... :-) 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: 25 Feb 93 15:40:09 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Scanning memory (PC) ac999512@umbc.edu (ac999512) writes: > I agree that scanners shouldn't scream and yell when they detect a > virus floating in RAM that isn't active. Yet on the other hand, > nothing should be taken for granted as to where a virus is, as stated > above. I disagree. Each known virus installs itself at a particular place in RAM and scanners do just that - scanning for known viruses. There is no way Stoned can install itself in the DOS buffers, instead of at the top of the available memory at boot time. I am not saying that it is not possible to write a boot sector infector which will install itself elsewhere, but it will not be a Stoned variant any more. Usually, it is possible to limit the area of memory where each particular virus can reside. The only slightly difficult case is viruses like Number of the Beast and LeapFrog, which install themselves exactly in the DOS buffers. So, it would be difficult to tell whether you have just copied an infected file (and parts of it are still remaining inactive in the buffers) or you really have an active virus. Difficult, but not impossible. All such viruses exclude the buffer they are using from the chain of available buffers. So, all you have to do is to verify that the memory scan string is not found in one of the available buffers... > I think it best that scanners should check interrupt vectors and so > forth to determine if the virus is active, then inform the user as to > the presence of the virus, and whether or not it is active. That's rather difficult to implement reliably. What does "check the interrupt vectors" mean? Just look in the Interrupt Vector Table? Many viruses don't modify it at all. And what if something (a TSR) has intercepted the vector -after- the virus? What then? Trace the interrupt vectors? Again - too unreliable on some machines. No, this is not a good idea... 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: 25 Feb 93 16:49:54 +0000 From: jobrien@umescsnw1.umd.edu (JAMES M. O'BRIEN JR) Subject: Help - GenB and GenP virus problem (PC) (long) I maintain a LAN that has about 35 pc, a netware fileserver and various other unix workstations. Recently, (the past few days) we've seen a number of floopy disks that have been infected with a GenB (Generic Boot) virus, according to vhield 99 & vshield 100. Now, I've been trying to ascertain the source of this virus and it is proving difficult to pinpoint. We currently have a person scanning all students floppies when they enter our microlab. All pc's have vshield 100 loaded, scan on access, and halt on discovery of a virus. Here's where it starts to get interesting: Yesterday, it seemed like the virus was appearing out of nowhere. A student would get their floopy scanned, clean (according to scan 100) and then proceed to work on a pc. Shortly there after, their machine would hang, reboot and try to continue working. Access the floppy and boom, floppy is infected with a GenB virus. Well the floppy is trashed, and scanning the local HD proves not to be a help as it comes back clean (scan100). So. where is the darn virus coming from? I decided to be safe, and reformatted all 16 machines in the microlab (drastic, but I've got a install disk that helps speed it up..). All seems well, scanned the file server partitions, all come back clean. Continue scanning floppies as they enter the lab, catch a few, take care of them, etc.. Now a floppy that scanned clean is being used with turbo pascal 6.0, the machine hangs. reboot, back into turbo pascal, access the floppy, boom it hangs, GenB on floppy. What???? Scan local HD, now there's a GenP on the local HD! What is going on here? Anyone have any ideas how to kill this? Anyone aware of incompatiblities of turbo pascal and vshield? It seemed that a lot of the problems where with low density disk formatted as high density (darn ps/2's) but it hasn't always been the case. Thanks Jim O'Brien University of Maryland Eastern Shore jobrien@umescsnw1.umd.edu Network Manager ------------------------------ Date: Thu, 25 Feb 93 19:23:42 +0000 From: 007 Subject: Re: Question about Patricia Hoffman and John McAfee mcafee@netcom.com (McAfee Associates) writes: >sbonds@jarthur.Claremont.EDU (007) writes: >>mcafee@netcom.com (McAfee Associates) writes: >>>There is no close link between McAfee Associates and Ms. Hoffman, at >>>least, none different from that between her and any other anti-viral >>>vendor. >>Really? I wonder why Ms. Hoffman states in her "A word from Patricia..." >>section: >> >> A special thanks goes to John McAfee for the countless hours he >> has spent reviewing VSUM prior to its release. >> >>Seems she has a bit more of a connection with SCAN than "any other >>anti-viral vendor." > >Simply because John McAfee would spend hours on the phone telling her >about what viruses were new, where they came from, how common they >were, etc. If you think you have any such information that may be of >use to Ms. Hoffman, I'd suggest that you contact her. Perhaps you too >can get your name mentioned in her virus summary. That's very nice of Mr. McAfee. It also explains much about the information found in VSUM. As to contacting Ms. Hoffman, I did exactly that about a year and a half ago. After disassembling the Cinderella virus, I sent a copy of my findings to Ms. Hoffman so she might be able to update her entry for Cinderella. I never received any reply, and the entry on Cinderella remains the same as it always was. VSUM is a potentially very useful product. How many times on this list alone have we seen people asking "I've got XXXX virus, what does it do??" My only beef with VSUM is that the information is SO inaccurate. The VSUM hypertext interface is extremely easy to use, if only we could couple that with some genuinely accurate information! Currently, MSDOSVIR is the only list I know of that contains accurate or nearly accurate virus info. Frisk also has good information, but it is rather brief. What I'd like to see in a virus information listing: + Accurate virus info, and how to contact the person who disassembled the virus. I'm sure Ms. Hoffman has not looked at a disassembly of every virus in her listing. I suspect that frisk has. Reports of errors in the listings should at least be acknowledged. + Easy to use. Ms. Hoffman comes through with flying colors on this one. + CARO names for variants. + Cross-indexing names with output from popular scanners. VSUM used to do this with SCAN, but SCAN seems to change its naming scheme with each new release, making this difficult or impossible to implement. Too bad we can't get MSDOSVIR in hypertext format. -- 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: 24 Feb 93 23:51:00 -0600 From: "Rob Slade, DECrypt Editor, VARUG NLC rep, 604-984-4067" Subject: Michelangelo Functions (CVP) HISVIRX.CVP 930210 Michelangelo Functions The replication mechanism of Michelangelo is basically identical to that of Stoned. A boot sector infector, it replaces the original boot sector on a floppy disk with itself. The original boot sector, whatever it may be, is placed in a new position on sector 3 or 14 of the disk, and the virus contains a "loader" which points to this location. After the virus loads itself into memory, the original boot sector is run, and thus, to the user, the boot process appears to proceed normally. When a computer is booted from an infected disk, the virus first checks to see if a hard disk is present. If it is, the virus infects the hard disk in much the same way as a floppy, except that the master boot record, or partition boot record (the first sector "physically" present on the hard disk) is replaced (in sector 7) instead of the boot sector. In a sense, this method of replication is simpler than that of other boot sector infectors. It is always the "physical first" sector that is affected. This also takes place at a very low level, not requiring MS-DOS to be fully loaded to operate. As with Stoned, there is no "stealth" involved. Examination of the boot blocks with a sector editing utility will clearly show the difference between a "valid" sector, and one which is infected. (Stoned is easier to spot, with the text message within the sector, but the absence of the normal system messages should be a tip-off.) In addition, Michelangelo reserves itself 2K at the "top of memory": a simple run of the CHKDSK utility will show "total memory" on the system, and if a 640K machine shows 655,360 bytes then you do *not* have Michelangelo. (There may be other reasons than a virus if the number is less.) Removal is a simple matter of placing the original sector back where it belongs, wiping out the infection. This can be done with sector editing utilities, or even with DEBUG. (There are cases where a computer has been infected with both Stoned and Michelangelo. In this situation, the boot sector cannot be recovered, since both Stoned and Michelangelo use the same "landing zone" for the original sector, and the infection by the second virus overwrites the original boot sector with the contents of the first virus.) When an infected computer boots up, Michelangelo checks the date via interrupt 1Ah. If the date is March 6, the virus then overwrites the first several cylinders of the disk with the contents of memory (generally speaking, not much). There are two limitations of this damage. Interrupt 1Ah is not available on the earliest PCs and XTs. This is not to say that only ATs and up are vulnerable: "turbo" XTs have this interrupt as well. However, the disk that is overwritten is the disk booted from: a hard disk can be saved by the simple expedient of booting from a floppy. Also, the damage is only triggered at boot time. copyright Robert M. Slade, 1992 HISVIRX.CVP 930210 ============== ______________________ Vancouver ROBERTS@decus.ca | | /\ | | swiped Institute for Robert_Slade@sfu.ca | | __ | | __ | | from Research into rslade@cue.bc.ca | | \ \ / / | | Mike User p1@CyberStore.ca | | /________\ | | Church Security Canada V7K 2G6 |____|_____][_____|____| @sfu.ca ------------------------------ Date: Thu, 25 Feb 93 05:49:44 -0500 From: A.APPLEYARD@fs1.mt.umist.ac.uk Subject: Re: Virus Survey Results > Date: 20 Feb 93 03:35:43 +0000 > From: jay@info.umd.edu (Jay Elvove) > Subject: Virus Survey Results > In November, I distributed a questionnaire [re] ... computer viruses ... I have UUENCODED the results ... anonymous FTP from info.umd.edu in the file /info/Computers/PC/Unix/uuexe520.zip. - - ---cut here------cut here------cut here------cut here------cut here--- begin 644 vresults.txt M("LM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM ... etc etc For those who can't FTP from USA, and who can't translate uucode, here is a plain language adaptation of this message with lines <= 78 chars long:- [VIRUS SURVEY RESULTS] How many PCs do you use or oversee?: 2-4 = 1, 10-19 = 1, 20-49 = 11, 50+ = 39, total = 52. PC environment: solitary = 0, open lab = 5, restricted lab = 1, departmental LAN = 17, combination of these = 30, total = 53. % of users are: faculty = 13.5%, staff = 29.1%, graduate = 6.6%, undergrad = 17.3%, other = 1.3%, non-academic = 22.7%, n/a = 9.4%, total = 100.0%. Perceived threat fom viruses: extreme = 2, very = 6, moderate = 31, little = 13, none = 1, total = 53. How many virus incidents in last 6 months: 1 = 3, 2-4 = 18, 5-9 = 5, 10-19 = 7, 20-49 = 5, 50+ = 1, 0 = 14, total = 53. What viruses: Stoned = 31, Jerusalem = 8, Michelangelo = 12, Yankee Doodle = 3, Form = 3, other = 24, = 1, total = 82. Damage: files = 8, diskettes = 4, FAT = 4, down = 5, little = 9, other = 3, none = 9, n/a = 15, total = 57. Time to remove virus or recover from effects: < = 5 mins = 8, 6-15 mins = 6, 16-30 mins = 3, 31-60 mins = 3, 1-4 hrs = 5, >4 hrs = 7, n/a = 21, total = 53. Greatest source: faculty = 5, staff = 9, graduate = 8, undergrad = 14, other = 8, don't know = 4, n/a = 14, total = 62. Likeliest source: faculty = 4, staff = 9, graduate = 3, undergrad = 19, other = 15, don't know = 1, n/a = 2, total = 53. Likeliest transmission medium for viruses: floppy = 44, net/FTP = 4, BBS = 4, other = 6, n/a = 2, total = 60. Scanning frequency: every boot = 17, daily = 4, weekly n = 11, monthly = 7, rarely = 12, never = 1, n/a = 1, total = 53. How many of your PCs use TSRs to detect viruses?: 2-4 = 13, 5-9 = 1, 10-19 = 2, 20-49 = 6, 50+ = 15, 0 = 15, n/a = 1, total = 53. Backup frequency: daily = 23, bi-weekly = 1, weekly = 12, weekly = 7, weekly = 8, weekly = 1, = 1, total = 53. Prevention: TSRs = 19, scanning = 35, user education = 14, official policies = 12, backups = 10, other = 6, nothing = 1, n/a = 3, total = 100. Antivirals in use: F-Prot = 21, Vshield = 5, Scan = 5, NAV = 3, other McAfee = 5, other = 10, none = 20, total = 69. Affiliation: faculty = 6, staff = 30, graduate = 1, undergrad = 2, other = 1, non-academic = 12, = 1, total = 53. Source of info: UMCP = 15, Novell = 26, VIRUS-L = 10, E-mail = 2, total = 53. Site type: EDU = 41, COM = 12, total = 53. ------------------------------ End of VIRUS-L Digest [Volume 6 Issue 35] *****************************************