VIRUS-L Digest Friday, 1 May 1992 Volume 5 : Issue 98 Today's Topics: Re: Filler warning with SCAN & CPAV (PC) Re: Impossible error occurred in SCANV V89B (PC) Re: Misinfo detected (PC) Joshi virus hit me, 4/28/92. (PC) Re: Windows viruses? (PC) Re: windows viruses? (PC) Re: Filler warning with SCAN & CPAV (PC) Re: F-PROT Cascade false alarm... (PC) Help Form Virus. (PC) Re: Authentication of resident Anti-Viral programs (PC) Re: New Myths #1: Infection during format (PC) Re: New Myths #2: Boot viruses survive format (PC) Re: New Myths #2: Boot viruses survive format (PC) Virus Detecting Disk Cache/Modem Protocol (PC) StarShip (PC) New files on risc (PC/Unix) Review list (was A short commercial break (was Re: lies and damn lies)) Administrivia (duplicates, address change, FAQ update) 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.sei.cmu.edu or upon request.) 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: Tue, 28 Apr 92 16:03:07 +0000 >From: btf57346@uxa.cso.uiuc.edu (Bohr) Subject: Re: Filler warning with SCAN & CPAV (PC) Does anybody know if CPAV is planning to encrypt (hide of whatever) their scan codes in any upcoming version? It seems to me that ever fourth "virus" comes up from some scanner seeing CPAV in memory. This would seem agrivating for those that like Central Point's interface. Anybody know anything about it? Byron Faber - -- Question: What's the fastest way Internet: btf57346@uxa.cso.uiuc.edu to run Windows? btf57346@sumter.cso.uiuc.edu Answer: Turn the computer off. Byron "Bohr" Faber ------------------------------ Date: Tue, 28 Apr 92 16:13:55 +0000 >From: mcafee@netcom.com (McAfee Associates) Subject: Re: Impossible error occurred in SCANV V89B (PC) Hello Mr. van den Berg, Error 4494 can occur if SCAN "loses" the current path. Reasons for this include running SCAN from a task-swapper or multiuser operating system, or running SCAN from a disk drive to check multiple disks in the same drive. Unfortunately, you did not mention which options you are running SCAN with nor tell about your operating environment so I can not suggest a fix. If you can mail this information to me, I'd be happy to help resolve the problem. Regards, Aryeh Goretsky McAfee Associates Technical Support /original message follows/ berg@physik.tu-muenchen.de (Stephen R. van den Berg) writes: >I don't really know where to send the report, here seems like a good place. >The other day, scan v89b reported something like: > >Impossible error occurred: Error number 4494 > >And it immediately aborted. >Well, normally, I would not be so picky, but since it is a virus scanning >program, I'd very much like to know what this supposedly impossible error >is all about? > >Anyone from McAfee who cares to comment about this? >In case it helps, it was a 80286 running MSDOS 5.0 >- -- >Sincerely, berg@messua.informatik.rwth-aachen.de > Stephen R. van den Berg (AKA BuGless). berg@physik.tu-muenchen.de > >Real programmers don't just die, they produce core dumps. - -- - - - - McAfee Associates | Voice (408) 988-3832 | mcafee@netcom.com (business) 3350 Scott Blvd, Bldg 14 | FAX (408) 970-9727 | ObQuote: "Log... from Blammo" Santa Clara, California | | 95054-3107 USA | BBS (408) 988-4004 | CompuServe ID: 76702,1714 ViruScan/CleanUp/VShield | USR Courier DS 14.4Kb| or GO VIRUSFORUM ------------------------------ Date: 28 Apr 92 21:13:00 -0500 >From: "0000-BIOMETRICS/DATA PROCESSING" Subject: Re: Misinfo detected (PC) Tarkan Yetiser (TYETISER@ssw02.ab.umd.edu) writes: > Why not? Define "strong". Okay, I'll take a stab at it. My organization has several hundred PC's. A few of them use things like stacker, 4dos, etc. Were we to license VDS, most of them could be protected, but what about the rest? Wouldn't they basically be a weak link in the chain? You may have the strongest solution for some individuals, but for large sites, it does leave holes. We could buy a different package just for those few PC's, but why bother? It would be much less of a headache for us to just buy the other package for all of them, wouldn't it? Of course, for the time being, VDS is out of the question anyway since almost all of them are networked... >> very good package for a limited user base, but if it can't be run on >> every system configuration that someone might use, it's not a really >> viable package in the current market. I can (for example) user F-Prot, > > What is viable or not is arguable. We are content with the current >market situation. :-)) That's a lousy attitude. In any case, your surveys seem to be confined to individual users. What about large corporate/government/institutional sites? You would be hard pressed to convince me that networks are the exception, rather than the rule, with them. That's a pretty sizable chunk of the market you're excluding. > BTW, VDS 2.1 will be a lot more compatible than 2.0. VDSFSCAN, which is > roughly like F-PROT, can handle network drives (tested on Netware & > Banyan) and even CD-ROMs (to show compatibility), as well as compressed > disks and under DR DOS 6.0. VITALFIX will work under DR DOS 6.0. We added > a switch to avoid memory protection violation when EMM386.SYS is loaded. > VDS.EXE (integrity checker part), on the other hand, works only if you > have a non-compressed disk. Besides, we are trying to find a way to stop > it from removing DR DOS protection :-)) Doesn't really matter what the scanner is compatible with. In that department, you are competing with several other excellent products that are much more widely known. It's the integrity checker that makes VDS different. If I can't get that to work, then your product is _just_ another scanner. > just a simple change and requires reinstallation. Other changes such as > installing new software etc. are handled easily, and do not require > reinstallation. As long as VDS is compatible with the new software, that is. Folks who decide to try 4dos later on are in for a surprise. Not only do I have to worry about what I'm running now, but also what I buy in the future? Seems a bit much to ask. Whether you like it or not, compatibility _is_ an issue for any type of software. If any magazine included VDS in a comparative review, your overall rating would undoubtedly suffer (Of course, certain magazines will always favor CPAV anyway, because it's prettier. :-( ). If that happens, it won't make much difference who your product is targeted for, will it? I really hope you'll work on it. -Hutch ------------------------------ Date: Wed, 29 Apr 92 01:33:05 +0000 >From: rwr@po.CWRU.Edu (Robert W. Rutkowski) Subject: Joshi virus hit me, 4/28/92. (PC) This morning I noticed that every time I put a floppy in my b drive, the computer trashed all the files on it. I ran scan77 and was truly horrified to see the "Shut off your machine NOW!" message. How unpleasant! After a scramble to find a boot disk and a lot of fear and worry, I used clean77 and hopefully solved the problem. McAlfee identified the code as "Joshi." Have any of you encountered this one? It sits in the file partition table of the hard drive. I don't know what program caused it. I have been deleting stuff off of my system lately and McAlfee did not find it in any of the exec. files. I have a feeling I got the thing from a certain bbs to which I subscribe, but I withhold judgment until I hear from the sysop. His board is scanned daily. I can't imagine one got through. If anyone has any background on "Joshi" I'd love to hear it. ------------------------------ Date: Wed, 29 Apr 92 16:38:00 +1200 >From: "Mark Aitchison, U of Canty; Physics" Subject: Re: Windows viruses? (PC) sgr4211@uk0x08.ggr.co.uk writes: >> need to look at pretty darned quickly, although I doubt that a virus >> that requires MS Windows to be present would get very far at the >> moment. (but then again...?) > > I disagree. MS Windows is *very* widely used indeed! Yes (although they account for a small fraction of the total, and v3.1 much less common yet, let alone viruses written specifically for it). But the main point is that these particular viruses would require data files to be transferred, which often go less distance than executables - - you might give some nice utility to someone to play with, but most office files - word processing and whatever - tend to stay within the same office, so the rate of spread might be slower than others. >... So the virus could potentially sneak past > anti-virus software that isn't looking at, say, .WRI files. This is part of what worries me - but of course it is not just a case of looking in lots of different files, you'd have to look for new things. The point I was trying to make with: >> ... Any other extensions don't >> need to be scanned for general viruses but for specific viruses, to >> save time. was that it takes a lot of time to scan, and people (well, people around here) exchange data much more often than programs. If all files have to be scanned for more things, more often, there could be big consumer resistance. But I think that, since these data files would be special, it could be possible to speed up the search by restricting the list of scan strings - or the bytes to search - when dealing with certain types of file. But, as I understand it, you are worried that viruses might be missed by any scanners that at present skip areas of files they think wouldn't contain the viral code. I might still be confused (chat via e-mail, if you like) but wouldn't they have to be looking for totally different scan strings anyway? Presumably, if scan strings for any new virus like that are added, the choice of where to look would also be updated. I doubt that heuristic methods would have any chance of spotting such new viruses either. The only exception would be if the data file was used as a dropper for an existing virus, which would be a bit silly (if anyone goes to the bother of doing that, it will be spotted soon after the drop - surely the virus, if it uses this area in the first place, would want to either stay there or use new virus code, or both? Mark Aitchison. ------------------------------ Date: 27 Apr 92 23:11:00 +0100 >From: sgr4211@uk0x08.ggr.co.uk Subject: Re: windows viruses? (PC) rslade@sfu.ca (Robert Slade) writes: > We've heard from the authors of antiviral software that Windows is a > difficult environment to work in in any case. Having just attended a > technical seminar on Windows 3.1, I do not feel that OLE presents > further security problems. > > The "embedding" portion of OLE seems to refer only to printable > material, such as a chart, which was originally created by another > application. "Embedding" such objects in the body of a document > merely means that a record is maintained of the original application > for ease of amendment. Therefore, the executable, in this case the > original application, exists outside of the document. Have you tried it? I have, and I'm not convinced. I took a simple WRITE file of 640 bytes and embedded a copy of CALC.EXE (43,072 bytes) by dragging & dropping from file manager. The resultant file was 46,464 bytes, which is big enough for the original datafile, CALC.EXE and whatever information PACKAGER sticks in there. I conclude from this that the executable is indeed truly embedded, *not* a reference to it - that would be linking. It would appear that both embedding and linking may be carried out on either datafiles *or* executables. Double-clicking on the CALC icon which is embeded works just fine. I can only conclude that, if a virus which will be "viable" under Windows can attach itself to CALC.EXE, it *will* be active in the embedded version. I don't have access to a library of viruses. I haven't yet heard whether or not viruses (DOS ones or specifically-written Windows ones) can execute under Windows. In any case, I don't have sufficient experience/confidence with viruses to risk infecting some files to try this out (leastways on the firm's kit!). Could one of you anti-virus experts *please* try this out? Steve Richards. ------------------------------ Date: Wed, 29 Apr 92 08:33:27 +0000 >From: Fridrik Skulason Subject: Re: Filler warning with SCAN & CPAV (PC) kenm@maccs.dcss.mcmaster.ca (...Jose) writes: > A colleague has the following, peculiar problem: He loads the > CPAV TSR from his AUTOEXEC.BAT, and later tries to use McAfee's SCAN. The CPAV program is the only anti-virus programs which has serious compatibility problems with other anti-virus products, as far as I know. In fact, the manual states that CPAV should not be used together with anonter similar package. As it is generally a good idea to use a couple of scanners, the solution is simple....don't use CPAV.... - -frisk ------------------------------ Date: Wed, 29 Apr 92 08:51:01 +0000 >From: Fridrik Skulason Subject: Re: F-PROT Cascade false alarm... (PC) In Message 24 Apr 92 09:09:19 GMT, vaughan@computing-department.poly-south-west.ac.uk writes: >While scanning my hard drive with F-PROT 2.03a it picked up a possible >Cascade variant in an ascii *text* file, FIND1701.DOC. This is the doc >file that is supplied with FIND1701.COM a program that scans for and >removes the Cascade virus. The doc file has the string '141$FLu' which >also appears in the virus, and is also about 2100 bytes long. It is perfectly natural for my F-PROT program to produce a false alarm on this file. The string "141$FLu" translates to the following sequence of instructions: XOR [SI],SI XOR [SI],SP INC SI DEC SP JNZ ?? Any assembly language programmer should be able to recognize that these instructions are extremely unlikely to be found by chance in any program, which is exactly why I use this 7 byte string as one of my Cascade signatures. There is nothing that can be done about it - if somebody takes a portion of a virus, which just happens to include one of my signatures, and includes that code in a text file, my program might detect the string. However, note that the file is NOT reported as infected - only as possibly containing a new variant of the virus....F-PROT will for example totally refuse to disinfect it. - -frisk ------------------------------ Date: Wed, 29 Apr 92 07:51:36 +0000 >From: pftzgrld@unix2.tcd.ie (FUNGUS FROM YUGGOTH) Subject: Help Form Virus. (PC) About two days ago now I discovered that my Pc was infected with the form virus. I have checked my diskettes and discovered that a large number of them are infected as well as my hard drive. So I aquired a program called Deform which was written specially to deal with form virus since my normal virus program Scan dosn't deal with form. However when I booted up with a clean floppy and ran Deform it returned the message "Unable to read boot sector". Does this mean the virus has overwritten the boot sector of the hard drive? If this is the case is the only way of getting rid of the virus to reformat the hard drive? Also what are the actual effects of Form virus? Thanks in anticipation. Peter Fitzgerald. (mail:- pftzgrld @unix2.tcd.ie) ------------------------------ Date: Tue, 28 Apr 92 21:58:56 +0000 >From: duck@frcs.Alt.ZA (Paul Ducklin) Subject: Re: Authentication of resident Anti-Viral programs (PC) Thus spake padgett@hobbes.dnet.mmc.com (A. Padgett Peterson): >IMHO, such a capability is vital to the authentication of a machine from >a network server level on login (ref an equal number of comments reguarding >the virtues of client-server networks over peer-peer systems) Knowing your resident scanner is working is always a good idea. In the Novell environment, eg, any program which hooks Int 21h Function 4Bh *before* the redirector gets loaded is in big trouble when NETx does go resident -- the redirector quite naughtily takes over all respon- sibility (is that hyphenation right?) for Load_And_Exec. Forget your earlier hooks: they don't get called no more! I like resident scanners which blip and blink at you so you know that they *seem*, at least, to be working (which is why my own has just those features :-). As long as you can switch the sound off -- for some reason, users don't seem to share my taste! Paul Ducklin Somewhere near the middle of the City of Pretoria South Africa ------------------------------ Date: Tue, 28 Apr 92 21:32:37 +0000 >From: duck@frcs.Alt.ZA (Paul Ducklin) Subject: Re: New Myths #1: Infection during format (PC) Thus spake AMN@VMS.BRIGHTON.AC.UK (Anthony Naggs): >Was "Virus surv[iv]ing format". >> In a recent arcticle [New Scientist no.1813 p48] the author stated >> "...some viruses may transfer from floppy to hard disk DURING >> FORMATTING" {caps mine}. >> >To deal with this properly I need to quote more of the original item, >[New Scientist no.1813 p54 (Feedback column)], reproduced without >permission: > "... one idea .. to safeguard .. against .. a computer virus. > If you send someone data on a floppy disc, and it is returned, > reformat it to wipe everything clean before reuse. But be > warned, some viruses may transfer from floppy to hard disc > during formatting, before the process kills them. The trick > here is to format the floppy on a cheap and cheerful computer > which has has no hard disc, preferably a portable which has its > operating system stored in ROM. That way the virus has nowhere > to hide." I too noticed this in NS, and have written to them to query their "advice". The really silly part is the bit about reformatting discs sent back to you before reuse! Even in South Africa, floppy discs are so readily available and so cheap that throwing away a disc sent to you by a friend is probably more cost effective than posting it back -- and you don't have to buy stamps or walk to a pillar box. Ergo, one assumes that a disc returned to you has been sent back because it contains data (apparently, there are even people in the First World who aren't on the Net..) for your perusal. Formatting it would then be, in my book, a little precipitous! OK: I suppose they meant "format after you've lifted off the data". But they didn't say so, did they? And since when have portables with their OS in ROM been immune to viruses? Try the venerable Sharp PC-6220, for example -- and that neat little beast (286; <2Kg) doesn't even have a floppy drive! Paul Ducklin Somewhere near the middle of the City of Pretoria South Africa ------------------------------ Date: Tue, 28 Apr 92 21:47:28 +0000 >From: duck@frcs.Alt.ZA (Paul Ducklin) Subject: Re: New Myths #2: Boot viruses survive format (PC) A couple of years ago this myth got *lots* of coverage in the South African media -- and there were people who were ready to *prove* that a floppy format on a PC-clone could leave viruses behind. I seem to recall that there were theories that the little beggars (the viruses, that is, not the PC-clones) sneaked into the drive cables, or gnawed their way into the parallel port, or something, and reemerged, foaming at the mouth and raising two fingers (or one, if the virus had been watching American movies recently) at the PC community. Naturally, those with "proof" had been using one of those public domain multi-version hyper-format utilties which one needs to "prime" with a boot sector germane to one's own favourite DOS. They'd primed it with Stoned by mistake and made themselves high-performance droppers. Anyway, it was funny at the time. Paul Ducklin Somewhere near the middle of the City of Pretoria South Africa ------------------------------ Date: Wed, 29 Apr 92 11:18:00 +1200 >From: "Mark Aitchison, U of Canty; Physics" Subject: Re: New Myths #2: Boot viruses survive format (PC) I wrote... >> ... it IS POSSIBLE >> for viruses to survive the format process. If they were already on a >> 360Kb diskette's boot sector that is formatted on a 1.2Mb drive to >> 360Kb again there is a slight chance of the original tracks being >> readable on other 360Kb drives.. AMN@VMS.BRIGHTON.AC.UK (Anthony Naggs) writes: > Was "Virus surv[iv]ing format". > > For this to happen the heads on both drives must be out of alinement in > opposite directions. Because of the narrowness of of tracks & large > amplitude signals on a HD disk (1.2Mb) a HD drive with significant > misalignment would show up rapidly as being unable to read old disks or > exchange disks with other PCs. The computer being clearly faulty even > a naive user would call an engineer at this point. It isn't just theory, I've seen it happen, and no, the disk drives don't normally seem to be very faulty - they read everything they wrote, and most other 360Kb drives perfectly okay. It is very common for 360Kb disks to get data errors reading diskettes written by 1.2Mb drives, that is why there was a warning against doing so in some DOS manual I saw. The sector error rate is normally something like 4% and normally you'd never read the old data without CRC errors, but a significant number of drives will give you much much worse error rates, and sometimes read the old data off some sectors WITHOUT AN ERROR. As I say, I've seen it happen, and the drive didn't seen all that bad otherwise. If you want to write data on a 1.2Mb drive and read it on a 360Kb drive later, I always suggest wiping the disk with a magnet and formatting it on the 1.2Mb drive. Some people say to format it on the 360Kb drive, but you can get unreported errors this way (more likely you'd get reported errors, of course). Remember that 360Kb drives tend to be older, and never needed to be so accurately aligned in the first place. If anyone still has doubts, I could go into it further in e-mail, in the mean time think of what happens when the head is out of alignment away from the thin 96TPI head's track and in the direction of the rest of the rest of the 48TPI head's track. It gets all of its own track, half of a normal 360 Kb drive's track, but possibly almost nothing of the 1.2Mb drive's track. Of course the field from the 1.2Mb drive's head will extend a bit, but the question is what does it get most of. It will almost always get a mixture, in a perfectly aligned disk it will get about half the width from the new track (amounting to a lot more than half of the signal, probably), but the head doesn't have to be far out for the signal ratio to be about 50/50 (you get errors when it is even slightly close to that), AND it can/does happen that the ratio goes the other way sometimes! Not that I'm saying you'll get all of the old disk contents without an error, nor that I've seen it happen with a virus, and it isn't a "loop hole" a virus can exactly go out and exploit, but it is worth rememberring to write 360K disks on 360K machines, or wiping the diskette first with a magnet. Mark Aitchison, Physics is Fun, University of Canterbury, New Zealand. ------------------------------ Date: Wed, 29 Apr 92 11:33:38 -0600 >From: ST6074@SIUCVMB (Tim Williams) Subject: Virus Detecting Disk Cache/Modem Protocol (PC) Would it be possible to write a disk cache that checks data coming into and out of the cache for viruses? What I mean is: Every time a read is made, check it for viruses, and every time a block is written, check it too. I realize that this would have to be done at a very low level and that there would have to be an almost absolute assurance that nothing else can write to disk, but is this possible? What about a virus-checking modem protocol. I realize this wouldn't work for ..ZIPped files, and such, but it is absolutely possible for other files. .ZIP files could even be dynamically unzipped and then scanned. It would be a lot of work, but on a fast machine, it could be done. Any comments??? Tim Williams ST6074@SIUCVMB.BITNET ------------------------------ Date: Wed, 29 Apr 92 12:59:48 -0400 >From: padgett@hobbes.dnet.mmc.com (A. Padgett Peterson) Subject: StarShip (PC) Well, not having seen the virus itself, I do not know why it does not replicate. However, for those concerned about it, the SafeMBR code (v1.6 & later) contained in FixMBR will detect the changes it makes to the MBR and warn the user that "something" has happened. At this point, examination of the new table pointer should permit determination if StarShip is present. Reguarding the failure to replicate, I would have to ask if it has been tested on a PC containing VGA RAM memory. Like the Michelangelo never triggering on an XT, from what I have heard, the starship will not work unless VGA RAM memory is present. Warmly, Padgett ------------------------------ Date: Wed, 29 Apr 92 00:20:23 -0500 >From: James Ford Subject: New files on risc (PC/Unix) Though I haven't been sending out email lately, I *think* all the recent file uploads mentioned on Virus-L have been placed in risc.ua.edu in the directory /pub/ibm-antivirus. The C source code for Info-Zips' ZIP and UNZIP is now available on risc.ua.edu as /pub/zip10ex.tar.Z and /pub/unzip41.tar.Z. Many thanks to Info-Zip for getting unzip and zip to work on different operating systems. This is the latest listing of the files on risc.ua.edu. If you see something out of date, please drop me a line with an FTP site...or upload it to /pub/00uploads and send a short email to me. - ------ Contents of risc.ua.edu:pub/ibm-antivirus/0files.9204 ----------- 0files.9204 fixfbr11.zip sentry02.zip validate.crc vshld89b.zip aavirus.zip fixmbr24.zip stealth.zip vc300ega.zip vsig9204.zip avs_e224.zip fixutil3.zip tbresc18.zip vc300lte.zip vstop54.zip bbug.zip fp-203a.zip tbscan33.zip vcheck11.zip vsumx203.zip bootid.zip fshld15.zip tbscnx30.zip vcopy82.zip vtac48.zip ccc91.zip fsp_183.zip trapdisk.zip vdetect.zip vtec30a.zip checkout.zip htscan17.zip unvir902.zip vds20t.zip wcv201.zip chk.zip i-m111a.zip uu-help.text virlab14.zip wolfchk.zip chkint.zip innoc5.zip uudecode.bas virpres.zip wp-hdisk.zip clean89b.zip m-disk.zip uudecode.doc virsimul.zip wscan89b.zip cpavse.zip navm.zip uudecode.pas virstop.zip xxdecode.bas cvc192am.zip navupd01.zip uuencode.pas virus-l.faq xxdecode.c cvc192ma.zip netsc89b.zip uxencode.pas virusck.zip xxencode.c cvc192ms.zip pcv4.zip vacbrain.zip virusgrd.zip xxencode.cms cvc291at.zip pkz110eu.exe vaccine.zip virx22.zip cvcindex.zip scanv89b.zip vaccinea.zip vkill10.zip dir2clr.zip secur234.zip validat3.zip vshell10.zip - ------------------------------------------------------------------------ - ---------- Whoever profits by the crime is guilty of it. - ---------- James Ford - Consultant II, Seebeck Computer Center The University of Alabama (in Tuscaloosa, Alabama) jford@ua1vm.ua.edu, jford@seebeck.ua.edu Work (205)348-3968 fax (205)348-3993 ------------------------------ Date: Tue, 28 Apr 92 20:30:22 +0000 >From: rslade@sfu.ca (Robert Slade) Subject: Review list (was A short commercial break (was Re: lies and damn lies) ) PHYS169@csc.canterbury.ac.nz (Mark Aitchison, U of Canty; Physics) writes: >So a suggestion: >How about establishing a table, perhaps an Appendix to the FAQ... a >brief summary of anti-viral products, by category. It would have the >latest version number, and where you can get it, and the size (& >checksum?) of the archive, and some other information tabulated - >don't know what (I'd hate to say "number of viruses spotted", and >scores for documentation, etc would involve a lot of work for >somebody, although I know there are good reviews being done now). >... >What do others think? I think its a good idea, in fact, I've been working on various versions of it. But you're right, it's an awful lot of work. In fact, there are two versions of it extent right now. There is the "Contacts" list that I've been trying to maintain (which is now of auch a size that I can't put it all into one message, and which Ken is undertandably loath to publish in the digest), and there are the full reviews which are archived at cert, among other places. Keeping the contacts list up to date, and trying to keep up with the reviews (yes, I *have* received VDS, and the request for a review will move it up the list) is already a fairly major task. It is not eased by the fact that very few of the producers of the products I have reviewed have seen fit to keep me up to date. (F-PROT and IBM's VIRSCAN being notable exceptions, thank you frisk and Dave, and you deserve better action on updated reviews.) I can appreciate, myself, the need for "source" information regarding the latest versions and ftp sites therefore. I know that those who maintain the sites have the same problems themselves. I appreciate, and try to support, the recent postings from eugene and urvax as to the latest versions and uploads. For more information, I also try to keep current with the comp.binaries...archives groups, and use archie. Therefore, while Mark's suggestion will be a hard act to follow, it is a valid and useful exercise, and I will commit to try and put something together in the next few weeks. I will try to contain, in a quick format, something to do with the name, version, type/category, docs, ease and overall rating. I will appreciate any further suggestions as to what should be included, I will appreciate even more, while I try to get it together, if those who send messges will forgive me for not replying and possibly not using their ideas. :-) (For those wondering where to file the various files mentioned: Vancouver | "Kill all: God will know his own." Institute for Robert_Slade@sfu.ca | - originally spoken by Papal Research into rslade@cue.bc.ca | Legate Bishop Arnald-Amalric User CyberStore Dpac 85301030 | of Citeaux, at the siege of Security Canada V7K 2G6 | Beziers, 1209 AD ============= for back issues: Contacts list: cert.sei.cmu.edu, /pub/virus-l/docs/reviews Reviews: cert.sei.cmu.edu, /pub/virus-l/docs/reviews/pc Column: cert.sei.cmu.edu, /pub/virus-l/docs/slade.cvp.articles For those without ftp, see Jim Wright's posting, or use Cyberstore, via Datapac or direct at (604) 526-3676. Also FREQ from 1:153/733 The Cage 604-261-2347. ------------------------------ Date: Fri, 01 May 92 10:29:43 -0400 >From: Kenneth R. van Wyk Subject: Administrivia (duplicates, address change, FAQ update) The last two VIRUS-L digests that went out (96, 97) were inadvertently sent twice. I believe that this was due to the LISTSERV sending the two copies. Hopefully, the problem has been resolved. Thanks to those who alerted me to the problem - I do appreciate it when people let me know that something is broken. (I can't guarantee that I can fix the problem, of course, but I will certainly try.) Also, note that the moderator's network address is going to be changing soon from krvw@cert.sei.cmu.edu to krvw@cert.org. This shouldn't affect the vast majority of you, especially since the old address will continue to function. Finally, I hope to be updating and sending out a new copy of the FAQ shortly. Now is a good time to send in comments and requests for changes. I'll get to the updating as soon as I've installed OS/2 2.0 (it just arrived today!) on my home machine and completed some course work. Thanks, Ken Kenneth R. van Wyk Moderator VIRUS-L/comp.virus Technical Coordinator, Computer Emergency Response Team Software Engineering Institute Carnegie Mellon University krvw@CERT.ORG (work) ken@THANG.PGH.PA.US (home) (412) 268-7090 (CERT 24 hour hotline) ------------------------------ End of VIRUS-L Digest [Volume 5 Issue 98] *****************************************