VIRUS-L Digest Tuesday, 24 Oct 1989 Volume 2 : Issue 221 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., and sent to VIRUS-L@IBM1.CC.LEHIGH.EDU (that's LEHIIBM1.BITNET for BITNET folks). Information on accessing anti-virus, document, and back-issue archives is distributed periodically on the list. Administrative mail (comments, suggestions, and so forth) should be sent to me at: krvw@SEI.CMU.EDU. - Ken van Wyk Today's Topics: Re: Gatekeeper false alarm? (Mac) Re: SAM vs. Gatekeeper (Mac) RE: Superclock non-virus... (Mac) Re: INIT 29 question from Jim Bradley... IBM Virus Scan program (PC) Virus source available in Toronto IBM's Virscan Program (PC) VIRUSCAN test (IBM PC) --------------------------------------------------------------------------- Date: 23 Oct 89 21:27:20 +0000 From: ut-emx!chrisj@cs.utexas.edu (Chris Johnson) Subject: Re: Gatekeeper false alarm? (Mac) In VIRUS-L Digest V2 #217, Richard Kennaway (kennaway@sys.uea.ac.uk) writes: >Paranoid speculation follows. Paranoia, being a disease, is an inherently bad thing. What follows is, I believe, an unfortunate illustration. >Maybe someone is using the Joker's trick. There could be several >infected applications out there, all quietly spreading harmless-looking >things like STR 801 that dont ring GateKeeper's alarms, but when they >all come together in one application, the real virus is triggered... More likely, there's no virus *at*all*. I do believe this is pure paranoia. Further, there's a good reason that things like STR resources look harmless: they are. Period. They aren't executable, so they don't get executed. In and of themsleves they are *utterly* harmless. The end. For a virus to spread executable code has to move. Although *no* anti-virus scheme is perfect, that is exactly the kind of thing that Gatekeeper watches for. There's no such dichotomy as "real virus" versus un-real virus - either it is a virus, or it isn't. That means that this "Jocker's trick" is essentially nonsense - in order for the "harmless-looking things like STR 801" to spread there has to be a real- live virus *doing* the spreading - a virus which, in all probability, systems like Gatekeeper will stop. >Plug for Virus Detective: with this it was easy to search for all files >containing STR 700 (legitimate MacWrite resource) or STR 801. All the >other virus detectors I've seen have the symptoms to look for >hard-wired. I have no relationship with the author other than being a >satisfied customer. Philosophical Point: The problem with tools is that the users have to under- stand how they work, what they do, and how to use them. A failure of the user on any of these points results in the tool being unable to accomplish its intended purpose. Virus Detective is a fine tool, but it's not being correctly employed here. Sure enough, most MacWrite files have STR 700 and 801 resources, but just because Virus Detective will allow a person to discover this, *doesn't* in any way indicate the presence or involvement of a virus. Like any tool Virus Detective can be used correctly or incorrectly -- in this case it is being used in an incorrect manner, since the key issue, whether or not there is any reason to believe a virus is involved, has been sidestepped. Virus Detective is now merely serving as a tool to "confirm" baseless fears and assertions. Gatekeeper being more a "system" than a "tool", is less prone to feeding wild speculation, since it has its own means of identifying the presense of a virus and, as a result, does not require that the user be a skilled Mac programmer capable of searching out and analyzing would-be new viruses. Of course, Gatekeeper is fallible... but that usually means that users are merely required to tell it what *isn't* a virus, rather than having to search out new viruses from scratch like searching for needles that may-or-may-not be hidden in hay stacks. STRs 801 and 700 are good examples of strands of hay mistaken for needles. Returning to Gatekeeper, the symptoms are not quite "hard-wired". Gatekeeper's philosophy is, basically, that if a virus can't move, add, modify or delete executable resources (there are about 24 types), then it can't spread. And a virus that can't spread isn't really a virus anymore. Of course, you'll still want something like Disinfectant to remove the effectively sterilized virus. The list of executable resources is certainly not hard-wired - it's easily edited by following the instructions in the on-line help. The type of monitoring that Gatekeeper does *is* hard-wired, but in order to establish that this is a problem, a way must first be found to spread a virus without moving, adding, modifying or deleting executable resources. In short, the hard-wired aspects of Gatekeeper are not a problem - they are *fundamental* protections. This is why Gatekeeper has been able to stop every Mac virus discovered to date, including totally new viruses like ANTI and INIT 29 which were developed *after* Gatekeeper was written. I should add that Gatekeeper's security system has not had to change since it was first released on 2-Jan-89, precisely because it is such a fundamental approach to stopping viruses. Gatekeeper isn't perfect - no anti-virus system is - but it's very good. I, personally, tend to be a bit defensive with regard to Gatekeeper because I've observed a number of misconceptions that do it sad injustices, while johnny-come-lately packages like SAM and the Virex INIT, etc. are heralded as the first and only fundamental solutions to the Macintosh virus problem. Since Gatekeeper was discussed here in a misleading manner I thought it was important to try to put an end to, at least, the misconceptions illustrated here. As to the alleged MacWrite virus - paranoia tends to spread... and I've seen a number of postings to other newsgroups from people scared because they've discovered perfectly normal STR resources in their MacWrite documents. This never should have happened. The fact is, the burden of proof is on he who asserts the positive. Yet, for all the talk about this new virus, there's still been no offer of proof of the virus's existence. Nonetheless, the paranoia spreads due to these baseless assertions. If there's some proof, we *need* it and blessings upon whoever provides it, but, for lack of that proof, this discussion should have been terminated long ago. Given that there's been a delay in the VIRUS-L news recently, maybe this discussion has already died, and I've ranted on needlessly. I certainly hope that's the case. - ----Chris (Johnson) - ----Author of Gatekeeper - ----chrisj@emx.utexas.edu ------------------------------ Date: 23 Oct 89 22:09:00 +0000 From: ut-emx!chrisj@cs.utexas.edu (Chris Johnson) Subject: Re: SAM vs. Gatekeeper (Mac) In VIRUS-L Digest V2 #216, Henry C. Schmitt writes: >I have used both GateKeeper and SAM Intercept and I prefer the >latter. The main reason? When "something suspicious" happens, >GateKeeper says "you can't do that!" then if you want to override, >you must open the Control Panel select GateKeeper and set up the >permission; with SAM Intercept, at the time of the happening you can >allow the action once or LEARN the action then and there! The reason Gatekeeper does not bring up a custom dialog that would let the user allow an operation, is neither sloth, nor indifference to the plight of the user. The reason is *compatibility*. Apple will guarantee that the Notification Manager, which Gatekeeper uses to display its alerts, will be compatible with virtually all software and will certainly be compatible with all future versions of the System. SAM's custom dialog may break in future releases of the System - or it may not. For myself, I can't think of any method that's worth the risk. Since the author of SAM probably had support from Apple DTS, he may have been provided with techniques that would make a safe implementation possible. I, regrettably, have no real access to DTS (becoming a registered developer requires money I just don't have). If anyone at DTS would be willing to offer some advice on safe ways of approaching the custom-alert problem, I'd *love* to hear it. (Hint, hint.) :-) One other point though (and please correct me if I'm wrong), I've been told that SAM doesn't provide a way to view all of the privileges that have been granted to various applications, let alone a method of editing them. If this is the case, I have to view it as a far greater problem with SAM, than on-the- fly configuration is with Gatekeeper. If someone using your machine inadvert- antly or unwittingly clicks on the LEARN button when a virus attack is detected, your copy of SAM will have been programmed to let a virus attack succed in that case, and you'll probably never find out. Like I said, though, please correct me if I'm mistaken. On the subject of the Gatekeeper Log file: >I only see this as being useful if you're trying to track the >propagation of a virus, but then you have to allow the "suspicious >action" which GateKeeper doesn't do (unless you gave permission, in >which case it isn't logged!) Depends what you mean by "propagation." If you mean the successful spread of a virus, then yes, Gatekeeper won't tell you much simply because it won't permit the spreading to occur in the first place. :-) But consider what the log file *does* do for you... it will tell you where all of the infection attempts originated from, when they started, what characterized the infection attempt, and it'll even tell you whether or not your machine was booted on a floppy disk and infected that way. Furthermore, if you're a person attempting to quickly gain an understanding of a virus' infection mechanism, running Gatekeeper on a test machine in its "notify only" mode will give you an immediate run-down on how the virus works. Also, each virus has its own "signature" - even when Gatekeeper stops the virus' spread - in the log file. It is easy, for instance, to tell INIT 29 from Scores merely by looking at the records of their failed attempts at infection as recorded in the Gatekeeper Log. This makes it equally easy to indentify both new strains of existing viruses, and totally new viruses. The log file provides an incredible amount of documentation that can be, I believe, extremely useful in protecting an individual or an entire corporation from the influx of viruses. >I'm not trying to put down GateKeeper, if you want to fight viruses >cheaply, it's a must! Keep up the good work Chris! > > Henry C. Schmitt Thanks! Gatekeeper 1.2 is in the works. In the same spirit, I'm not trying to put down SAM - I'm just trying to make sure that Gatekeeper gets full credit where it's due. - ----Chris (Johnson) - ----Author of Gatekeeper - ----chrisj@emx.utexas.edu ------------------------------ Date: Tue, 24 Oct 89 08:32:07 -0400 From: dmg@lid.mitre.org (David Gursky) Subject: RE: Superclock non-virus... (Mac) Superclock (in the general case) is not a virus. It is a legitimate cdev that displays the current time-of-day in the upper right hand corner of your Mac's screen. The current version is 3.5 (although I thought I saw a 3.6 yesterday). It is more likely that the "Superclock" virus is simply an occurance of (if I have to pick one) the INIT 29 virus, or a strain therof. Superclock is not a stand-alone application; it is a "control panel device" that is loaded into RAM at start-up. In the MS-DOS world, Superclock would belong to the class of applications called "TSR"s (Terminate and Stay Resident). In the Macintosh world however, cdev's (and their sister's RDEVs (Chooser devices) and INITs (classic TSRs)) contain their code in resources called (appropriately) INIT. Classic Macintosh viruses (such as nVIR and strains, Scores, Peace, and ANTI) infect code in CODE resources. Only INIT 29 infects code stored in INIT resources. Another possibility is that the "Superclock" virus is a wholly new strain. While this is not impossible, I find this less likely. The Mac is a not as easy a machine to program and acquire expertise on as MS-DOS platforms. Consequently, there is simply a smaller number of potential virus-writers (proportionally) than in the MS-DOS world. David M. Gursky Member of the Technical Staff Special Projects Department, W-143 The MITRE Corporation ------------------------------ Date: Tue, 24 Oct 89 08:50:37 -0400 From: dmg@lid.mitre.org (David Gursky) Subject: Re: INIT 29 question from Jim Bradley... In Virus-L V2 #220, Jim Bradley asked if an application on a clean disk opened a data file infected with INIT 29, would the application then become infected. No. While INIT 29 is capable of infecting data files, the virus is "dormant" essentially. Code in INIT resources is only executed at startup, and no other point. Data files infected with INIT 29 only represent a threat to your system if they are kept in the same folder as your System and Finder files. ------------------------------ Date: Tue, 24 Oct 89 11:09:00 -0400 From: "Gerry Santoro - CAC/PSU 814-863-4356" Subject: IBM Virus Scan program (PC) I like the fact that the IBM virus scanning program reads its strings from an ASCII file provides the capability for updating this program for new viruses. (I still like McAfee's SCAN program too, and would recommend that a user have BOTH, just to be safe.) My question, are there any plans to add updated virus scan strings to the IBM virus scan data file and have this string file available on one of the anti-virus servers? This could help a lot of people avoid duplication of effort. - ----------------------------------------------------------------------------- gerry santoro, ph.d. *** STANDARD DISCLAIMER *** center for academic computing This posting is intended to penn state university | represent my personal opinions. gms @ psuvm.psu.edu -(*)- It is not representative of the gms @ psuvm.bitnet | thoughts or policies of anyone ...!psuvax1!psuvm.bitnet!gms else here or of the organization. (814) 863-4356 ---- "I yam what I yam!" ---- - ----------------------------------------------------------------------------- ------------------------------ Date: Tue, 24 Oct 89 12:01:49 -0400 From: Russell Herman Subject: Virus source available in Toronto Disassembled source code for the PC virus producing a bouncing ball onscreen just appeared on a major Toronto BBS. It does not appear to be quite correct, nor will it assemble nonfatally with either MASM 5.1 or TASM 1.0.1 (small comforts). Furthermore, the comments are in Portugese, although the file was dubbed "italiano.asm". Now the world has been given the template for an infector (sigh). [Ed. The book "Computer Viruses: A High Tech Disease", published by Abacus, contains several (functional) source code examples, in various languages on various hardware/software platforms, of viruses. This book is readily available in bookstores and from the publisher.] - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Russ Herman | Internet: rwh@me.utoronto.ca | University of Toronto Comp. Sys. Mgr. | UUCP: uunet!utai!me!rwh | Dept. of Mech. Eng. (416)978-4987 | | 5 King's College Rd. (416)978-7753fax| | Toronto, ON M5S 1A4 Canada ------------------------------ Date: Tue, 24 Oct 89 12:38:00 -0400 From: <90_PENNYPAB@UNION.BITNET> Subject: IBM's Virscan Program (PC) I just subscribed to this list, so this posting may be redundant. Bear with me... I worked for IBM over the summer and had a chance to take a look at their VIRSCAN program, which others have discussed on this list. Unfortunately the version I used is listed as "IBM Internal Use Only", meaning that It is only to be used for IBM related purposes. According to the Forums I read on the IBM network while working there, VIRSCAN is supposed to be one of the better programs for detecting known viruses. What I would like to know is if there is a similar version of this program available to the general public, and if so how to get a copy of it. Also, if a public version of this program is available, how are updates to the virus signature files (SIGFILE.LST and SIGBOOT.LST for VIRSCAN) kept up to date, if they are at all? Bruce Pennypacker 90_PENNY@UNION.BITNET 90_PENNYPAB@GAR.UNION.EDU ------------------------------ Date: Tue, 24 Oct 89 07:41:08 -0700 From: portal!cup.portal.com!cpreston@Sun.COM Subject: VIRUSCAN test (IBM PC) These results apply to versions through V38. The current version at this time is V45. Changes are made at least once per week, it seems, to keep up with new viruses, and I finished the work about the time this digest went off for a couple weeks. VIRUSCAN, for the IBM PC, from McAfee Associates, was tested using 23 actual viruses or strains of virus. These included boot or partition viruses such as Stoned, Ping Pong, and Brain, and .COM or .EXE viruses such as Datacrime (1168, 1280, Datacrime II) Jerusalem, Icelandic (several varieties) and Fu Manchu. In each case, with two exceptions (noted below) VIRUSCAN correctly identified the viruses after they had infected programs or disks, and located all instances of infection in all subdirectories of the hard disks. One version of the program, before V35, failed to detect the 405 virus, but this was corrected in later versions. Suriv 300, a Jerusalem variant, was not detected in an .EXE file, but was caught in a .COM file. Based on the testing I did, VIRUSCAN appears to be a well-written and effective program for locating specific known viruses, and is a very useful part of an anti-virus program. Next question: How good are scanning programs? There seems to be a perception, at least as written in several sources, that scanning for known viruses is the weakest method of detecting viruses. This is probably based partly on the assumption that the slightest change in a virus will defeat the effort to detect it using byte strings. Experience shows that minor changes are frequently made to microcomputer viruses. Perhaps the most freqent change is to imbedded, non-encrypted, text strings. Changes are also made to the infection trigger or activation conditions or dates. Obviously, changes can be made to any virus to defeat any particular scan string. This has already occurred in the Macintosh world, but most changes made so far have been on the same level of difficulty as changing ASCII strings. Inspection of a search string in VIRUSCAN and/or its location in the virus code can show that a particular search string is not based on imbedded text, and that changing the text will not interfere with detection. A number of viruses were checked for this. Also, it is easy to determine that text added to a boot sector in the Yale/Alameda virus, for example, to make it look more like a normal boot sector would not interfere with its detection. If the search string used in the scanning program is at a different location than the added text, it won't interfere. On other changes, I found that with a partial disassembly, or one that was perhaps incorrectly interpreted by me, changes to what appeared to be an infection trigger did not replicate with the virus, or did not cause the anticipated change in virus behavior. For this reason, it seemed more efficient, and probably more accurate, just to make a common type of change to a virus, and test VIRUSCAN again. Each virus was modified by patching it, making minor changes in the executable code on the disk. Each modified virus was allowed to infect at least one other program to produce a second generation virus. The final infected program was inspected and run to ascertain that the modification was correctly transmitted with the virus. This established that there was a viable new strain of virus. VIRUSCAN was run to see if it still found the modified virus. - -------- Viruses modified and detected by VIRUSCAN version 0.5V34 or later versions through V38. -Virus name- -Type of modification- Ping Pong boot Virus (Italian) Activation window time was increased Jerusalem Virus - Version D Activation date changed 1280 Virus (Datacrime) Activation (destruction) date changed 1168 Virus (Datacrime) Activation (destruction) date changed Vienna (DOS 62) Virus - Version A Manipulation task to move 5 bytes to corrupt infected program was changed. 405 virus Changed to seek and infect hidden files - ------------- Conclusion: A well-chosen search string for a virus can survive at least some of the common changes to viruses that are made as they pass through different hands. A good scanning program can provide better protection than it might appear at first glance. VIRUSCAN is available from BIX, CompuServe, and other sources, including the Homebase BBS, at 408-988-4004. On Homebase, the latest version is SCANV45.ZIP. Disclaimer: I am a computer security consultant and have been working with PC and Macintosh microcomputer viruses and anti- virus products for about 18 months. I have no obligation to John McAfee except to report the outcome of the tests. Information Integrity is a member of the Computer Virus Industry Association, which is operated by John McAfee. Charles M. Preston 907-344-5164 Information Integrity MCI Mail 214-1369 Box 240027 BIX cpreston Anchorage, AK 99524 cpreston@cup.portal.com ------------------------------ End of VIRUS-L Digest ********************* Downloaded From P-80 International Information Systems 304-744-2253