VIRUS-L Digest Thursday, 26 Sep 1991 Volume 4 : Issue 174 Today's Topics: Virus Scanner Test Info Required (PC) Procedures Involving Potential Virus Files (IBM VM/CMS) desouza or souza virus (PC) re: Precise identification (PC) Reaction and Philosophy Re: Novell Various SITELOCK (PC) re: Precise identifications Re: Possible Autocad virus (PC) Wanted : a utility to warn me when I'm accessing a removable disk (PC) Re: Procedures Involving Potential Virus Files (IBM VM/CMS) Re: Need Info on Integrity Shells 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: Wed, 25 Sep 91 11:35:00 >From: White_D@cc.curtin.edu.au Subject: Virus Scanner Test Info Required (PC) I don't want to start any flames about the efficiency or otherwise of different virus scanners, but has anyone tested a range of products to determine just how good they are? In particular, I am interested in a comparison between McAfee's products and VirusBuster. We are prohibited from using McAfee's products as the site licence was too expensive and must now use VirusBuster. If anyone has tested these two products, I would welcome your comments. If you post directly to me, I will summarize for the newsgroup. [Ed. Have you taken a look at the reviews that have been posted to the group? They're archived on the anonymous FTP on cert.sei.cmu.edu in pub/virus-l/docs/reviews] Thanks, David White. Department of Chemical Engineering Curtin University Bentley, Western Australia. ------------------------------ Date: Wed, 25 Sep 91 09:05:03 -0500 >From: Ron Wigmore Subject: Procedures Involving Potential Virus Files (IBM VM/CMS) Relax! This is just a request for 'policy' information! :-) We have RSCSV3 checking for files that may be potential viruses (such as CHRISTMA exec, etc.). We just had someone try to send such an exec out. As it turns out, the exec is harmless and the user just picked a bad name for his exec. What do other sites do at this point? Do you just discard the file, with or without telling the user? Do you rename the file and send it on off to its original destination. Do you tell the people on your system that files of a certain filename and filetype cannot be sent out over the network? This is the main stumbling point. If you tell the users which filenames/types cannot be sent out over the network, then anyone wanting to cause some trouble will just rename the file and then send it out - defeating the reason for checking for specific files in the first place. How do other sites handle these matters? Reply via email if this is a 'sensitive' topic. Ron,,, ------------------------------ Date: Wed, 25 Sep 91 08:44:00 -0500 >From: tneuhaus@uwspmail.uwsp.edu Subject: desouza or souza virus (PC) Two faculty here at UWSP have reported that their home PC's have been infected with the "desouza" or "souza" virus. I looked through FPROT 2.0's list of virus information, but could not locate a reference to either name. I have not yet gone to their homes to try to use FPROT 2.0 to clean their disks. I might find out at that time that these are known viruses and will be easly cleaned. But, wanted to ask ahead of time if anyone knows of viruses with these names. Thanks, Tom Neuhauser tneuhaus@uwspmail.uwsp.edu Information Technology, University of Wisconsin, Stevens Point, WI ------------------------------ Date: Wed, 25 Sep 91 11:18:42 -0400 >From: padgett%tccslr.dnet@mmc.com (A. Padgett Peterson) Subject: re: Precise identification (PC) Reaction and Philosophy >Consider the implication of a system with a fixed disk separated into >tworeoccuring system crashes - the whys >would take all day and considerable lubrication) and contains all >executables. I do not know how the preceeding garble (from issue 173) occurred but it destroyed the meaning of the posting. The concept presented was to consider a PC divided into two partitions: one locked from writing and containing only executables. the other writable but not executable. There could be provision for an executable/ writable partition as well for development. Updates of the executable/ unwritable area would be accomplished via user disrection with a special command format. This is not a pipe dream, I have been using something similar for some time. It is done with software. Being software, it is breakable, but being PC specific, generic software to break it would have to be very complex - far beyond the level of sophistication seen in malicious software thusfar. It would take an intruder some time to capture enough data to bypass manually and resonable procedure on the part of the user is enough to reduce this risk. Add in a secure BIOS, prevention of the three-finger-salute, and a good integrity manager and you have reduced risk to the point where any increase in protection would be lost in the noise. Padgett ps I am getting tired of hearing why things will not work in some obscure instance, e.g. a Ferrari makes a poor dump truck. The simple fact is that use of ANY commercial anti-viral utility (and many non-commercial) puts a user way out beyond the third sigma in liklyhood of a damaging infection. ------------------------------ Date: Wed, 25 Sep 91 11:49:38 -0600 >From: kev@inel.gov (Kevin Hemsley) Subject: Re: Novell In VIRUS-L Volume 4 : Issue 17, I wrote: > I recently presented a paper on virus protection to a group of network > administrators. Most if not all of these people relied on the Read > Only ATTRIBUTE to protect files. This measure is just as ineffective > as setting the DOS Read Only file attribute. Most parasitic viruses > simply alter these bits before infection. In a personal reply, Steven Klepzig wrote: > Hello there. I read your post to the VIRUS-L list with interest. I can't > believe that anyone would actually trust just the file attributes to protect > a network. Even I saw the folly of that one! We definitely use the Netware I think that I may have been a bit misleading in my comment. The network administrators that I spoke with did use rights, but they felt that within the directories they had given access to, use of the Read Only attribute would prevent viral infection. I have found that many "computer professionals" have ingored viruses until they experienced a problem. Those which have not really considered what viruses truly are, often make obvious mistakes such as this. I have had degreed professionals ask me if viruses are some kind of "freak of nature," like a program gone mad or something. So I continue on my trek of educating users and support employees about the realities of viruses, hopefully eliminating false conceptions and undue paranoia. - ------------------------------------------------------------------------------- Kevin Hemsley | Information & Technical Security | If you think that you have someone Idaho National Engineering Laboratory | eating out of your hand, it's a (208) 526-9322 | good idea to count your fingers! kev@inel.gov | - ------------------------------------------------------------------------------- ------------------------------ Date: 25 Sep 91 13:37:01 -0400 >From: "David.M.Chess" Subject: Various Back from vacation, and just finished reading all the back VIRUS-L's. Good discussion going on! A few random comments on some of the threads (I apologize for not including citations for what I'm replying to): On IBM's scanner having strings in clear: I have seen at least one sample in which two tiny changes were made, one of which was in the middle of one of our signatures. The sample came to us very indirectly, though, and it wasn't clear whether it had been found in the wild, or prepared specially by someone out to prove a point. We've never seen that particular variant again, so it was probably a "lab specimen". IBM's scanner now has a certain amount of "mutant detection" on by default, so it's a bit harder to produce a tiny variant that will go undetected. The need for verifiers: If the typical incident involved detecting an infected object (program, diskette) before it was used (run, booted from), I would tend to agree that verifying the exact identity of the virus would be of secondary interest (possibly interesting to trace spread, but not of vital interest to the user). Of course, if that were the case, viruses would cease to be a problem shortly thereafter! As it is, the typical incident involves finding that a system is infected, and has been for at least a little while. Given that, it's vital to know exactly what virus you're dealing with, because you have to know what things may have been damaged (subtly or otherwise), and require repair. I wish exact identification weren't needed, but I fear that it is! At least at the moment. (I've just written a paper on the verification tools we currently use; I'll be posting or publishing it somewhere before too long.) Hardware and Software: Even the ideal combination of hardware and software doesn't make viruses completely impossible. As Cohen and others have shown, a virus can be written for even a protected system that is correctly set up and, as long as (roughly) some users can write to programs that others can execute, it can spread. Now this may be of only theoretical interest, in that such a virus might never actually become a problem (spreading too slowly to become pervasive in any real environment), but it's worth remembering that *any* search for _perfect_ protection is almost certainly doomed, and we have to look for "good enough". Integrity shells: The only one I know of is Cohen's own. I think it's called "ASP", but I fear I don't have any contact info. Fred is not on the net (and proud of it, hehe!). DC ------------------------------ Date: Wed, 25 Sep 91 12:51:06 -0500 >From: BJ Watts Subject: SITELOCK (PC) Hello, I don't know if anyone has really mentioned anything about SITELOCK lately, but I am disappointed with it so far. We have a 100 PC Novell Network with EtherNet and Token Ring configurations. The problems that we have been having is that after LockSetting a program, when another user tries to access that particular program after the limit is used, the pc's tend to hang up. After call Bright Works, they sent us another release 3.10 and it still does the same things, just not as often. I was wondering if anyone has used SITELOCK and if anyone has had any problems with it. Any comments or answers would very much be appreciated. Thanks. ________________________________ ____________________________________ : : : : BJ Watts : : : BITNET: WWATTS1@UA1VM.BITNET : How do girls get minks? : : INTERNET: WWATTS1@UA1VM.UA.EDU : The same way minks get minks. : : The University of Alabama : : :________________________________:____________________________________: ------------------------------ Date: Wed, 25 Sep 91 12:38:48 -0400 >From: padgett%tccslr.dnet@mmc.com (A. Padgett Peterson) Subject: re: Precise identifications >From: turtle@darkside.com (Fred Waller) > That is precisely the point. We are so used to thinking in terms > of "curing infections" that the idea of _preventing_ them no > longer seems to cross our minds. But it's obviously more > desirable to _prevent_, rather than cure, virus contamination. That comes under the heading of "bottom duck". If every PC in our organization looked exacly like mine, I'd have to go back to honest work (not entirely without merit) and I could start getting more than four hours sleep a night. Given a 10,000 user community and a bad economy you don't always get your way even if it is right (see "Atlas Shrugged" by Ayn Rand). Excrement happens, and I have to be ready to deal with ongoing situationns not just tell people "if you had only...". When a virus appears (and they do knock at the door with disturbing regularity) I want to know: 1) What is it 2) How did it get here 3) How do we close that door without offending the users Part of this is the ability to get a fast, reasonably accurate fix on the "what" so that we know how to deal with it. Scanners pay a big part in th "what" to determine the scope of the danger. Try sitting in a control room at 2 a.m. with a couple of VPs waiting to find out if you are going to shut their production line down to isolate a problem before you denounce SCANers as a valuable tool. In the real world today, taking down a 2000 node network because the Jerusalem or one of its clones has gotten loose is not something done lightly. The fact is that we are all still learning how to cope. I have been fortunate (?) enough to experience some real "interesting" cases that are simple to say "well, what we should have done was..." now but it was the "first time" then. LANs are the real threat today. It is nearly impossible to manage thousands of clients, often in remote areas and owned by outsiders "by the book" - and we are still writing the book. In short, there probably is not "one true solution". We are imperfect and we make mistakes, but when someone shouts "FIRE" there is not time to say "this can't be happening", it's time to find every available water line & hope for overkill - the alternative is worse. Padgett ------------------------------ Date: Wed, 25 Sep 91 19:22:00 -0500 >From: Big fish man on hippocampus Subject: Re: Possible Autocad virus (PC) BBROWN%HARPERVM.BITNET@mitvma.mit.edu (Bob Brown) writes: > Has anyone heard of a virus that infects Autocad and pops up an alien > who moves his mouth for appr. 1 second and then dissappears? We tried > using scanv80 and IBM's virscan, but neither could find an infection. > Has anyone else seen this or have ideas? AutoCad compiles and runs an AutoLisp program when it calls up a drawing. It would be possible to program some kind of animation sequence in it. If you want to check it out, copy the acad.lsp file from the installation disk into your autocad directory and run autocad. Of course this will overwrite any "macros" or other programs or subroutines you might have had in the acad.lsp so you might want to rename/copy the file first. - -- |\ \\\\__ Tony Maimer __ | \_/ o \ / | > _ (( <_ / | | / \__+___/ maimer@kuhub.cc.ukans.edu /o /_/| |/ |/ < )) _ < \ \ \| \ | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ------------------------------ Date: Thu, 26 Sep 91 10:26:41 +0000 >From: nstephen@dogmatix.inmos.co.uk (Nick Stephen) Subject: Wanted : a utility to warn me when I'm accessing a removable disk (PC) Hi Whilst I've been reading these groups for some time, I've never seen mention of a utility which prevents me from accessing a removable disk unless I type some command or response allowing me access to a floppy drive. Does such a thing exist? I would like it so that I do not need to have something like vshield resident, but instead the computer reminds me to run a scan program over any floppy that I put into my drive *before* I access it in any other way. Ideally, the program could recognise when a first access to a removable media is made and prompt for an 'are you sure' or even simply return a 'general failure' or similar error. Once the disk was accepted (reply 'y' to the prompt) the drive would be accessed normally until the media was removed, whereupon the process could be repeated when a new disk is accessed. Installing something using multiple disks could be done by either replying 'y' to the 'are you sure' message for each new disk, or running an 'acceptA' program which disables the checking. I believe that on a humble XT such as mine, the 'media changed' flag doesn't work properly, so this TSR could only easily fire the once, upon the first floppy access. After that, it could assume that I was alert enough to run scan on any suspect floppies I was about to introduce until the next reboot! I don't know enough about the internals of a PC to write such a TSR, but I do know enough about programming to know it shouldn't be that hard to someone who DOES know! Is there anything out there that already does this? If so, is it on a mail server somewhere, or could someone email me a copy as I don't have FTP access across to the USA :( Many thanks in advance, Nick ------------------------------ Date: Wed, 25 Sep 91 15:22:30 -0400 >From: "Steven P. Roder" Subject: Re: Procedures Involving Potential Virus Files (IBM VM/CMS) On Wed, 25 Sep 1991 09:05:03 EST Ron Wigmore said: >Relax! This is just a request for 'policy' information! :-) > >We have RSCSV3 checking for files that may be potential viruses (such >as CHRISTMA exec, etc.). We just had someone try to send such an exec >out. As it turns out, the exec is harmless and the user just picked >a bad name for his exec. > >What do other sites do at this point? Do you just discard the file, >with or without telling the user? Do you rename the file and send it >on off to its original destination. > >Do you tell the people on your system that files of a certain filename >and filetype cannot be sent out over the network? This is the main >stumbling point. If you tell the users which filenames/types cannot be >sent out over the network, then anyone wanting to cause some trouble will >just rename the file and then send it out - defeating the reason for >checking for specific files in the first place. > >How do other sites handle these matters? Ron, We are running the Selective File Filter package on RSCS 3.1 here. I have the first 10 copies of the file (e.g. CHRISTMA EXEC) sent to my userid, and any subsequent copies are purged. We do not advertise the names of the files we are filtering. Sending them to my ID allows me to see what the file is or does. If we were to make a policy of not allowing any files of filetype EXEC or MDOULE to be sent out, then we would publish it. We are not doing this, since it seems like overkill. Hope this helps. Steve ------------------------------ Date: Tue, 24 Sep 91 18:05:00 +0300 >From: Y. Radai Subject: Re: Need Info on Integrity Shells Steve Albrecht writes: >In his article "A Cost Analysis of Typical Computer Viruses and >Defenses", Dr. Fred Cohen speaks of "integrity shells...command >interpreters that look for changes in interpreted information before >interpreting it". > >What commercial products, shareware, or public domain software >falls into this category? I know of plenty of products which fall >into Dr. Cohen's other three categories (scanners, monitors, and >cryptographic checksums), but cannot locate an "integrity shell". An example of an integrity shell is Cohen's own commercial product, ASP (Advanced Systems Protection). I first heard of it two years ago. I presume it's still available, though I'm not sure. (I've never used it, so I can't comment on how good it is.) What I know of integrity shells (a la Cohen) comes mainly from glancing through his book _A Short Course on Computer Viruses_ while I was at the VB Virus Conference a couple of weeks ago. I found a lot of interesting information in it that I've never seen in any other book on viruses, and it's the only one I feel tempted to buy. However, it seems to me that an integrity shell would be entirely at the mercy of stealth viruses. Yet unless I overlooked something in the short time I had to look at the book (my apologies to Cohen if I did), his book contains absolutely no discussion of this important threat. And in general, it seems to me that the book omits several more very relevant topics, and (imho) contains a few outright errors. Still, on the whole I recommend the book, if not the software. Y. Radai Hebrew Univ. of Jerusalem, Israel RADAI@HUJIVMS.BITNET RADAI@VMS.HUJI.AC.IL ------------------------------ End of VIRUS-L Digest [Volume 4 Issue 174] ****************************************** Downloaded From P-80 International Information Systems 304-744-2253