From: Kenneth R. van Wyk (The Moderator) Errors-To: krvw@CERT.SEI.CMU.EDU To: VIRUS-L@IBM1.CC.LEHIGH.EDU Path: cert.sei.cmu.edu!krvw Subject: VIRUS-L Digest V4 #126 Reply-To: VIRUS-L@IBM1.CC.LEHIGH.EDU -------- VIRUS-L Digest Tuesday, 16 Jul 1991 Volume 4 : Issue 126 Today's Topics: Exchanging floppies Re: Reviewing software Re: long and technical (PC) multi-compression IBM's VSTOP scanning compressed files for viruses (PC) Re: General definition part 1 (general) Re: McAfee on VSUM accuracy and Microcom (PC) Reply to Virus Bulletin (sorry for the length!) Special terminology 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. Please sign submissions with your real name. Send contributions to VIRUS-L@IBM1.CC.LEHIGH.EDU (that's equivalent to VIRUS-L at LEHIIBM1 for you BITNET folks). Information on accessing anti-virus, documentation, and back-issue archives is distributed periodically on the list. Administrative mail (comments, suggestions, and so forth) should be sent to me at: krvw@CERT.SEI.CMU.EDU. Ken van Wyk ---------------------------------------------------------------------- Date: Mon, 15 Jul 91 13:32:50 -0700 From: p1@arkham.wimsey.bc.ca (Rob Slade) Subject: Exchanging floppies hvonvill@magnus.acs.ohio-state.edu (Helena M Vonville) writes: > (acording to virscan and f-prot). My question is this: would we be > better off zapping the disks in the demagnitizer, then formatting? Or > is it safe to just re-format the disks? My concern is not only for > our systems, but the potential for speading virii to our patrons. We Given your reference to SCAN and FPROT, I assume you are working with MS-DOS. The answer to your question is slightly different for the Mac world. If you simply put a disk in the B: drive and give the format command, ther is no danger that a boot sector virus (or any other kind) will transfer from the floppy disk to your system. If you are already infected, you will, of course, infect the disk. If you put the floppy in drive A:, and accidentally reboot the computer, you may infect your system. To more directly answer your question, yes, a demagnetizer will give you slightly more safety, but making it policy to reformat these disks in drive B: will give you almost as much. ============= Vancouver p1@arkham.wimsey.bc.ca | "If you do buy a Institute for Robert_Slade@mtsg.sfu.ca | computer, don't Research into (SUZY) INtegrity | turn it on." User Canada V7K 2G6 | Richards' 2nd Law Security | of Data Security ------------------------------ Date: Tue, 16 Jul 91 12:33:25 +0700 From: James Nash Subject: Re: Reviewing software Several response cames in to my brief outline of the anti-viral software review that appears in the July 1991 issue of PC Plus (UK) magazine. The article outlines what viruses are with an excellent glossary of terms, where they come from and what they do. Next it has individual reviews of 10 software packages with a "star" security rating. >> From: Alan Solomon > Subject: Re: Reviews of anti-virus software > > [...]. I can see several sources of bias. > 1. The choice of viruses used in the test. A subset of all possible > viruses is used, ... > [There] needs to be some sort of disclosure on this commonality of the subsets > of the viruses. Couldn't agree more. Mark Hamilton in his review says "I have built up quite a large library of viruses collected from various sources around the world". Unfortunately he doesn't specify how many/ what type/ which viruses he used. Maybe it was lack of space or an oversight? He then goes on to specify... > 2. The criteria used for the review. ... [and] > 3. What is important? ... He outlines 3 points which I generally agree with: (i) Detection is more important than speed. 95% detection is OK. 90-95% is average. Anything else is unacceptable. (ii) Speed is important as a secondary issue. i.e. the less time it takes, the more inclined you will be to run it often. (iii) Disinfection capabilities. These are not tested in the review. I would agree that 90% of the problem is finding out you do have a problem. > As Anthony Naggs posting points out, it is important that any review > includes a full disclosure of connections. In the case of the PC Plus > review, it was worth disclosing that: [list deleted] None of these connections are mentioned but, to be fair, none of the companies are overtly pushed, let alone mentioned, outside any qualitative judgements on individual packages. It would be nice for Mark H. to have balanced these judgements with the facts Dr. S. mentioned. By the way, I'm just someone who has to fight viruses. I have no financial connections with any software company nor do I write anti-viral programs. >> From: c-rossgr@microsoft.COM > Subject: re: PC Plus (PC) > Interestingly enough, most reviews I've seen seem to suffer from a > case of "Gee, I don't really know nuttin' about anti-virus software, > but I got a job to do"-itis. ... > Undisclosed interests aren't half as bad as ignornat reviewers, in my > opnion. What is so refreshing about this review is that it is technically competent and expressed in language that could help to dismiss the myths surrounding viruses. To be able to write such a piece requires an "industry expert" which then brings in that individual's spin. So IHMO the problems above cannot be avoided in a knowledgable piece. [In reply to "We weren't included" message] > The crux of the problem, certainly. Did you, by any chance, have the > opportunity to forward a copy of your code to VB for inclusion in > their review(s), or did you expect them to track you down? The selection process of which packages to choose for review is also omitted. Overall I liked the feature but the omissions above could be construed as tarnishing its integrity. Personally I don't think so. - -- James Nash, Computing Services, Coventry Polytechnic, England - --Time passes slower when you're with your relatives. (A.E. sort of!) ------------------------------ Date: Mon, 15 Jul 91 20:49:15 +0300 From: vasya@stack.fian.msk.su (Vasili Bykov) Subject: Re: long and technical (PC) martin@cs.ualberta.ca (Tim Martin; FSO; Soil Sciences) writes: >MBR-infecting viruses trap the INT 13 vector from the vector table in RAM, >and re-route it through themselves, before anything else is executed. They >may include Stealth techniques to stop all subsequent efforts to access >"absolute sector one". After an infected boot-up, then, one cannot simply >write a clean MBR copy back into place and re-boot. > >Four Solution Ideas: >1 (Requires knowing what the correct BIOS INT 13 call address is.) On >each boot-up, re-write the "correct" INT 13 call into the vector table, >thereby "cutting off" the virus <...> > >2. (Requires knowing what the correct BIOS INT 13 call address is.) Modify >the MBR code so that it uses the correct INT 13 call <...> > >3. (Requires knowing what the correct BIOS INT 13 call address is.) Run a >program from the server, which uses the correct INT 13 call <...> > >4. <...> > >Discussion: >For solutions 1, 2, and 3 the implimentation is dependent on the specific >BIOS chip set. A more general "setup" program might be designed, if one >had the needed data for each known BIOS set. (This could be an expandable >data table, assumably). Padgett: might such a feature be incorporated into >the DiskSecure package? ( sorry for the long quote ) An idea of a program which knows all BIOS'es versions frightens if you think about a vast army of PC clones. I can suggest the following way of looking for true INT 13 address at run-time (stealth technique to hide from it can be invented too, surely): Scanner sets INT 01 ( single-step ) on itself and calls some function of INT 13, setting TF simultaneously. A handler of interrupt 01 traces the addresses through which the execution passes( until it returns to the scanner ). It is sure that BIOS INT 13 handler resides somewhere between segment adresses 0C000h and 0FFFFh. As soon as the execution gets into this region, a scanner stores current address and later use it as an entry point of INT 13 handler. Nice, isn't it? - -- - - Vasili Bykov -|- vasya@stack.fian.msk.su ------------------------------ Date: Tue, 16 Jul 91 06:51:52 -0700 From: Eric_Florack.Wbst311@xerox.com Subject: multi-compression From: dave@tygra.Michigan.COM (David Conrad) in #125: It may be worthwhile to note that after the first, subsequent compressions tend to yield much diminished returns unless the later compressors are far more efficient than the earlier ones. So I think it is unlikely that one would see multiply compressed files. For example, say I have an executable, P.EXE, which is 100k in size. I use LZEXE to produce, say, PLZ.EXE, which is, say, 70k (which is not unreasonable, I think). If I were to then try PKLITE and produce PLZLITE.EXE which might be 67k, would I bother with the extra loading time for such a small gain? Probably not. - -=-=-= What you suggest isn't very practical, and is nigh on impossible because of the following: Let's say I have an EXE that I've run through LZEXE. PKLITE, regardless of version will do a test on the file to see if the file is smaller after the compression is added. Since the file's already compressed, PK won't make the file any smaller, and will crash off, and inform the user that it can't compress the file.... leaving the file untouched. Same goes for the other way around. For this reason, multiple compressed files are not as large a concern in reality as it appears to be . Could such files be generated? Certainly, but not without substantial mods to either LZEXE or to PKLITE, or both... and as I've indicated in the past, I doubt the virus idiots have that much on the ball, for the most part, that they'd be able to pull such a thing off. - -=-=-= Of course, it's possible that someone might compress many executables in a batch, and not notice, or perhaps compress as a policy, and not care. - -=-=- Again, no. Both LZEXE and PKLITE won't touch the file in question, beyond an attempt to compress the file in RAM.... upon finding out they've been compressed, they'll quit without writing the newly compressed file. regards, E ------------------------------ Date: Tue, 16 Jul 91 17:22:01 +0700 From: "Donny Gilor" Subject: IBM's VSTOP scanning compressed files for viruses (PC) Ref: Sun, 14 Jul 91 13:55:41 -0400 RefFrom: MMCCUNE@sctnve.sct.peachnet.edu - Mike McCune The IBM VSTOP anti-virus program is currently IBM Internal Use Only which means that it can be only used by IBM employees. For that reason it is "little known" (as you mentioned). You are correct in saying that it detects viruses in compressed files by detecting the viruses as they are activated. On the other hand it IS fully supported and updated versions are obtained easily by IBM employees. VSTOP and other such tools are IBM Internal Use Only and the product version of VIRSCAN (version 2.1.2) is the only IBM anti-virus product available right now to the public. IBM is always checking new possibilities of what it can do to help in this area. Donny Gilor P.S. Thanks for the compliments! ("reliably detect viruses", etc) ------------------------------ Date: 16 Jul 91 15:00:04 +0000 From: vail@tegra.com (Johnathan Vail) Subject: Re: General definition part 1 (general) RADAI@HUJIVMS.BITNET (Y. Radai) writes: Rob Slade writes: >I must make mention, before I continue, of the work of Fred Cohen. >Dr. Cohen is generally held to have coined the term "computer virus" >in his thesis, published in 1984. Just for the record, the term "virus" (as we use it) was *not* coined by Fred Cohen. Cohen's use of it came from his advisor, Len Adleman (the "A" of the well-known "RSA" cryptosystem). Btw, Adleman has published a very formal treatment of viruses, full of esoteric Goedelian concepts like "partial recursive" functions (not to be confused with recursive calls in programming) and Goedel number- ing. Although I studied these things in Logic courses in my undergrad days, I've never had the time or patience to wade through Adleman's article, but if anyone's interested, the reference is: L. M. Adleman, "An Abstract Theory of Computer Viruses", Crypto 88, pp. 354-374. With a date of 1984 I think the term must have been in use before that. I know that I was writing viruses in 1980 and using the term virus to describe it. The "official" title was a 'worm', an error that is the reverse of the current abuses of the word virus. I got my idea for a virus for PCs after reading an article about research at PARC on a network 'worm'. I tried to write a similar program on an Apple ][ and succeeded in creating what we now call a virus. I remember in discussions that the term "virus" came up in describing it and talking of "infections". We even developed a "vaccine" that would protect against future infections. And all this right out of high school and in my freshman year of college in 1980. jv "Telephones and viruses, and the passion of it all Ground up in a porridge, and written on the wall" -- RH _____ | | Johnathan Vail | n1dxg@tegra.com |Tegra| (508) 663-7435 | N1DXG@448.625-(WorldNet) ----- jv@n1dxg.ampr.org {...sun!sunne ..uunet}!tegra!vail ------------------------------ Date: Tue, 16 Jul 91 16:25:36 +0000 From: mcafee@netcom.com (McAfee Associates) Subject: Re: McAfee on VSUM accuracy and Microcom (PC) c-rossgr@microsoft.COM writes: >>From: mcafee@netcom.com (McAfee Associates) >> >>Hello Ross, >> >>I've given Mr. McAfee a copy of your message [regarding the license >price for one machine to be able to use his scan product] >>..., but he hasn't typed up a >>reply yet. In the meantime, perhaps you could leave me your mailing >>address and/or fax number so that I could give that to John for a >>(faster) reply. > >I'd rather find out here publicly, if you don't mind: I know a lot of >people have recently had pricing questions regarding your company's >scan products and this might clear up a lot of confusion. > >Thanks. > >Ross Pricing depends on many factors such as the type of usage, number of machines, which programs, type of upgrades, and so forth. This makes it difficult to give you a simple response. If you (or Microcom) wish to obtain a license, please call McAfee Associates directly at (408) 988-3832, collect if you'd like (please state that it's either "Ross Greenburg" or "Microcom" calling) to obtain further information. Regards, Aryeh Goretsky McAfee Associates Technical Support - -- McAfee Associates | Voice (408) 988-3832 | mcafee@netcom.com 4423 Cheeney Street | FAX (408) 970-9727 | (Aryeh Goretsky) Santa Clara, California | BBS (408) 988-4004 | 95054-0253 USA | v.32 (408) 988-5190 | mrs@netcom.com ViruScan/CleanUp/VShield | HST (408) 988-5138 | (Morgan Schweers) ------------------------------ Date: 16 Jul 91 14:43:43 -0400 From: "David.M.Chess" Subject: Reply to Virus Bulletin (sorry for the length!) In a letter in the July 1990 Virus Bulletin, Roger Riordan complains that by stressing raw numbers of viruses detected, VB's reviews are not properly presenting the real benefits of some anti-virus programs. In a long reply to that letter, VB makes the following rather odd claims: - That there is a "selectivity" movement in the current anti-virus community, that advocates not scanning for viruses not known to be in the wild, or thought to be extinct, - That the movement was started by me and Ross Greenberg in a couple of VIRUS-L postings in May, - That the movement is motivated by a desire to cut costs by avoiding work, and to keep scanners with primitive scanning techniques from being slowed down by too many viruses, - That in the long run the most good will be done by those companies that resist this nefarious movement, and spend all their time gathering as many viruses as they can, and developing scanning techniques which will not be slowed down by having more viruses added, - That every functioning virus is "a threat", and no-one can say otherwise. I may of course have mis-represented some of the points in this summary; I hope not! The piece is not signed, and is therefore presumably by Edward Wilding, of whom I would generally expect better. My reply to it is attached; it will also be FAXed to VB, in hopes of being included in a forthcoming issue. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Dear Editor, I am writing to try to clear up a rather surprising confusion that I have evidently caused. In a reply to a letter in the July 1991 VB, the editor reprints (without permission) a posting of mine to VIRUS-L, and attributes to me by implication the opinion that, among other things, virus scanners should not scan for viruses not known to be in the wild, or thought to be extinct. I would like to state that that is not my opinion, and that I did not intend to give that impression in my posting (which, in fact, consists mostly of questions, not of statements or opinions). The fact that the IBM Anti-Virus Product, with which I have something to do, scans for at least as many "research" or "collector only" viruses as known-in-the-wild viruses should serve as evidence to the contrary. In fact, I doubt that any of the other anti-virus workers who have taken part in the discussion would agree to the theory of "selectivity" as the Editor states it. On the other hand, I would like to take this opportunity to outline a view that I *would* support, which I hope is sufficiently far from the naive "selectivity" view to avoid further confusion. As the anti-virus field continues to move past the butterfly-collector stage and into a more mature and responsible part of its life, anti-virus workers will quite naturally move beyond the simple questions of how many viruses they can find, and the details of what a specific virus does. To be of the maximum service to our customers and the community, we have to say more than "we know of these 400 viruses, and only if you buy our product can you be saved; the Snorfler virus, for instance, will erase all your data on alternate Thursdays". We must also be able to give some idea of which viruses are in fact the most serious threat, which are likely to become threats in the future, and what anti-virus measures are likely to be the most effective (after all, any reader of VB knows how to protect a single machine against all the most common viruses; the difficulty now seems to be to figure out how to protect an entire community or organization). In order to do accurate threat-estimation, and research into how viruses behave at the organizational or societal level, we need to know new kinds of things about viruses. We need to know what software sharing patterns are like, what causes some viruses to be common and others not, and which viruses are in fact common in the real world today. It is toward the answers to these sorts of questions that our most interesting current work is focused, and it was in an attempt to attack some of those sorts of questions that I made my posting to VIRUS-L. I think we in the anti-virus community *do* need to be selective, but not by simply ignoring viruses that are not in the wild. We need to be selective, instead, about where we concentrate our research, and be sure that we don't ignore the important large-scale questions because we are using all of our resources on just gathering all the viruses we can find. It's perfectly acceptable, and accepted, for an anti-virus worker today to say to the press "there are over six hundred viruses in the world", for a software maker to advertise a product primarily on the number of viruses it detects, and for a publication to rate products primarily on that number. In the future, though, I would hope that a responsible researcher would at least add "although only about 10% of them are actual threats", that a responsible software maker would at least say "including the 10% known to be in active circulation", and that a responsible publication would give the reader some idea of how a product performed against the most important subset of their very complete test set. Similarly, it would be very nice if collectors exchanging viruses with trusted peers would also exchange anything they know about the history or current status of the viruses involved, and not simply binary samples. I trust that as the industry continues to mature, all these good things will happen. One statement in the Editor's reply with which I would definitely disagree: he states in the caption to the excerpts from VIRUS-L that "no functioning virus can be classified as a 'non-threat'." That is not the case: anyone with much experience in the anti-virus field can say with confidence that, for instance, the MGTU virus, while it is technically a functioning virus, will never become any more widespread than a non-viral "arf-arf" style Trojan Horse would; the virus is just too slow-spreading and too obvious. To claim that we can always tell which viruses are the dangerous ones would of course be foolish; but to claim that we have no idea, and that all viruses must be treated the same way because they are all threats, would be equally inadvisable, and I'm sure that the Editor did not mean to make that claim. Thanks for the chance to clear this up! David M. Chess ------------------------------ Date: Mon, 15 Jul 91 15:39:43 -0700 From: p1@arkham.wimsey.bc.ca (Rob Slade) Subject: Special terminology DEFGEN3.CVP 910714 Specialty viral programs If we stick to a strictly "Cohenesque" definition of viral programs as only those which attach to specific programs, then there are some difficulties with defining other, similar, programs which reproduce themselves, but without being linked to a specific program. Unfortunately, although attempts have been made to address this issue, there is, as yet, little agreement as to the terminology. In early multitasking operating systems, programs often "broke the bounds", and would overwrite sections of other programs or data. Since this damage was generally random, the pattern of damage, when mapped, gave the appearance of twisting tracks which appeared and disappeared. This closely resembled the patterns seen when cutting through a piece of worm eaten wood, giving rise to the term "worm" for such rogue prgrams. One such program escaped not only from its own partition within the computer, but actually escaped from the orginal computer to another over an early computer networking system. The term "worm" has therefore come to be used to refer to viral programs which do not attach to specific programs, and, more specifically, to those which use network communications as a vehicle for spreading and reproduction. Two examples of this usage are the famous Morris/Internet/UNIX worm of late 1988, and the lesser known CHRISTMA EXEC mail worm of December 1987. This still leaves a class of viral programs which do not attach specifically to programs. There are actually many sub-groupings within this group, and there are within viral programs generally. However, European researchers, particularly those from France, often refer to such programs as "bacteria", rather than viri. In these areas of terminology there is often much debate about whether a given virus, or type of viral program, fits into a given class. Boot sector infectors, for example, would not appear to fit the definition of a virus as infecting another program, since BSI's can be spread by disks which do not contain any program files. However, the boot sector of a normal disk, whether or not it is a "system" or bootable disk, always does contain a program (even if it only states that the disk is not bootable), and so it can be said that a SI is a "true virus. copyrigh Robert M. Slade 1991 DEFGEN3.CVP 910714 ============= Vancouver p1@arkham.wimsey.bc.ca | "If you do buy a Institute for Robert_Slade@mtsg.sfu.ca | computer, don't Research into (SUZY) INtegrity | turn it on." User Canada V7K 2G6 | Richards' 2nd Law Security | of Data Security ------------------------------ End of VIRUS-L Digest [Volume 4 Issue 126] ******************************************