VIRUS-L Digest Wednesday, 1 Apr 1992 Volume 5 : Issue 80 Today's Topics: Telephonica and Floppy Discs (PC) 639k on PS/2s (PC) Strange things... (PC) Re: Which Package is Best? (PC) Re: Which Package is Best? (PC) Re: Protection from Boot Sector Viruses (PC) Novell Security (PC) Re: Recovery from a New Zealand Strike? (PC) Stoned/SBC (PC) Re: Stupid questions about booting (PC) PC virus scanners under UNIX? (PC) (UNIX) Re: OS/2 bug or virus? (OS/2) COPS (security package) for VMS? (VAX/VMS) Re:Vax Virus & Patricia Hoffman (VAX/VMS) APL virus reference some 89B from McAfee Associates (PC) New files on risc Latest McAfee on beach and eugene (PC) New files on risc (PC) VSUMX203.ZIP is available on eugene (PC) Checklist part 7 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: 28 Mar 92 14:03:31 +0000 >From: Robert.Turner@brunel.ac.uk (Robert Turner) (Robert Turner) Subject: Telephonica and Floppy Discs (PC) Hi We have had a lot of experience with telephonica, but have just come up with a novel situation. Can anyone help (intellectual question, rather than physical). Our 386 machines run Dr. Solomons' Guard program along with an INT-13h modifier written by one of our people here that protects a small 'C' disc (with DOS etc). Anyway, I was carrying out a disinfection of telephonica as I have done hundreds of times before, typing 'XCOPY A:\ D:\TMP /S /E', without even doing a 'DIR' on the disc, prior to re-formatting. Anyway, Guard obediently put up a warning message, this was bypassed, and the disc motor started. Then without any warning the computer complained about 'Write Protect on Drive C' (from out INT-13h program). Now, nothing else was running, and therefore the only assumption that I can make is that somehow Telephonica managed to get executed. My question is whether it is possible for a boot sector virus to be executed by doing a 'DIR' or other directory access. I believe that this is impossible, however my experience yesterday gives rise to doubt. Thanks in advance, Rob - -- ________________________________________________________________________ / | \ | Rob Turner | email : Robert.Turner@brunel.ac.uk | | Brunel University | | | London, England | never an exciting moment | \____________________________|___________________________________________/ ------------------------------ Date: Sat, 28 Mar 92 10:41:25 -0600 >From: miguel@roxanne.nuclecu.unam.mx (Miguel de Icaza A.) Subject: 639k on PS/2s (PC) IBM PS/2 computers reserve 1Kb from conventional RAM for the ABIOS (Advanced BIOS) variables. Miguel de Icaza ------------------------------ Date: Sat, 28 Mar 92 10:51:43 -0600 >From: miguel@roxanne.nuclecu.unam.mx (Miguel de Icaza A.) Subject: Strange things... (PC) I Have a batch file who exchanges the config.sys in order to load or not to load the network, this morning, when I exchanged the files, I came up with this surprise: the files were'not exchanged, so I copied the little config.sys over the big config.sys (the one who load the net). I rebooted and nothing happend: the big config.sys was still there, then I erased the file and rebooted: config.sys was still there! I'm using DOS 5.0, I used debug to track down the DOS (I thought it was a virus), so I went with something like this: DOS is in segment 21, offset 87??, the first instruction is a CLI followed with some CMP (I think this is the selection routine), at first instance I thought this was a virus, so to be sure I run Thunderbyte Scan with the -direct option and I was right that was DOS, then I set Int 21h pointing there, the same thing I do with Interrupt 13h. Then I run chkdsk /f, it reported something like 61,000 bytes in lost clusters, when I told to CHKDSK to write the chages: the changes never appear in the root directory, the I rerun chkdsk and nothing happends. I rebooted n-times with a clean-dos-5.0-diskette, erase config.sys and there it comes again (when I reboot), I transfered DOS to the hard disk with SYS and nothing works: Worst of all: Any file written to the hard disk in the root directory gets erased as soon as I try to run a no-existent program. Then, i used Norton's SI to search in the device driver chain (looking for a virus in the driver chain), and with my clean disk and with the maybe- infected-DOS anything is equal. When I boot with the clean diskette nothing wrong happends, config gets deleted and programs run fine. Any ideas? Miguel de Icaza UNAM ------------------------------ Date: 28 Mar 92 11:48:13 -0500 >From: Wolfgang Stiller <72571.3352@CompuServe.COM> Subject: Re: Which Package is Best? (PC) trent@rock.concert.net (C. Glenn Jordan -- Microcom) writes: GJ> By the way, I don't think a CRC is superior to a proprietary GJ>Checksum for this kind of application. Checksumming is faster and GJ>though each individual checksumming method is sucessfully attackable, GJ>no one's has yet been attacked that I'm aware of, and the method is GJ>easy to alter between version updates. In the real world samples I've GJ>examined, duplicate checksums for different whole files have no real GJ>impact on the protection method. In my opinion, CRC's are a marketing GJ>gimmick pure and simple. Nice, particularly nice sounding, but not GJ>worth slowing down for, yet. The difference in relative GJ>"infallibilty" in the real world is not worth anything. "Not worth anything." Hmmmmm(?) I'm afraid I must disagree at least somewhat with what you're saying here, Glen. While it may not be worth adding a lot of code or significantly slowing down, CRCs certainly have significant value (at least relative to check sums). Checksums are susceptable to being oblivious to a rearrangement of data. This can happen to individual bytes or entire sectors or clusters (eg. when a defrag programs fails). GJ>In my opinion, CRC's are a marketing gimmick pure and simple. I can understand why you've decided that Virex wouldn't benefit from this extra protection, but it's absolutely vital for Integrity Master users to know that everything is back to normal in their files. Use of checksumming (exclusively) would leave the door open to some fairly common types of file corruption. By the way, this type of damage is more common than viral damage based on our customer reports. Since detecting viruses is just one job for Integrity Master I think you can see that CRCs are not merely a marketting gimick for us. Regards, Wolfgang Wolfgang Stiller Stiller Research 2625 Ridgeway St. Tallahassee, FL 32310 U.S.A. ------------------------------ Date: 28 Mar 92 11:48:54 -0500 >From: Wolfgang Stiller <72571.3352@CompuServe.COM> Subject: Re: Which Package is Best? (PC) bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) writes: WS> not safely disinfect the files. I don't fault the product in this WS> area (as far as I know it's disinfection capabilities are as good as WS> any other) but simply the claims made for it. How can you trust the VB>Well, it is difficult to compare. You cannot compare a generic remover VB>with a virus-specific one. The virus-specific one (if it is good VB>enough) will have a higher success rate, while the generic one will be VB>more safe, because it will not destroy any files... As you state, comparing generic and specific removal capabilities is difficult. I would not propose doing so. I agree, it is indeed a tremendous plus that UT will not "clean" a file which it can not do properly. Many other will fail to properly remove a virus and leave a user with a damaged files or an unbootable system. I find it frightening that (based on my surveys) most users are depending upon this flawed technology to recover from a virus attack. VERY DANGEROUS! And this reliance is pushed futher by UT's advertising. Speaking only for myself, I can not suggest someone use a product which may be technically OK, yet promotes this very hazardous practice. Since I believe some of us here on Virus-L may have some influence with the makers of UT, I believe that they may be persuaded to make their claims more realistic. Pardon me for continuing to hammer on this issue, but it is difficult enough for Stiller Research to compete with Fifth Generation Systems when Integrity Master is competing with a product which is perceived as disinfecting every virus now and forever due to the advertising. While few readers of Virus-L may buy such a claim, the opposite is true elsewhere including the FIDO virus echos where exactly such claims have been made for UT. Regards, Wolfgang Wolfgang Stiller Stiller Research 2625 Ridgeway St. Tallahassee, FL 32310 U.S.A. ------------------------------ Date: Fri, 27 Mar 92 08:37:10 -0700 >From: Subject: Re: Protection from Boot Sector Viruses (PC) bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) writes: > ... I only didn't like that the program (as far as I > understood) "corrects" the boot sector if it thinks it's wrong. I agree with your concern. Was that what R. Riordan was suggesting? Maybe P. Stuckey could post a clarification. > This must be done only when the user explicitely requests it, and the > original contents of the corrected boot sector must be saved in a > file. I hate the "I know better what programs you must be running" > approach. Yes, agreed. >> How do you find the Int13 entry point? Simple, really. Use >> DEBUG to search system ROM for typical int13 code, and try it: > >> C:>DEBUG > >> - - s f000:0 l FFFF 80 FA 80 > > Good guess... But totally wrong. :-) On my XT the INT 13h handler for > the hard disk is on the hard disk controllers's EPROM and is at > address 0C800:0000h. Well, not totally wrong. It works for all the 286 and 386 machines I've tried it on so far (I used to have an XT around here somewhere:-) And if you don't find the code as suggested above, that should be a clue that there may be a ROM BIOS extension, in which case the second method I suggested should work. >> look at the first offset reported, and back up a byte (or two) if >> the preceeding bytes are FB (or FC). That will be your entry >> point. Un-assemble the code to make sure it looks like an >> int13 service routine, then try it. > Are you serious is proposing the average user to perform the above > operation, in order to install the anti-virus program? The same user > who can't make the difference between a boot sector and a partition > table and between a virus and a spreadsheet? No, certainly not! :-) It was my understanding that R. Riordan was personally installing this, not user-installed. You are correct in pointing out that this must only be done by someone who understands what they're doing. BTW, another check you can do before trying to run the code is to search the BIOS for the code "MOV AX, ####", where #### is the offset of the start of what you think is the INT13 entry point. (The BIOS has to load the vector into low memory, and this code snippet seems to be fairly universal on the machines I've looked at - with the exception of some Compaq's. But, all revs of Compaq system BIOS I've seen so far always have INT13 entry at 02E12H; does anyone know of an exception? Compaq BIOS can be identified by the string COMPAQ at F000:FFEA). >> Another (sure-fire) way is to write a small machine-code program >> to replace the boot sector of a diskette. This program just >> grabs the Int13 vector (before DOS or any virus can change it) >> and displays it on the screen. > This sounds much better... Yes, this is preferred approach. This should also work for your XT :-) ( It works for our machines with Hard-Cards installed, which have ROM BIOS extensions for INT13 ). > ... Another idea is to trace INT 13h (like some > viruses do). Interesting... I had considered that, but there seemed to be too many pitfalls to implement it reliably. Ether (ether@enc.gedlab.allied.com) ------------------------------ Date: Sun, 29 Mar 92 10:31:00 -0500 >From: WHMurray@DOCKMASTER.NCSC.MIL Subject: Novell Security (PC) >I can tell you only about Novell. It provides two levels of >protection: file attributes and file access rights. The file >attributes are essentially the same as in MS-DOS and provide the same >level of security (i.e. - none at all). Over stated. DOS attributes are implemented in a single-user single-state environment. Therefore they can be reset by any process running in the target system. Many common viruses that use the DOS interface, as a matter of convenience and course, simply set all file attributes OFF. Novell attributes are an extension of DOS attributes. They can be set with normal DOS facilities such as ATTRIB. However, they are implemented in a multiuser multiple-state environment. That is, the server is an independent process protected from interference on the part of the client workstation. The Novell server will reset the file attributes only for a workstation operating with privilege with respect to the target directory or file objects. The user of the workstation authenticated to the server must have MODIFY rights for the target server object. This mechanism is reliable and is not bypassed by any common virus. Therefore, the use of attributes such as HIDDEN, SYSTEM, and EXECUTE-ONLY is recommended to resist infection with a virus. As with almost any mechanism for resisting viruses, this one is less than 100 percent effective, in part because user privileges are usually sufficient for a virus to spread. If the user of the client workstation has MODIFY or SUPERVISOR privileges, then the virus can use that privilege to set all attributes off. The problem arises when those users with such privileges logon to the server from a workstation that is already infected with a (file infecting) virus that attempts to set attributes off. In the face of the same behavior, the only difference between the effectiveness of the ATTRIBUTES and ACCESS RIGHTS is that there are many viruses that attempt to reset the former and none that attempt to alter the latter. That is, the difference is in the behavior of the virus rather than in the effectiveness of the mechanisms. As VB points out, it is important that server privileges not be used routinely. In addition, it is important that privileged users never logon to a server from an infected workstation. That is, a privileged user must logon only from workstations which they initialize from known and trusted sources (e.g., WRITE-protected diskette). William Hugh Murray, Executive Consultant, Information System Security 21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840 203 966 4769, WHMurray at DOCKMASTER.NCSC.MIL ------------------------------ Date: Mon, 30 Mar 92 18:19:00 +1200 >From: "Nick FitzGerald" Subject: Re: Recovery from a New Zealand Strike? (PC) bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) wrote: >CCTR132@csc.canterbury.ac.nz (Nick FitzGerald) writes: > >> The New Zealand virus can't be much more like Stoned than it is, being a >> (somewhat common?) psuedonym for Stoned. New Zealand is not "nasty" - > >Well, I thought that it's the alias for Stoned-2, that is, the variant >which puts the original MBR at 0,0,2. It is my understanding, that >this was the "original" virus, as programmed by that New Zealand boy. As we seem to be playing a little "one-upmanship" here 8-), I'll just chip in that I heard and read many references to "New Zealand" as an alias for Stoned well -before- I ever heard of Stoned-2. One commonly available reference is on p.62 of Highland's "Computer Virus Handbook" - this is copyrighted in 1990, but from the contents I'd say mostly written the best part of a year prior to that. (Note: I didn't say this is a definitive reference - just an example of an "early" reference to "Stoned" as "New Zealand".) >> Normally (if there is such a thing), as part of infecting a HD Stoned >> moves the original Master Boot Record from absolute sector 0,0,1 to abs >> sector 0,0,7 (James Bond has a lot to answer for). It then writes the > >Ahhh, of course! I was always wondering why the hell it uses sector 7, >while sector 2 is much more "obvious"... Now I understand... As an aside - I've lost track of how many times I must have typed "0,0,7", and it was only whilst typing that reply the other day that this thought struck me ... >> Assuming your user has not done something remarkably silly (like "format >> c:") then you may be able to recover by simply moving the original MBR >> back to 0,0,1. Norton's Utilities and several other disk/sector editors > >Ooops, error. FORMAT C: will rewrite the boot sector of the DOS >partition, not the MBR. It will also wipe out the FATs, so "restoring" >the MBR won't help a lot... FORMAT C: is "remarkably silly" with Stoned -if- the HD was partitioned with an old or "odd" version of DOS (How many users know what their HD's were partitioned with?). It is also "remarkably silly", as Vessilin points out, in that -all- file linkages, etc will be lost, whereas without it, often most files can be reconstructed if no satisfactory backups exist and the contents are worth the time and effort. Regards, +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Nick FitzGerald, PC Applications Consultant, CSC, Uni of Canterbury, N.Z. Internet: n.fitzgerald@csc.canterbury.ac.nz Phone: (64)(3) 642-337 ------------------------------ Date: Mon, 30 Mar 92 09:17:57 -0500 >From: d246@uni05.larc.nasa.gov (Braden Glen) Subject: Stoned/SBC (PC) Over the weekend, my boss was doing some homework on the PC. He wasn't having much luck with a simulation program that was given to members of his class, by the instructor. As an after thought, he ran a scan against the disk which reported (as he related) NO-INT [STONED]. He ran a scan against the PC and the scan found nothing. He then ran CLEAN against the disk and it reported that STONED was cleaned off. This morning as a precaution, we ran the scan on F-PROT against the HD. It reported that one of our programs was infected with SBC. We rebooted the machine, to clear anything that may cause a false positive and reran F-PROT. It reported SBC again, on the same program. We ran SCAN86 which reported nothing. We ran CLEAN86 against that program which came up nil, then we reran F-PROT with a disinfect, which reported that it was unable to disinfect the program. I am pretty sure that this is a false positive that we are getting, but I need to make sure. Any suggestion as to how to verify either way? Glen Braden Database Analyst d246@uni05.larc.nasa.gov ------------------------------ Date: 30 Mar 92 20:25:35 +0000 >From: jesse@gumby.Altos.COM (Jesse Chisholm AAC-RjesseD) Subject: Re: Stupid questions about booting (PC) LIBBIE%PUCC.BITNET@BITNET.CC.CMU.EDU (Libbie Counselman) writes: : I've been reading this list for a while, and have some general : knowlege about boot sector viruses, etc., but there are some definite : holes in my knowlege. : : Here is what I feel I already understand: : : - There are boot sectors on both hard disks and floppies. : - If a floppy is in the A: drive when the machine is booted, the : machine will read its boot sector even though the floppy may not : be a bootable diskette. If the floppy is infected with a boot : sector virus, this action will infect the hard disk. : - The partition table, which defines partitions on the hard disk, : is in the Master Boot Record on the hard disk. It may or may not : become infected, depending on the virus. : : Here are some of my confused loose ends: : : - What is the difference between the Master Boot Record and the : boot sector? Each hard disk has one MBR which holds enough code to keep going and a Partition Table describing where the rest of the hard disk information starts. Each partition on the hard disk has a Partition Boot Sector, which is functionally much like the Floppy Boot Sector. This has enough code to find the operating system files and get them started. : - Do only hard disks have Master Boot Records? Or are they found : on floppies, too? Only on hard disks. : - If a disk has a Master Boot Record, does it *also* have a *separate* : boot sector, or does the Master Boot Record house the boot sector? There is one Master Boot Record per hard disk. Each partition has a Boot Sector. : - If a hard disk has only one partition (e.g. a "C:" drive, but no : others, right?), is there a partition table? Yes. : - I assume that DOS's 2 hidden files are stored in either the boot : sector and/or the Master Boot Record (MBR), correct? Which one? : What else, besides the partition table, and viruses, can be : found there? Wrong. They are files in the normal file area of the partition. They are marked with the HIDDEN and SYSTEM bits. The Boot Sector has code to go find them, load them in memory, and execute them. : - What exactly happens when the machine reads the boot sector? Or : the Master Boot Record? For example, does it first look for DOS's : hidden files? Does it look for something else? Where does it go : next and how does it know where to go next? Basically: hard disks: BIOS reads MBR BIOS executes MBR MBR reads PBR MBR executes PBR PBR reads IO.SYS and MSDOS.SYS (or whatever) PBR executes these files MSDOS.SYS sets things up and reads the CONFIG.SYS etc. floppies: BIOS reads FBR FBR reads IO.SYS and MSDOS.SYS etc... : If my questions cannot be answered the way I've asked them, could someone : recommend a good resource for me to get a clearer idea of what's going : on when a machine boots? : : Thanks, : -Libbie C. - -- | O sibili, si ergo. ==> Oh, see, Billy; see 'er go. | Fortebus es inero. ==> Forty buses in a row. | O nobili, demis trux. ==> Oh, no, Billy; them is trucks. | Si vatsinum, causandux. ==> See what's in 'em, cows and ducks. ------------------------------ Date: Sat, 28 Mar 92 20:31:41 -0800 >From: John Paul Morrison Subject: PC virus scanners under UNIX? (PC) (UNIX) Are there any (PC) virus scanners that run under UNIX? I think this would help isolate the user from a possible virus. For example, we have Suns which have floppy drives: it would be safer (in a way) to scan the boot sector and the files on the Sun, since there is no way for a PC virus to infect a Sun. We also get files through ftp, so a virus checker on the Sun would also help with this route of infection. - -- __________________________________________________________________________ John Paul Morrison | University of British Columbia, Canada | Electrical Engineering | .sig closed for repairs | jmorriso@ee.ubc.ca | ________________________________________|_________________________________ ------------------------------ Date: Mon, 30 Mar 92 23:38:03 +0000 >From: meyer@ux1.cso.uiuc.edu (Don Meyer) Subject: Re: OS/2 bug or virus? (OS/2) csvcjld@nnomed.bitnet writes: > I'm running OS/2 1.3. Under OS/2, XCOPY does not change the >dates of the files it copies. In the DOS box, the files created by >XCOPY have their dates set to the current date. The resulting files >are the same size as the originals and COMP says they are the same. >Is this a known OS/2 1.3 bug? Or, do I have a virus? Probably a bug -- the same behaviour is not present under the current OS/2 v2.0 beta (6E.304), but I cannot verify under v1.3 as our machine has no DOS box. Don Meyer dlmeyer@uiuc.edu ------------------------------ Date: Mon, 30 Mar 92 15:31:33 +0000 >From: zwbm07@hou.amoco.com (Walter Moore) Subject: COPS (security package) for VMS? (VAX/VMS) Hello, A co-worker of mine asked me if there is any software for VMS that provides the same functionalty for VMS that COPS provides for UNIX. Since I didn't know, I thought I would ask the guru's. Of course, it would be preferable that the software be as expensive as COPS ;). If this software exists, what exactly does it do? Where can I get it? what's it called? Thanks for your help! - -- TTYL & TANSTAAFL ---------------- Walter Moore Internet: zwbm07@hou.amoco.com ------------------------------ Date: Mon, 30 Mar 92 15:35:18 -0600 >From: mike@tfred3.me.uic.edu (Michael E. Polhemus) Subject: Re:Vax Virus & Patricia Hoffman (VAX/VMS) Roy Coates writes: >1. Has anyone ever come across a virus targetted at VAX/VMS ?? Yes, I have seen a few... I have also seen several Trojans written for VMS systems. If you think you may have one, I'll be happy to discuss it with you through e-mail. There are some system routines which can be very beneficial in detecting/stopping these. Mike _=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_ Michael E. Polhemus University of Illinois @ Chicago Network Administrator Department of Mechanical Engineering Internet: mike@fred.me.uic.edu 842 W. Taylor, Rm 3076 ERF (m/c 251) Bitnet: u49083@uicvm Chicago,IL 60607 Office: (312) 996-9603 Lab: (312) 413-2318 _=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_ - -Mann ist was er isst -Heidegger ------------------------------ Date: Sun, 29 Mar 92 09:39:00 -0500 >From: fc Subject: APL virus reference The reference to the word "virus" in the APL article was only to point out that the term was used in that context for modified versions of APL opers and (if you read my paper from a good copy) was not an example of the sort of thing being discussed in the paper. The first computer virus I am aware of was demonstrated in the 1930s by John von Neumann (a theoretical one of course). The first real virus I am now aware of (real taken to mean an implementation on a working computer) was written in the late 1950s. It was the first backup program that copied itself onto the backup media and could be run from there. I know of several such systems that operated on punched paper tape in the 1960s. Of course some might claim that the first "bug" in a computer met the definition of a virus because it was a self-replicating biological entity, but I am not certain that it can actually be run by a computer, and I am quite certain that after being run, it didn't replicate - it died! The first virus given that name was described in 1984 and demonstrated in November of 1983. The first network viruses I am vaguely aware of were supposedly written in the 1960s, but this is all quite fuzzy since there were only indirect reports of these events in the Shoch and Hupp paper, and therefore, tyhey cannot be accurately verified. The first virus that can be accurately verified as such and which was used for the purpose of attack rather than experiment was launched in the middle 1980s. I am sorry I cannot give further details. If you want to read about viruses, the little black book is not really that informative. I had the chance to ask the author why he used source code instead of pseudo-code (on a radio show in New York), and he said that he just didn't think it was as informative to provide pseudo-code as to provide real code. He did not seem particularly malicious nor did he seem unreasonable. Perhaps we should seriously consider the good and bad points of publishing a book on viruses with real virus code. As to integrity checkers, it is clear from your many articles back and forth on the subject that most of you haven't thought the matter out very well. There are and have been integrity checkers that defeat all current and probably most future stealth viruses - even in the partition table! Several integrity checking systems are "perfect" at repairing infected files that they are able to repair. The ASP Integrity Toolkit either does it right or tells you that it couldn't (assuming you have not told it to be silent about things). By the way, I now have an at least relatively permanent temporary network mailing address. DO NOT USE THIS TO SEND PRIVATE MESSAGES - If you want confidential communication with me, I am now providing RSA messaging for the PC, and you can use my system to do this. Get in touch with me for details. Fred Cohen ------------------------------ Date: Sun, 29 Mar 92 07:07:00 -0500 >From: HAYES@urvax.urich.edu Subject: some 89B from McAfee Associates (PC) Hello. This short note to announce the availabilkity of: CLEAN89B.ZIP NETSC89B.ZIP SCANV89B.ZIP VSHLD89B.ZIP in our site. wsmr-simtel20.army.mil and oak.oakland.edu have also these files. - --- Site: urvax.urich.edu, [141.166.1.6] (VAX/VMS using Multinet) Directory: [anonymous.msdos.antivirus] FTP to urvax.urich.edu with username anonymous and your email address as password. You are in the [anonymous] directory when you connect. cd msdos.antivirus, and remember to use binary mode for the zip files. - --- Best, Claude. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Claude Bersano-Hayes HAYES @ URVAX (Vanilla BITNET) University of Richmond hayes@urvax.urich.edu (Bitnet or Internet) Richmond, VA 23173 ------------------------------ Date: Mon, 30 Mar 92 00:33:53 -0600 >From: James Ford Subject: New files on risc The following files have been placed on risc.ua.edu (130.160.4.7) in the directory /pub/ibm-antivirus for anonymous FTP: cvcindex.zip - Computer Virus Catalog Index cvc192am.zip - Amiga cvc192ma.zip - Macintosh cvc192ms.zip - MS-Dos cvc291at.zip - Atari >From March 30, 1992 til April 6 the University of Alabama will be on break. risc.ua.edu will remain up during this time, but mail to the accounts of jford@ua1vm.ua.edu, jford@risc.ua.edu and jford@seebeck.ua.edu will not be answered as quickly as usual......... - ---------- Anger is a wind which blows out the lamp of the mind. - ---------- 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: Mon, 30 Mar 92 10:57:26 -0600 >From: John Perry Subject: Latest McAfee on beach and eugene (PC) The latest version of the McAfee suite of anti-viral software (89B) is available on eugene.gal.utexas.edu (129.109.9.21) and beach.gal.utexas.edu (129.109.1.207). If you have any problems obtaining files, please contact perry@eugene.gal.utexas.edu - -- John Perry - perry@eugene.gal.utexas.edu ------------------------------ Date: Mon, 30 Mar 92 15:35:09 -0600 >From: James Ford Subject: New files on risc (PC) The following files have been placed on risc.ua.edu (130.160.4.7) in the directory /pub/ibm-antivirus for anonymous FTP: vsumx203.zip - Virus Summary List, March 1992 scanv89b.zip - McAfee's Scan v89b clean89b.zip - " Clean v89b vshld89b.zip - " VShield v89b netsc89b.zip - " NetScan v89b - ---------- Experience varies directly with equipment ruined. - ---------- 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: Mon, 30 Mar 92 11:56:15 -0600 >From: John Perry Subject: VSUMX203.ZIP is available on eugene (PC) VSUMX203.ZIP is available for anonymous ftp on eugene.gal.utexas.edu (129.109.9.21). It will be available on beach.gal.utexas.edu as soon as possible. If you have any questions or comments, send mail to perry@eugene.gal.utexas.edu - -- John Perry - perry@eugene.gal.utexas.edu ------------------------------ Date: 28 Mar 92 18:29:00 -0800 >From: Robert Slade Subject: Checklist part 7 Antiviral checklist - part 7 For each office: (cont.) _ Log of disks/programs received Many large companies think they already have this. Many smal companies see this measure as far too draconian. As usual, the truth lies somewhere in between. Corporations, both large and small, and government departments, often have policies restricting the use of software. Usually these schemes make some statement regarding bringing disks and software into the office. These policies are, of course, universally disregarded, even by those who drafted them. Such procedures are unnecessarily restrictive, unworkable, and fail to address the issues that prompted them in the first place. The intent is good. The institution wishes to protect the copyright of authors and other companies (or at least wishes to avoid being sued for failing to do so). The policy is also supposed to prevent the intrusion of viral and trojan software into the company, and, in some cases, the extraction of sensitive data from company files. Unfortunately, I have yet to see such a policy which actually does so. In most cases, the procedures are both insufficient to the intended outcome, and damaging to normal business practice. I will use some examples from the government of Canada. (Anyone gloating over the foolishness of this institution does not know the policies within their own company.) The Treasury Board is the governing body in financial matters, and therefore publishes directives covering pretty much all aspects of federal government practice. Several years ago, it published a circular stating that all computer related software or hardware had to have an associated purchase order before it entered government premises. At first glance, this would appear to be sound, and even an advantage for software companies. Not so. If you are reviewing software, a local government office cannot afford to purchase the necessary variety of software and still keep within its budget. Of course, it *is* possible to cut a P.O. for the software for no money. This takes about as long as the review process itself, as well as potentially putting the software company at risk (there being other policies regarding minimum and maximum pricing). Even if you intend to purchase the software next fiscal year, you cannot review it in this fiscal year if you have no funding left for that line item, or cannot afford to "lose" that funding this year. copyright Robert M. Slade, 1992 PRTCKL7.CVP 920328 (to be continued) ============== Vancouver | "A ship in a harbour Institute for Robert_Slade@sfu.ca | is safe, but that is Research into rslade@cue.bc.ca | not what ships are User CyberStore Dpac 85301030 | built for." Security Canada V7K 2G6 | John Parks ------------------------------ End of VIRUS-L Digest [Volume 5 Issue 80] *****************************************