28-Sep-89 21:28:11-GMT,30444;000000000001 Received: from RUTVM1.RUTGERS.EDU by topaz.rutgers.edu (5.59/SMI4.0/RU1.1/3.04) id AA21335; Thu, 28 Sep 89 17:24:58 EDT Message-Id: <8909282124.AA21335@topaz.rutgers.edu> Received: from RUTVM1.RUTGERS.EDU by RutVM1.Rutgers.Edu (IBM VM SMTP R1.2.1MX) with BSMTP id 9441; Thu, 28 Sep 89 14:22:45 EDT Received: from RUTVM1.LISTSERV by RUTVM1.RUTGERS.EDU (Mailer R2.04RU) with BSMTP id 9438; Thu, 28 Sep 89 14:22:38 EDT Date: Thu, 28 Sep 89 07:33:25 EDT Reply-To: VIRUS-L@ibm1.cc.lehigh.edu Sender: Virus Discussion List From: "The Moderator Kenneth R. van Wyk" Subject: VIRUS-L Digest V2 #206 Comments: To: VIRUS-L@ibm1.cc.lehigh.edu To: Multiple recipients of list VIRUS-L VIRUS-L Digest Thursday, 28 Sep 1989 Volume 2 : Issue 206 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: Cookie (monster) virus (PC) viruses in anti-virals Tiger Teams Re: Preventing virus attacks (PC) Anti-virus viruses Hyperspace virus ? (PC) Final word on Centel Corp and Viruscan Viruses in Commercial Software Re: October 12/13 (PC) Compiled list of viruses... Anti-viral hard disk controllers Review of NIST anti-virus paper... Anti-virus Virus Columbus Day Virus attacks the military? Tiger Teams (Was Re: Good viruses?) Virus signatures --------------------------------------------------------------------------- Date: 27 Sep 89 12:56:00 +0200 From: Antonio-Paulo Ubieto Artur Subject: Cookie (monster) virus (PC) I haven't yet got VIRUS-L Digests #197 to #199. It seems that my contributions about the "Cookie virus" was included in one of these. Just after receiving some kind postings about this item, I found on the French magazine "Soft & Micro" (september 1989, p. 156) a description and a photo of the "Sesame Street virus". The described version seems to be old, the virus is said to have been one of the first virus around in some American colleges. No harm is described: the only requirement was to write "cookie" when the text "I want a cookie !" appeared on the screen. Incidentally, on the photo, the virus appears on a dBASEIII screen, not on a word-processing program. I have to apologize. I described what seems to be a Spanish hack - -or at least translation- of the "Sesame Street virus" or "Cookie monster virus". This version seems to be more violent, as there were lost files due to this virus. I insist: I haven't yet seen this virus, neither has it caused any damage -as far as I know- at my University. But if there is something I awfully hate in computing is to loose data and having to rekey them again. Therefore my contribution was more intended as a warning message. If someone out there avoids only one of this loosings by "giving a cookie", I thing it was worth the effort. Of course, any preventive or removal method against this virus would be appreciated. As it was said in one recent VIRUS-L Digest, "the best virus is the dead one". And my colleagues here at the University -some of them recently threathened by the "Friday-13 virus" (sUMsDos variant)- would also have a little more peace of mind. Thank you very much. Antonio-P. Ubieto. Department of Modern and Contemporary History. Zaragoza University (Zaragoza, Spain - Europe). hiscont@cc.unizar.es ------------------------------ Date: 27 Sep 89 12:38:00 +0700 From: "Okay S J" Subject: viruses in anti-virals In VIRUS-L.V2NO201 David Gursky(DMG@LID.MITRE.ORG) >Let me take this one step further. Anti-virus applications (IMO) make >a poor carrier for a virus. In order for a virus to succeed, it must >go undetected. This means that prior to the activation of the virus' >logic-bomb or time-bomb, it cannot interfere with the normal operation >of the computer or the applications in use on the computer. To do so >greatly improves the chances the virus will be discovered (to wit, the >Jerusalem virus). If we work under the assumption that when a user >acquires an anti-virus application, they actually use it (in fact we >must work under this rule; otherwise the virus would not spread), the >virus necessarily undergoes an increased chance of detection because >an application is running that looks for viruses! The only problem with this is that with a virus or other destructive program masking itself as an anti-viral, you would think that the person would have ripped the detection code out for the particular virus he is trying to spread, or just chopped it out altogether. It would be kind of funny to have a virus you are trying to spread zapped by its own carrier! :). But then again, some criminals can be pretty stupid....(which is all any of us can really hope for) ----Steve Stephen Okay Technical Aide, The MITRE Corporation x6737 OKAY@TAFS.MITRE.ORG/m20836@mwvm.mitre.org ------------------------------ Date: Wed, 27 Sep 89 09:05:57 -0400 From: Joe McMahon Subject: Tiger Teams Dave Gursky asked about the tiger team approach. It depends on several things: - - Is the computer in question a computer which belongs to the installation, or one which belongs to the person? - - Is the virus completely self-limiting (i.e., if the date becomes anything other that the date of infection, the virus removes itself? - - Is the company willing to risk destroying this user's files and possibly wasting large amounts of time and money to replace them? Apple's statement on Mac viruses is that you should never trust a once-infected file, even if it is "cleaned up". I tend to side with that approach. I know that if I had been following procedures, and some expletive-deleted from Security futzed around with my machine behind my back, I'd be angry. Especially if it trashed my files. --- Joe M. ------------------------------ Date: Wed, 27 Sep 89 13:40:46 +0000 From: frisk@rhi.hi.is (Fridrik Skulason) Subject: Re: Preventing virus attacks (PC) > Will changeing a file attribute to READ ONLY stop or slow down a virus? > What about write locking a whole Directory? > Does hiding a file or directory have any effect??? This is a very common question, but in general the answer is NO. Boot sector viruses are of course not affected by the read-only protection, since they do not infect files. Some viruses can be stopped my making program files read-only, but right now I can only think of two such viruses: South African "Friday 13." (and the related VIRUS-B) Lehigh However, those two viruses are very rare. The rest of the PC viruses remove the read-only attribute from files, before infecting them. Most of them restore it later ("Icelandic" does not). So - making files read-only will not provide any protection from viruses like: Jerusalem (Israeli Friday 13.) and relatives (Fu Manchu) Vienna (DOS-62) Traceback DataCrime Icelandic and relatives (MIX1 and Saratoga) The main use of read-only protecting .EXE and .COM files is really to protect the user from his own mistakes. Hiding a file is equally ineffective. --- frisk ------------------------------ Date: Wed, 27 Sep 89 14:25:25 +0000 From: frisk@rhi.hi.is (Fridrik Skulason) Subject: Anti-virus viruses I have been following the anti-virus-virus discussion with some interest, but I have not yet seen anybody mention the fact that one such virus already exists. The virus is the "Den Zuk" (Translation: The Search) virus, which was written to fight the Brain virus. When this virus finds a Brain-infected diskette, it removes Brain and puts a copy of itself in place. It also looks for old versions of itself and "upgrades" them if necessary. The virus resides on track 40 on diskettes (normally 360K diskettes only have tracks numbered 0-39), and thus takes up no usable space. So far, so good. However - this virus also demonstrates what can (and will) go wrong with anti-virus-viruses. The programmer did not anticipate 1.2M or 3.5" diskettes. When the virus infects a disk of that type, it will destroy data. Also, several "hacked" versions of this virus have been reported, including one that will disable the SYS command and destroy all data on drive C: on September 13. 1991. (One more of those "Friday the 13th viruses. Why can't virus writers have a little more imagination :-) ) So - the conclusion is simple: "The only good virus is a dead one." ---- frisk ------------------------------ Date: Wed, 27 Sep 89 14:39:45 +0000 From: frisk@rhi.hi.is (Fridrik Skulason) Subject: Hyperspace virus ? (PC) Has anybody heard of a virus or trojan that will produce the following effect ? Suddenly the computer will switch to graphic mode, and dots will appear, coming from the center of the screen, going faster and faster. Then a flash of light will appear on the screen, followed by the text "Welcome to HYPERSPACE" Finnally the computer will svitch back to text mode, and everything will be back to normal. I have not seen this, only heard of it. --- frisk ------------------------------ Date: Wed, 27 Sep 89 10:51:56 -0400 From: KARYN@NSSDCA.GSFC.NASA.GOV Subject: Final word on Centel Corp and Viruscan I decided to look into this Centel Corporation problem. As they are situated just down the street, I called their office, and they sent me the information alluded to in the Washington Post article. I received a license agreement and a letter sent to various businesses addressed to "Security Colleague". Centel does not seem to be distributing Viruscan. The second paragraph of the Preamble of the License agreement is: In response to this threat [referring to DATACRIME viruses] Centel Federal Systems, in conjunction with American Computer Security Industries, Inc. ("ACSI"), has developed certain scanning software ("VCHECKER") that is capable of detecting certain forms of the virus, and is offering that software to computer users for a nominal handling fee of $25.00. It is presently believed that VCHECKER is capable of detecting two of the unknown number of strains of the virus that are in existence. However, because of the unpredictability of the virus and its various strains, and because of the many uncertainties surrounding its propagation and detection, neither Centel Federal nor ACSI is able to warrant that VCHECKER software will succeed in detecting the virus as it may exist in any particular computer system. Users of VCHECKER should also understand that VCHECKER is designed only to detect the possible existence of the virus, and that removal of the virus from a particular computer system, or repair of any damage that the virus may cause, is the responsibility of the user. An excerpted paragraph of the distribution letter follows: ...One company, ASCI, has developed a program called VCHECKER that looks for the known signatures of what they call the Columbus Day Virus... It seems to me that ASCI got its hands on the DATACRIME signatures that John McAfee distributed and wrote a program to check computers for it, and decided to sell it. Hopefully this will stop all the hoopla about this subject and clean up Centel Corp's reputation. I hate to see reputations ruined over misunderstandings. Standard Disclaimer: I am in no way affilliated with Centel Corp, or ASCI, and all the ideas presented are my own and in no way reflect attitudes of anyone I work for. *-- *-- *-- *-- *-- *-- *-- *-- *-- *-- *-- *-- Karen Pichnarczyk KARYN@nssdca.gsfc.nasa.gov 703-648-0770 ------------------------------ Date: Wed, 27 Sep 89 11:53:00 -0400 From: TMPLee@DOCKMASTER.ARPA Subject: Viruses in Commercial Software In commenting on viruses being distributed (accidentally, of course) through commercial software someone recently mentioned that someone near him had been hit by a virus that was in a shrink-wrapped copy of WordPerfect. I'm skeptical -- WordPerfect is such a widely-sold program that had there been one copy infected there would have been thousands and the din would have been deafening. Could someone who follows this closely summarize exactly which commercial packages have definitely been identified as having been shipped infected? (i.e., the virus was found on them before there was any chance whatsoever they could have been written to by the user's machine.) (I'm not doubting that commercial software is a good vector for distributing viruses or that it has happened before, I just want to make sure that a company with good anti-virus practices doesn't get falsely accused; in the case in point I have no idea what WP Corp's practices are.) ------------------------------ Date: 26 Sep 89 19:07:49 +0000 From: ttidca.TTI.COM!hollombe%sdcsvax@ucsd.edu (The Polymath) Subject: Re: October 12/13 (PC) In article <0006.8909251230.AA29228@ge.sei.cmu.edu> ttidca.TTI.COM!hollombe%sdc svax@ucsd.edu (The Polymath) writes: }}I'm the editor of our university's computing newletter. I need to }}know how users can detect the October 12/13 virus ahead of time. Is }}there a way at all? ... } }How about backing up the hard disk, then setting the system date ahead to }October 13 and re-booting? Since posting this, I've been advised that some viruses are designed to detect and avoid this test. They do so by keeping track of date increments to make sure they occur one day at a time. Typically, they store a week's worth of dates, possibly more. Assuming a one week buffer, you'd have to implement the sequence "increment date, re-boot, run infected program" at least 8 times to bypass such a check. It's getting nasty out there. }[Ed. Sounds (to me) kind of like testing to see if the mines in an }inert minefield are "ert" by having someone walk through it. :-)] I did say to back up the hard drive first. That way you can resurrect your mine tester if it happens to step on an "ert" mine. (-: The Polymath (aka: Jerry Hollombe, hollombe@ttidca.tti.com) Illegitimis non Citicorp(+)TTI Carborundum 3100 Ocean Park Blvd. (213) 452-9191, x2483 Santa Monica, CA 90405 {csun|philabs|psivax}!ttidca!hollombe ------------------------------ Date: Wed, 27 Sep 89 14:44:01 -0500 From: Dave Boddie Subject: Compiled list of viruses... I may be asking quite a big question, but I want to know: Is there a compiled list of viruses, symptoms, cures, source, whathaveyou that I can somehow obtain? I am mostly looking for PC viruses, cures and symptoms to most know viruses. If there is one, could someone PLEASE send it or any like it to me? Thanks much in advance. David Boddie Remote Lab Operator University of Arkansas. ------------------------------ Date: 27 Sep 89 20:37:15 +0000 From: ginosko!cg-atla!mallett@uunet.UU.NET (Bruce Mallett) Subject: Anti-viral hard disk controllers Seems to me that virus infestation in companies could be controlled through a little bit of dicipline and with the help of a modified hard disk controller. The scheme is to partition the hard disk into an executable partition and into a data partition. All executables are kept on the bootable, outer partition. The modified disk controller has: switches which indicate the last track number of this outer partition a switch out the back to enable/disable writes to this outer partition. Probably a rotary requiring a screw-driver or other tool to change. In a corporate environment where systems are controlled I would think that this would work quite well. Virus software must be able to write to executables to spread, and they would not be able to since the partition containing them is hardware protected. Without hardware assist, software is always defeatable so no software solution is going to guarantee protection against all infestations. Dicipline is needed in several areas: administration to ensure that systems get properly setup, environments defined correctly, etc.; software packages must not maintain/modify data out of their executable directories; users must not fiddle with the switch nor import foreign, unknown software (by write-enabling the partition), etc. Note that programs run from the floppy can still wreak havoc to the un- protected partition, but they cannot spread via the HD. Is this workable? [Ed. There is at least one commercial product that does exactly that, but it's name escapes me.] ------------------------------ Date: Wed, 27 Sep 89 15:43:11 -0400 From: dmg@lid.mitre.org (David Gursky) Subject: Review of NIST anti-virus paper... Recently, the National Institute of Standards and Technology (NIST, the successor to the National Bureau of Standards) published a short paper entitled: _Computer Viruses and Related Threats: A Management Guide_. I have had a chance to read through it, and here are my comments: NIST Virus study comments First and formost, the NIST paper is an excellent, broad summary of knowledge of prevention measures for "electronic threats". It does not deal with the specifics of protecting this system, or that system, but rather looks at two classes of systems (multi-user and single-user) in two different environments (stand-alone or networked) and discusses six aspects of the security issue: General Policies, Software Management, Technical Controls, Monitoring, Contingency Planning, and Network Concerns. As much as I want to say this is an excellent paper, I find two flaws that hold it back: 1 -- The paper is not always consistent in its tone and advice 2 -- Some advice presented in the paper is based on false assumptions Inconsistency -- The authors of the paper appear to have a problem accepting that any successful policy to deal with electronic threats must rely on the cooperation of the user community. At certain points, it explictly states system managers must *prevent* users from performing actions of questionable risk altogether, and later on it states that users can do the same thing under controlled circumstances. The problem of electronic threats is *everyone's* problem, and *everyone* must be part of the solution. The underlying attitude of the authors seems to be "users cannot be counted on". For better or for worse, users *must* be counted on, and when that is not possible, made accountable. Other examples of where the authors make one statement, and then back down from it elsewhere in the paper exist; this is the one that I happen to have picked up. By the same token, there are only a few instances of this type of hemming and hawing. False Assumptions -- The paper forwards the myth that programs obtained from public sources (bulletin boards; public network libraries) are inheritely tainted, and that shareware/freeware/etc. should really be avoided. Certainly applications obtained from these sources are riskier, but these risks can be minimized through careful selection of sources, (i.e. public sources with a large pool of experienced users feeding from it), by judicious testing of software obtained from these sources, and by maintaining an internal library of these applications. This last step (completely overlooked by Wack and Carnahan) of providing users access to shareware from a corporate-sanctioned libraray can go far in ensuring that applications from riskier, public sources are not brought into the corporate computing environment. By the same token, the paper forwards the myth that commercially obtained applications are inheritly untainted. The Aldus Freehand infection (among others) demonstrates that this is clearly not true. Summary -- Summarizing, I would say this paper is a very good source for technical users looking to gain information about how to go about addressing the virus problem, and a good source for corporate managers looking at the same question. The paper's inconsistency on the role users must play in a successful anti-virus strategy, and it's partial reliance on a false assumption hold it back from being excellent on both counts. Copies of the NIST paper can be obtained for $2.50 from the U.S. Government Printing Office, 202.783.3238. The document is NIST Special Publication 500-166, GPO #003-003-02955-6. The opinion expressed in this review is mine, and does not in any way reflect the official policy of the MITRE Corporation, or any of MITRE's clients. Please do not redistribute this review without my consent first. Thank you. Submitted 27 September 1989 David M. Gursky Member of the Technical Staff, W-143 Special Projects Department The MITRE Corporation ------------------------------ Date: Wed, 27 Sep 89 20:13:00 -0400 From: WHMurray@DOCKMASTER.ARPA Subject: Anti-virus Virus Chris Poet invites comment on the idea of an anti-virus virus. Chris you are correct. The idea is not original and has been discussed here ad nauseum. The consensus appears to be that it is not a good idea. Certain behavior is reprehensible regardless of its motive or intention. One such class of behavior is misrepresentation. Nice people do not resort to lies, regardless of motive. A subset of misrepresentation is stealth. Nice people do not intrude unannounced and univited. Good intentions in such cases rarely excuse the behavior. Finally, some behavior is so potentially dangerous that it cannot be justified by good intentions. Spreading any kind of computer code by automatic replication is dangerous and not justified by the intent or value of the code so distributed. Nor is it justified by any superiority of this method of distribution over any other. The decision to employ protection is a personal one. Open distribution by overt channels is preferred. I am glad that you sought advice before embarking on this ill-advised scheme. Having sought it and received it, I hope that you will heed it. [Ed. I agree with Dr. Murray in that this topic has been discussed here ad nauseum - the general concensus of which is that it is not a good idea. Unless anyone has anything significant to add to the conversation, let's please consider this topic closed. Ok? Please? :-)] ____________________________________________________________________ William Hugh Murray 216-861-5000 Fellow, 203-966-4769 Information System Security 203-964-7348 (CELLULAR) ARPA: WHMurray@DOCKMASTER Ernst & Young MCI-Mail: 315-8580 2000 National City Center TELEX: 6503158580 Cleveland, Ohio 44114 FAX: 203-966-8612 Compu-Serve: 75126,1722 INET: WH.MURRAY/EWINET.USA 21 Locust Avenue, Suite 2D DASnet: [DCM1WM]WMURRAY New Canaan, Connecticut 06840 PRODIGY: DXBM57A --------------------------------------------------------------------- ------------------------------ Date: Thu, 28 Sep 89 02:59:00 -0400 From: CZMUREK%DREW.BITNET@VMA.CC.CMU.EDU Subject: Columbus Day Virus attacks the military? Once again there is some frightening news about the Columbus DAy Virus!!! As I was watching the Monday edition of computer chronicles there was a segment on the problem that exists for the military. It seems that all branches have been put on the watch for this one because of the recent HUGE number of finds in the Air Force and Navy. The implications of this are wuite scary indeed. Did anyone else hear abou this or does anyone else have any light to shed on the severity of the infection? One last question- do the armed forces have any plan of action for such an occurance as the downing of a large number of their systems at one time or for the vaccination of military hardware? ------------------------------ Date: 27 Sep 89 19:34:37 +0000 From: chinet!ignatz@att.att.com Subject: Tiger Teams (Was Re: Good viruses?) In article <0002.8909261721.AA06193@ge.sei.cmu.edu> dmg@retina.mitre.org (David Gursky) writes: ... >Suppose a company has stringent rules about protecting desktop >computers from viruses. How do you go about ensuring the rules are >being followed? One thought I had was the user of "Tiger Teams". And goes on to describe a "Tiger Team" which would prowl the halls after-hours, looking for unsecured desktop machines which it could then infect with an "approved" virus, preparatory to an upleasant visit by the PC Police the next day. Presumably, the purpose of actually infecting the machine is to provide an object lesson to the unhappy employee careless enough to not lock the system. This, however, is Not A Good Idea, for many reasons. First, you've disrupted the productivity of a probably useful employee for at least half a day, or more, while his/her machine is zoned out. Next, you're tying up one or more people comprising the "Tiger Team"; as proposed, worse, they're having to put in non-prime hours performing what is essentially an overhead (read "costs money, makes none") task; you're setting up the kind of confrontational situation that can cause stressful relations between employees; and it's not necessary. Not to mention that there are other security holes that are unaddressed, such as terminals left logged into multi-user systems which nevertheless can be used to corrupt or destroy company data and programs. Also, how about desktop or cubicle multi-user and/or multi-tasking systems, such as small Unix/Xenix boxes, VAX/VMS workstations, etc.? Look at finding access to these, and then corrupting them, and you'll start to see that this is a form of sanctioned cracking which is beneficial to none, and detrimental to all. More useful, and actually used in many client sites I've been assigned to, is to simply have the guard--who must make rounds anyway--also made responsible for checking certain criteria for computer equipment. Such things as locked access when applicable, no media left lying about unattended, login-protected terminals (whether remote timesharing, desktop multi-task/user, etc.) logged off whenever unattended, etc. would be grounds for a report by the guard. At the same time, the unsafe condition would be corrected as well as possible by the guard--media collected and secured, accounts either logged off or reported to system operators for deactivation, unlocked single-user desktop machines either locked in the office, if possible, or the power supply secured, etc. The same desired benefits are obtained: the employee is made amply aware of his/her faux pas, and security is maintained. Anyone who's ever worked in a security environment is aware of these and other methods; they're actually used, as I mentioned before. The military does make use of "Tiger Teams" that attempt to penetrate security and leave proof of their success. Usually, however, they are employed in an environment where they're attempting to subvert or circumvent active security measures, such as the deck guard on a nuke sub that's docked, or access to a presumably secured and monitored area. ------------------------------ Date: Wed, 27 Sep 89 16:26:48 +0300 From: Luiz Felipe Perrone Subject: Virus signatures A few weeks ago I received one VIRUS-L digest (unfortunately I do not remember which one) which had the signatures of two versions of the Datacrime virus. I happened to loose the listings and to make matters worse I found out I also had discarded the digest from my mailbox. I wonder if someone could send me this signatures as soon as possible and also show me an effective way to look for them in my hard disk. As a matter of fact it would be of great help to receive all the known virus signatures, although I guess I might be asking too much. I study at COPPE/UFRJ in Rio de Janeiro and a couple of months agoall this fuss about computer viruses was like Science Fiction for me. I had never seen any kind of it, and thought that it would take a long time before I had any trouble with them. In Brazil there are no networks like CompuServe, The Source, PCMagnet, etc. so I thought that the "problems" that affect Europe or North America couldn't reach us so fast for they would not be downloaded. But I was quite wrong. About two moths ago I have seen Bouncing-ball and JV infect the whole Lab in which I work. And worse than that : they have got to my hard disk. After running a program that kill BB and JV I have run Norton Utilities to look for the string "sUMsDos" and it found four instances of it. I still do not know if they belong to sectors in use by .EXE or .COM filesbut I must say I'm worried. There is a strong possibily that other evil creatures lurk in my system just waiting for the day to come up and make a big mess. I would be very grateful if someone could help me to make a list of methods to take this orcs out from our hard disks and develop anti-virus programs. I have appreciated the help contained in the VIRUS-L disgests but sometimes I feel I have missed a lot of the basic information. [Ed. From an earlier editorial comment (v2i195): In VIRUS-L volume 2 issue 192, Charles M. Preston states that a) Viruscan V36 can detect Datacrime and that b) Datacrime can be identified by the hex string EB00B40ECD21B4 (1168 version) or 00568DB43005CD21 (1280 version). Note that a hex string search can be done via the DEBUG 'S' command (e.g., "S CS:100 FFFF hex_string" at the DEBUG prompt), if my memory of MS-DOS is correct. ] Thanks a lot and greetings from Brazil Luiz Felipe Perrone COS99284@UFRJ - Bitnet ------------------------------ End of VIRUS-L Digest ********************* 29-Sep-89 15:11:20-GMT,17568;000000000001 Received: from RUTVM1.RUTGERS.EDU by topaz.rutgers.edu (5.59/SMI4.0/RU1.1/3.04) id AA25448; Fri, 29 Sep 89 11:07:42 EDT Message-Id: <8909291507.AA25448@topaz.rutgers.edu> Received: from RUTVM1.RUTGERS.EDU by RutVM1.Rutgers.Edu (IBM VM SMTP R1.2.1MX) with BSMTP id 3926; Fri, 29 Sep 89 10:27:12 EDT Received: from RUTVM1.LISTSERV by RUTVM1.RUTGERS.EDU (Mailer R2.04RU) with BSMTP id 3922; Fri, 29 Sep 89 10:26:14 EDT Date: Fri, 29 Sep 89 07:15:34 EDT Reply-To: VIRUS-L@ibm1.cc.lehigh.edu Sender: Virus Discussion List From: "The Moderator Kenneth R. van Wyk" Subject: VIRUS-L Digest V2 #207 Comments: To: VIRUS-L@ibm1.cc.lehigh.edu To: Multiple recipients of list VIRUS-L VIRUS-L Digest Friday, 29 Sep 1989 Volume 2 : Issue 207 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: Tiger Team comments DATACRIME II INFO (PC) Tiger teams attempting to penetrate corporate machines at night New virus on a PC ?? Virus detector program (PC) Re: Anti-viral hard disk controllers Re: Review of NIST anti-virus paper... When is a virus not a virus? Cascade in Sargon III (PC) ViruScan Length (PC) Oct 13 PC virus question FixCrime.arc (PC) --------------------------------------------------------------------------- Date: Thu, 28 Sep 89 07:41:32 -0400 From: dmg@lid.mitre.org (David Gursky) Subject: Re: Tiger Team comments In Virus-L #205, Steve and had some good comments about my Tiger Team suggestion. Here are some answers to their comments: RE: Most viruses are not spread by someone sneaking in at night... Absolutely true. The objective of this proposal would be to ensure that users are following a published anti-virus strategy, beyond simply backing up the data. If the user targeted by the Tiger Team is following the procedures properly, then the virus should not be able to get in. For instance, say the policy reads "All Macintosh computers shall run Gatekeeper". Gatekeeper is very effective at stopping nVir. If the Tiger Team attempts to infect a Mac with nVir, and the attempt fails, the user of the system is not properly following the established procedure. RE: What corporation is willing to take the risk of letting someone *tamper* with the computers which the company depends upon, especially when proper operating procedures will offer you very good protection? Good question. I would hope any company worth its salt. The objective of the "Tiger Teams" is to help ensure the corporate anti-virus policy is being adhered to. "Proper operating procedures" per se do not prevent an infection, *following* those procedures do. RE: Can you guarantee that the "Team" will not do damage?... In order for this proposal to be effective, the TT must do a complete backup of the system's data before proceding (I suspect an image backup would be preferred in this instance), and a restore afterward, regardless of whether the team succeeds or fails. RE: If they are introducing live viruses, ... no one can guarantee the virus will be benign in all situations... I have a problem with this suggestion. Viruses (even nasty ones) such as nVIR, (c) Brain, Lehigh, and so on are well understood. If I start with a "known" strain of one of these (and there are libraries out there of unmodified versions of these and other viruses), I know exactly how a virus will behave under any set of conditions. Please also remember that I proposed using a "neutered" version of a virus. Using (c) Brain as an example, if the logic-bomb or time-bomb is removed from it, leaving only the infector, it's hard to say that such a neutered virus proposes a serious threat to a user when used by a TT to check for the use of anti-virus procedures. RE: If the tiger team fails to exterminate ALL copies of the virus there is the possibility of virus parinoia (sic), files that grow in size for no good reason, and the possibility of lost data thru virus malfunctions. See my earlier comment about backups and neutered versions. RE: The virus would be released in a unsuspecting work area. The presence of strangers insisting on checking every disk that leaves the area would cause chaos. As described above, the virus would not be released in an unsuspecting work area. Tiger Teams are used as a method to test the effectiveness of a given policy. If the users within a given work area are not following an established anti-virus policy (it is taken as a given the suggestion of TT is only valid where such a policy exists, for the exact reason you point out) then they are at risk for a virus infection, and poss a risk for other computing resources (oops! Poss = pose). RE: "Controlled" environment Such environments are possible. They are routinely used for the handling of classified materials for example. Again, the effectiveness of the controls directly depends on how well you adhere to them. ------------------------------ Date: 28 Sep 89 23:03:57 +0000 From: edvvie!eliza!andreas@relay.EU.net (Andreas Brandl) Subject: DATACRIME II INFO (PC) Hello out there, a few days ago I read a article about the DATACRIME- virus and how I can find it with search-strings. Yesterday I read in an info-paper from a very, very, very big corporation about them. This paper tells about three versions of DATACRIME. The first two versions only infect COM-files. Their functions are identical, only their increase-sizes are different. One increases the file size by 1168 bytes, and the other by 1280 bytes. DATACRIME II virus is the third version and infects COM and EXE files. In this version COM files grow by 1514 bytes and EXE by a similar, but variable, size. I possibly know the search-string for the third version. But I can give no warranty, that my info is absolut right. The search-string is like the following: 5E81EE030183FE00742A2E8A9403018DBC2901. I hope this is a little help to locate and destroy this virus. Bye bye, Andreas - -- ------------------------------------------------------------------ EDV Ges.m.b.H Vienna Andreas Brandl Hofmuehlgasse 3 - 5 USENET: andreas@edvvie.at A-1060 Vienna, Austria/Europe Tel: (0043) (222) 59907 (8-16 CET) ------------------------------ Date: 28 Sep 89 13:27:06 +0000 From: cpsolv!rhg@uunet.UU.NET (Richard H. Gumpertz) Subject: Tiger teams attempting to penetrate corporate machines at night Why should such a "tiger team" work under cover of dark? Why not "surprise inspections"? "We're from virus security and we're here to help you ..." - -- ========================================================================== | Richard H. Gumpertz rhg@cpsolv.UUCP -or- ...uunet!amgraf!cpsolv!rhg | | Computer Problem Solving, 8905 Mohawk Lane, Leawood, Kansas 66206-1749 | ========================================================================== ------------------------------ Date: 28 Sep 89 20:57:36 +0000 From: cosc75a@uhnix1.uh.edu (Parameshwaran Krishnan) Subject: New virus on a PC ?? Hi, I am working in the College Of Business Admn, of the Univ of Houston. And I am in the RICS Deptt. I manage Novell Networks there. Today there was a report of a virus in a floppy disk. I am listing down its features any body who would have seen it before please inform me 1. how destructive it can be . 2. How can it be disinfected. Features : 1. It seemingly attaches to an exe file. When u try to execute the file it says that the very same file was not found (??). and asks for a path (in this specific instance it was a Wordperfect file. If u executed wp, it said wp.exe not found Please give a path likd c:\wp\wp.exe. I have a feeling that it does this to infect the harddisk too). If the path is given then it goes bonkers. 2. In this case it created a hidden file called Wordperf.cet. It also screws some exe files on the hard disk It took up 660Bytes extra and wrote the wp.exe back again on the disk. I think this might be the virus code. If u want any other feedback please e-mail me and i will send it to u. Thanks in advance, P Krishnan (cosc75a@uhnix1.uh.edu) (create a virus free computer world) ------------------------------ Date: Thu, 28 Sep 89 13:48:53 -0400 From: unhd!stm@uunet.UU.NET (Steven T Mcclure) Subject: Virus detector program (PC) I would be very interested in seeing this program posted, as I don't know much at all about viruses. I have an AT&T PC6300 with MS-DOS 3.0 with a HD, and would like to be able to find out if I have any viruses currently, and would also like to be told if a new one is being introduced into the system. I don't have ftp access, so I would rather see it posted to c.b.i.p, and there are probably other people who know about as much as I do who would be interested also, but aren't news/ftp/bbs wizards. Thanks. -- Steve ------------------------------ Date: Thu, 28 Sep 89 21:02:15 +0000 From: time@oxtrap.oxtrap (Tim Endres) Subject: Re: Anti-viral hard disk controllers Virus infection is not *spread* via hard disks. Floppies and modems are the *movement* medium. I am not sure what advantage this read only hard disk has over simply monitoring the checksum of an application. More importantly, not all computer systems have "read-only" executables. Most notably, the Macintosh stores code in the resource fork of an application, which is *frequently* modified. The move to distributed execution from file servers is slowly changing this, but it remains an issue. We have a program, that once run against an executable, makes it IMPOSSIBLE for a virus to infect that application and be executed. Infection is still possible, but the application will never execute again, thus stopping propogation. This is simply a check sum of the executable set up in a way to inhibit execution once infection has occurred. The use of a quick key word entered by the user at run time prevents the virus from "intelligently" by-passing the check sum. This solves only one facet of the problem, but a large facet it be. ------------------------------ Date: Thu, 28 Sep 89 21:07:32 +0000 From: time@oxtrap.oxtrap (Tim Endres) Subject: Re: Review of NIST anti-virus paper... > Discussion of the NIST virus paper... The paper forwards the myth that programs obtained from public sources (bulletin boards; public network libraries) are inheritely tainted, and that shareware/freeware/etc. should really be avoided. By the same token, the paper forwards the myth that commercially obtained applications are inheritly untainted. Sounds like the committee was seated with commercial software vendors! ------------------------------ Date: 28 Sep 89 20:38:05 +0000 From: mrsvr!gemed.mrisi!davej@csd4.csd.uwm.edu (David Johnson) Subject: When is a virus not a virus? The following article copied without permission from the Milwaukee Sentinel, Thursday, September 28, 1988 to promote discussion on the ethics involved, legal implications (especially if Lab Force didn't answer their phone on a Saturday :-)), etc. I have no interest nor association with any of the parties mentioned in the article below; I just thought it would provide some interesting beginnings for discussion. I'm especially interested in hearing about "good faith" legal ramifications of the software described below. === BEGIN ARTICLE "FIRM SAYS 'VIRUS' ENSURES PAYMENT" By Mike Mulvey Sentinel staff writer The "viruses" that allegedly infected a computer system serving three Milwaukee-area hospitals were actually fail-safe devices installed by the manufacturer to ensure payment on the system, the company's president said Wednesday. Robert C. Lewis, president of Lab Force Inc. in Dallas, Texas, vehemently denied allegations that his company intentionally introduced viruses to sabotage the computer network that provided laboratory test results. "The allegations are totally without merit," Lewis said. "It is insane." "We have not and never will cause a virus to disrupt a computer system." Federal Judge John W. Reynolds issued a temporary restraining order Tuesday barring the Dallas company from introducing any more alleged viruses into the computer system. The computer network run by Franciscan Shared Laboratory Inc. services St. Michael and St. Joseph's Hospitals in Milwaukee and Elmbrook Memorial Hospital in Brookfield. Franciscan, of 11020 W. Plank Ct., Wauwatosa, file a lawsuit Tuesday in Federal Court, alleging Lab Force introduced a computer virus that disabled the system Sept. 16 and another virus scheduled to be activated Nov. 15. The suite alleged actions by Lab Force were endangering the lives of patients at the three hospitals. A hearing on the case is scheduled for Oct. 6 in Federal Court "We will let the evidence speak for itself. We've done what we believe is in the beset interest of our client and its patients," said attorney John Busch, who is representing Franciscan. "Lewis may deny allegations of sabotage, but he doesn't deny the fact that the system was down." Lewis said the system began operation in April 1988, although Lab Force still is adding to the network. He said the system always had had a "key," a device that locks out the user if a payment schedule isn't kept or a licensing agreement isn't honored. Although Franciscan had been making its payments on time, the key that originally was set to shut down the system Sept. 16 was not rescheduled for a later date because of a mistake by a Lab Force technician, Lewis said. When the technician was notified that the computer system shut down Sept. 16, he immediately corrected the problem by rescheduling the key for Nov. 15, said Jerry Levine, a consultant for Lab Force. "It was a mistake. Our operator screwed up. There has never been a virus in there. There has only been a simple key." "Keys are commonly used by hundreds, if not thousands, of software companies," Levine said. "Until software is accepted and paid for, the only protection a software company has against the equipment being stolen is to place a key in the system." Lewis said Lab Force was considering filing a countersuit against Franciscan for damage done to the Dallas company's reputation. === END ARTICLE - -- David J. Johnson - Computer People Unlimited, Inc. @ GE Medical Systems gemed!python!davej@crd.ge.com - OR - sun!sunbird!gemed!python!davej "What a terrible thing it is to lose one's mind." - Dan Quayle ------------------------------ Date: Thu, 28 Sep 89 12:30:50 +0000 From: Fridrik Skulason Subject: Cascade in Sargon III (PC) I just received a report of a shrink-wrapped and write-protected copy of Sargon III arriving infected with the cascade (1704-A) virus. The store selling the program did not have any more copies, but since they do not allow the return of games, the disk must have been infected outside of Iceland. Has anybody else seen found an infected original of this program ? --- frisk ------------------------------ Date: Thu, 28 Sep 89 07:19:19 -0700 From: portal!cup.portal.com!Alan_J_Roberts@Sun.COM Subject: ViruScan Length (PC) John McAfee asked me to forward the following message: My apologies to the VIRUSCAN user community about my premature announcement some months back that VIRUSCAN would always remain 34400 bytes long. I am old enough to have known better. Architectural changes brought about by newer viruses have necessitated a changing size for some versions. Version 39 in particular, has been virtually re-written to double its speed, link with the SHEZ program to scan archived files and provide an individual file scan if requested. Such changes can't be squeezed into the original 34400 bytes. I accept the title of idiot from anyone who wishes to confer it on me. Future versions of SCAN will contain the file size in the documentation, and sizes will be appropriately advertised. John McAfee ------------------------------ Date: Thu, 28 Sep 89 14:48:00 -0600 From: Frank Simmons Subject: Oct 13 PC virus question I am the editor of our Computer center newsletter. I want to include an article in our early October issue about this Oct 13 virus. Has anyone any concrete facts about this I can relate and secondly what hope/vaccines can I offer my readership? Frank Simmons ------------------------------ Date: Thu, 28 Sep 89 18:47:36 -0500 From: jwright@atanasoff.cs.iastate.edu (Jim Wright) Subject: FixCrime.arc (PC) New anti-viral, sent directly to me by the author. fixcrime.arc Will fix files infected by DataCrime virus. Operates only on .COM files, not .EXE. Has programs to combat three different strains of DataCrime. *Use with caution!* FIXCRIME.ARC Removes infections of DataCrime virus Jim ------------------------------ End of VIRUS-L Digest ********************* 2-Oct-89 17:17:43-GMT,19979;000000000001 Received: from RUTVM1.RUTGERS.EDU by topaz.rutgers.edu (5.59/SMI4.0/RU1.1/3.04) id AA14240; Mon, 2 Oct 89 13:14:41 EDT Message-Id: <8910021714.AA14240@topaz.rutgers.edu> Received: from RUTVM1.RUTGERS.EDU by RutVM1.Rutgers.Edu (IBM VM SMTP R1.2.1MX) with BSMTP id 0408; Mon, 02 Oct 89 13:07:03 EDT Received: from RUTVM1.LISTSERV by RUTVM1.RUTGERS.EDU (Mailer R2.04RU) with BSMTP id 0404; Mon, 02 Oct 89 12:13:53 EDT Date: Mon, 2 Oct 89 07:19:41 EDT Reply-To: VIRUS-L@ibm1.cc.lehigh.edu Sender: Virus Discussion List From: "The Moderator Kenneth R. van Wyk" Subject: VIRUS-L Digest V2 #208 Comments: To: VIRUS-L@ibm1.cc.lehigh.edu To: Multiple recipients of list VIRUS-L VIRUS-L Digest Monday, 2 Oct 1989 Volume 2 : Issue 208 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: How can I get SCANV3x ??? paper comparing biological and computer viruses MILIVIRUS REPLY Re: MILIVIRUS REPLY Jerusalem virus infection, query (PC New virus? (Mac) Followup on new virus (Mac) Re: F-PROT anti-virus package (PC) Virus Protection Apple II Viruses Flushot+ and Artic speech package (PC) RE: Tiger teams at night RE: Review of NIST anti-virus paper... RE: Tiger Teams --------------------------------------------------------------------------- Date: 28 Sep 89 19:01:39 +0000 From: smg%eedsp@gatech.edu (Steve McGrath) Subject: How can I get SCANV3x ??? Could some kind soul please tell me where I can get a copy of the SCANV program (or send it to me, if, as I believe, it is shareware)? I have been trying to call the BBS at (408)988-4004 with no success, and the more I read about the viri which are out there the more apprehensive I am getting. I don't, by the way, have access to Compuserve. Thanks in advance, Stephen - -- Stephen McGrath Georgia Tech, School of EE, DSP Lab, Atlanta, GA 30332 (404)894-3872 smg@eedsp.gatech.edu ------------------------------ Date: Thu, 28 Sep 89 11:19:13 -0400 From: Peter Jaspers-Fayer Subject: paper comparing biological and computer viruses This is an outline for a semi-serious paper on the similarities between biological and computer viruses, and the efforts to understand and combat them. I present it here in the hopes that others may wish to contribute a paragraph or so (sorry no money, but I'll give credit for any material I receive). - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Loosely termed, a virus is a "piece of information" that replicates itself by using it's host's own machinery. Methods of entry into the host system are various. The infection often has a latency period that differs from one species of virus to another. They may, in fact, appear to be entirely benign. Viruses often "hide" in specific parts of the infected system, sometimes multiplying there, sometimes completely dormant, until some external event triggers the onset of the symptoms. Concerning the effort to understand and combat biological and computer viruses; there are also many correspondences between the identification, classification, taxonomy, evolutionary theory and epidemiology of the two disciplines. Often in reading the network discussion list "VIRUS-L", I am struck by the familiarity (my own background is biology) of the arguments that have arisen about: - - How best to identify a new virus, - - What to name it, - - When it started, - - Where it originated, - - It's relation to other viruses, - - The possible evolutionary path, - - What methods of infection there are, - - The ways a virus can combat detection and defences, - - How quickly it spreads, - - The percentage of the host population that is infected, - - What the latency period is, and how the onset of symptoms are triggered. The only absolutely sure way to understand the virus is to dis- assemble it into it's component parts, and read the code. Unfortunately, we are only recently able to disassemble the simplest of the biological virus, and the ability to understand all of the approximately 10K instructions of that simple virus is many years away. What other analogies can you see? Can you expand on any of the above? Stretching things just a little bit further, there are analogies between: Biological Computer - -------------------------------- ----------------------------- Atlanta Center for Disease Control - Computer Virus Industry Association DNA viruses - Boot-Sector Viruses RNA viruses - .EXE, .COM resident viruses AIDS - A (as yet uninvented - I hope) virus that seeks out and destroys only anti-viral programs, leaving you prone to infection by other viruses. I'd like to flesh this out a bit. Suggestions need not be serious, and flights of fancy welcomed. The material may be used in a talk we are giving on computer viruses and other ills. Please reply directly to me at SofPJF@VM.UoGuelph.Ca, or SOFPJF@UOGUELPH.BITNET Thanks. /PJ ------------------------------- First Law of Wing Walking: Never leave hold of what you have got until you have got hold of something else. ------------------------------ Date: Thu, 28 Sep 89 11:06:00 -0500 From: JEWALSH%FORDMURH.BITNET@VMA.CC.CMU.EDU Subject: MILIVIRUS REPLY Although I haven't gotten my feet too wet with the administrative functions of the Army, as far as I can tell: a. In the combat service support branches, e.g.: Adjutant General Finance Corps, etc., the only C.O.A. for dealing with system malfunctions is to call the programmers in. b. On the combat support level, e.g.: branches like Air Defense Artillery may operate with safeguards and procedures when dealing with viruses. Considering that it is equipment that safeguards our nation's defense, one would HOPE that it is resistant to viruses. But, more than anything else, I have a feeling that it's relegated to the knowledgable computer operators to resolve problems with the systems. c. Combat Arms branches, e.g.: Infantry, Artillery, and Armor, don't do a lot with computer systems except on the unit level. (Within individual tanks, or on the platoon level for troop movement, etc.) The level to which it is prone to viruses is, in my estimation, minimal, and the ease by which the components can be replaced takes away the risk. If anyone knows more about the Army's Plan on Viruses, please post! I'd be interested to learn about it. Jeffrey Walsh Fordham University BITNET%"JEWALSH@FORDMURH" ------------------------------ Date: Thu, 28 Sep 89 14:46:25 -0400 From: "Dennis G. Rears (FSAC)" Subject: Re: MILIVIRUS REPLY Jeffrey, you write: > a. In the combat service support branches, e.g.: Adjutant General > Finance Corps, etc., the only C.O.A. for dealing with system > malfunctions is to call the programmers in. Also Ordnance, Transportation, JAG, & Chaplain Corps. > b. On the combat support level, e.g.: branches like Air Defense > Artillery may operate with safeguards and procedures when dealing > with viruses. Considering that it is equipment that safeguards > our nation's defense, one would HOPE that it is resistant to > viruses. But, more than anything else, I have a feeling that > it's relegated to the knowledgable computer operators to resolve > problems with the systems. Air Defense is a combat arms branch. Signal, Military Police, Military Intelligence, and Chemical Corps are service. >If anyone knows more about the Army's Plan on Viruses, please post! I'd be >interested to learn about it. Overall DOD has done little or anything. They were one of the last to know about the worm incident. They care more about administrative security than real security issues. (My opinion only!) Dennis ------------------------------ Date: Fri, 29 Sep 89 08:46:48 -0500 From: Jeff Medcalf Subject: Jerusalem virus infection, query (PC) The PC lab at the Engineering Computer Network, University of Oklahoma, has detected multiple virus infections (mostly Jerusalem virus) on its PCs. The viruses were found and removed with Unvirus, with thanks to its authors. However, I would like to find some programs which would detect and remove more than 7 viruses. Any information regarding anti-viral archive sites, anti-viral programs, and documentation would be greatly appreciated. Also, how many viruses have been identified, and which are the largest threats to security in the United States of America? Thank you ------------------------------ Date: 29 Sep 89 15:02:38 +0000 From: jap2_ss@uhura.cc.rochester.edu (Joseph Poutre) Subject: New virus? (Mac) We here at the University of Rochester may have discovered a new virus, or a variation on a theme. What it does is infect Macwrite and the Chooser, so that when a document is printed, Macwrite crashes. The virus changes the name to Macwight or Macwite, but this is the only clue so far. I am trying to get more data, more none is forthcoming. I will do what i can today and tommorrow, and give furthr reports. Disinfectant 1.1 doesn't work, so please email me the latest version of disinfectant to try. The sooner the better, because the Vice-Provost's office is infected, and they may lose a 75 page report for the government. (What, no backups? What do you think. Argh.) The Mad Mathematician jap2@uhura.cc.rochester.edu Understand the power of a single action. (R.E.M.) ------------------------------ Date: 29 Sep 89 19:22:37 +0000 From: jap2_ss@uhura.cc.rochester.edu (Joseph Poutre) Subject: Followup on new virus (Mac) This is a followup to my earilier report. I will try to give more details from my and others investigations. The virus definatly attacks Macwrite. It adds a str ID 801 and modifies the icon to say Macwite instead of the standard application icon. The application increases in size by 104 bytes, 56 in the string. they are added in sector 014F, according to Fedit Plus 1.0. It also attacks the system, in an unknown fashion. I was able to induce it to do something by repeated Get Infos. This may be a counter towards a more fatal outcome. Some of the disks have crashed after giving the This is not a Macintosh disk. Shall I initialize it? warning. This happens almost immediatly after attempts to print. The chooser is unable to find printer resources, and claims there are none. When the File locked, Lock, Bozo and File Protect bits are set, the virus apparently cannot infect. It doesn't appear able to attack a disk write protected by the corner tab, either. Tommorrow I will be performing further experimenets, and will upload exact locations for the added code, and probably the string listing, too. No anti-virus program has been able to find it, including Interferon, Virus Rx, Anti-pan, and Disinfectant 1.2. If this is recognized by anyone, please email me ASAP at the address below with devirusing help. If not, I will try to do everything I can. Thank you for your time and effort. The Mad Mathematician jap2@uhura.cc.rochester.edu Understand the power of a single action. (R.E.M.) ------------------------------ Date: Fri, 29 Sep 89 17:44:08 -0400 From: dptg!att!ll1a!nesac2!jec@rutgers.edu Subject: Re: F-PROT anti-virus package (PC) Yes, there's probably enough interest to warrant posting the program. But will you be able to keep it current, and get the current version to registered users as fast as the virus? John - --- USnail: John Carter, AT&T, 401 W. Peachtree, FLOC 2932-6, Atlanta GA 30308 Video: ...att!nesac2!jec ...attmail!jecarter Voice: 404+581-6239 The machine belongs to the company. The opinions are mine. ------------------------------ Date: Fri, 29 Sep 89 19:33:00 -0400 From: JHSangster@DOCKMASTER.ARPA Subject: Virus Protection It seems to me that this whole problem will be largely solved when and only when the vendors all start "signing" their software with a digital signature based on public key cryptography. At least then any one who wishes to check a program for authenticity need only check to see that it passes the digital signature check with the alleged vendor's public key. Of course you also have to know that the checking program hasn't been tampered with, the hardware hasn't been tampered with, etc., etc., but at least we would have a starting point for software authentication. The signature approach and the use of signature checking seem to me the only way to make definitive progress against viruses. All other approaches are dependent on details of the viruses code, which as we have seen change with time and with each new virus. Digital signatures will let us check that at least a trusted source has put its signature on the code, and that it has not been altered since then. Software developers will then have to get serious about preventing viruses from creeping in at the factory if they are not already serious. If members of the appropriate software standards body are listening, I hope they give consideration to such a standard ASAP. The standard should allow for both existing and future developers as well as private individuals (hobbyists who may develop freeware) to have a unique public key. Then software users who neglect to check the signature use the software at their own risk, but if they experience damage and can prove it, they will be in a position to apply some heat to the vendor who provided the signed, but infected, software. The ideal way to implement checking would be to build it into the loader. This may become feasible if a worldwide standard is adopted. Meanwhile checking could be implemented in a way which did not require ROM modifications. The standard could provide for inclusion of the vendor's public key and the resulting signature in the format of any loadable file. - -John Sangster SPHINX Technologies, Incorporated (617) 235-8801 / P.O. Box 81287, Wellesley Hills, MA 02181 ------------------------------ Date: Fri, 29 Sep 89 19:48:56 -0500 From: davidbrierley@lynx.northeastern.edu Subject: Apple II Viruses If any readers of VIRUS-L have any information on viruses affecting Apple II series computers I would be very appreciative if they could e-mail it to me. I am especially interested in public domain and shareware antiviral programs. Please note that I have virus information posted in Info-Apple. Thank you. David R. Brierley davidbrierley@lynx.northeastern.edu ------------------------------ Date: Fri, 29 Sep 89 22:54:00 -0400 From: Yahn Zawadzki Subject: Flushot+ and Artic speech package (PC) I am new to this list, and don't know much abot various anti-viral programs for the IBM - but I have run into some problems I think may be caused by one of them. In our labs, I am setting up a workstation for visually impaired - the major role plays there a package called ARTIC - hardware/software driven speech synthesizer. Part of that program is a memory-resident code which can intercept any program, and provide support for ARTIC's hardware from within. This way, one can have the machine read the screen, or just read the key combinations, etc. Now, on the same drive I have installed Flushot+ (students have access to the station). I am not familiar with Flushot or Flushot+, so I can't tell what is happening: at all times, there is a '+' in the top right corner of the screen, and some of the functions of ARTIC are for some reason disabled. I dug through ARTIC's manuals - there is no mention of anything which could explain the situation.. Anyone out there - PLEASE tell me whether it is Flushot intefering with ARTIC here (I suspect '+' signifies something!) or am I looking in the wrong direction... If anyone out there has used ARTIC business version - and knows of an anti-virus which will not react to ARTIC's software - please let me know..! Thanks - Yahn. - ------------------------------------------------------------------------------- Yahn Zawadzki Bitnet: S72UZAW @ TOWSON Student Lab Assistant INET: yahn@towson.edu Towson State Univ. Disclaimer: Any Views Expressed Above Are Those Of Mine And Not Of The Towson State University. A N D Y E S - I A M A M A C P E R S O N !!! - ------------------------------------------------------------------------------- ------------------------------ Date: Sat, 30 Sep 89 09:18:16 -0400 From: dmg@lid.mitre.org (David Gursky) Subject: RE: Tiger teams at night In the VIRUS-L Digest V2 #207, cpsolv!rhg@uunet.UU.NET (Richard H. Gumpertz) writes: > Why should such a "tiger team" work under cover of dark? Why not "surprise > inspections"?... Because people use their computers during the day. If the Tiger Team finds the person is following all the proper anti-viral procedures, why should the Tiger Team interrupt the user's normal workday? ------------------------------ Date: Sat, 30 Sep 89 09:30:38 -0400 From: dmg@lid.mitre.org (David Gursky) Subject: RE: Review of NIST anti-virus paper... In the VIRUS-L Digest V2 #207, time@oxtrap.oxtrap (Tim Endres) writes: > Sounds like the committee was seated with commercial software vendors! The NIST paper was written by two staff members there, and is not a committee report. I've received some feedback from NIST on my comments to the effect of "Good point. We did not intend the bias towards commercial software, but it is certainly there". ------------------------------ Date: Sat, 30 Sep 89 14:39:00 -0400 From: "Thomas B. Collins, Jr." Subject: RE: Tiger Teams Another thought on the Tiger Teams... It doesn't make much sense to me. If I don't add any new software to my system at work, I'm not going to worry about viruses. Say I get my new system, put all the software on it, and run a few virus scanners that turn up nothing. I then run all applications from my hard drive, and don't use any floppy disks. It wouldn't make sense for me to check my hard drive every day for viruses, because they don't just pop up from nowhere. If I did add software to my system, I would check it for viruses before adding it. I think it would make more sense for the Tiger Teams to come in in the middle of the day, ask you to please save your work, and then run a virus checker on your system. If anything is found, you are "cited" as letting a virus into your system. If you're clean, you go back to work, and the Tiger Team moves on. - ------- Tom "Shark" Collins Since ICS is comprised of 2 people, my views tbc101@psuvm.psu.edu are the opinion of at least 50% of the company. ------------------------------ End of VIRUS-L Digest ********************* 2-Oct-89 17:21:44-GMT,28202;000000000001 Received: from RUTVM1.RUTGERS.EDU by topaz.rutgers.edu (5.59/SMI4.0/RU1.1/3.04) id AA14484; Mon, 2 Oct 89 13:18:36 EDT Message-Id: <8910021718.AA14484@topaz.rutgers.edu> Received: from RUTVM1.RUTGERS.EDU by RutVM1.Rutgers.Edu (IBM VM SMTP R1.2.1MX) with BSMTP id 0415; Mon, 02 Oct 89 13:13:13 EDT Received: from RUTVM1.LISTSERV by RUTVM1.RUTGERS.EDU (Mailer R2.04RU) with BSMTP id 0412; Mon, 02 Oct 89 12:14:12 EDT Date: Mon, 2 Oct 89 07:45:16 EDT Reply-To: VIRUS-L@ibm1.cc.lehigh.edu Sender: Virus Discussion List From: "The Moderator Kenneth R. van Wyk" Subject: VIRUS-L Digest V2 #209 Comments: To: VIRUS-L@ibm1.cc.lehigh.edu To: Multiple recipients of list VIRUS-L VIRUS-L Digest Monday, 2 Oct 1989 Volume 2 : Issue 209 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: Introduction to the anti-viral archives Amiga anti-viral archive sites Apple II anti-viral archive sites Atari ST anti-viral archive sites Documentation anti-viral archive sites IBMPC anti-viral archive sites Macintosh anti-viral archive sites UNIX anti-viral archive sites Why not change OS? M-1704.EXE (PC) Follow up on Tiger Team comments. Configuring FluShot (PC) Re: Tiger Team comments Future AV software (PC) The book you've all been waiting for? --------------------------------------------------------------------------- Date: 30 Sep 89 09:23:48 +0000 From: jwright@atanasoff.cs.iastate.edu (Jim Wright) Subject: Introduction to the anti-viral archives # Introduction to the Anti-viral archives... # Listing of 30 September 1989 This posting is the introduction to the "official" anti-viral archives of virus-l/comp.virus. With the generous cooperation of many sites throughout the world, we are attempting to make available to all the most recent news and programs for dealing with the virus problem. Currently we have sites for Amiga, Apple II, Atari ST, IBMPC, Macintosh and Unix computers, as well as sites carrying research papers and reports of general interest. If you have general questions regarding the archives, you can send them to this list or to me. I'll do my best to help. If you have a submission for the archives, you can send it to me or to one of the persons in charge of the relevant sites. If you have any corrections to the lists, please let me know. ------------------------------ Date: 30 Sep 89 09:25:11 +0000 From: jwright@atanasoff.cs.iastate.edu (Jim Wright) Subject: Amiga anti-viral archive sites # Anti-viral archive sites for the Amiga # Listing last changed 30 September 1989 cs.hw.ac.uk Dave Ferbrache NIFTP from JANET sites, login as "guest". Electronic mail to . Main access is through mail server. The master index for the virus archives can be retrieved as request: virus topic: index The Amiga index for the virus archives can be retrieved as request: amiga topic: index For further details send a message with the text help The administrative address is ms.uky.edu Sean Casey Access is through anonymous ftp. The Amiga anti-viral archives can be found in /pub/amiga/Antivirus. The IP address is 128.163.128.6. uk.ac.lancs.pdsoft Steve Jenkins Service for UK only; no access from BITNET/Internet/UUCP Terminals : call lancs.pdsoft, login as "pdsoft", pwd "pdsoft" FTP : call lancs.pdsoft, user "pdsoft", pwd "pdsoft". Pull the file "help/basics" for starter info, "micros/index" for index. Anti-Viral stuff is held as part of larger micro software collection and is not collected into a distinct area. uxe.cso.uiuc.edu Mark Zinzow Lionel Hummel The archives are in /amiga/virus. There is also a lot of stuff to be found in the Fish collection. The IP address is 128.174.5.54. Another possible source is uihub.cs.uiuc.edu at 128.174.252.27. Check there in /pub/amiga/virus. ------------------------------ Date: 30 Sep 89 09:27:01 +0000 From: jwright@atanasoff.cs.iastate.edu (Jim Wright) Subject: Apple II anti-viral archive sites # Anti-viral archive sites for the Apple II # Listing last changed 30 September 1989 brownvm.bitnet Chris Chung Access is through LISTSERV, using SEND, TELL and MAIL commands. Files are stored as apple2-l xx-xxxxx where the x's are the file number. cs.hw.ac.uk Dave Ferbrache NIFTP from JANET sites, login as "guest". Electronic mail to . Main access is through mail server. The master index for the virus archives can be retrieved as request: virus topic: index The Apple II index for the virus archives can be retrieved as request: apple topic: index For further details send a message with the text help The administrative address is uk.ac.lancs.pdsoft Steve Jenkins Service for UK only; no access from BITNET/Internet/UUCP Terminals : call lancs.pdsoft, login as "pdsoft", pwd "pdsoft" FTP : call lancs.pdsoft, user "pdsoft", pwd "pdsoft". Pull the file "help/basics" for starter info, "micros/index" for index. Anti-Viral stuff is held as part of larger micro software collection and is not collected into a distinct area. ------------------------------ Date: 30 Sep 89 09:28:26 +0000 From: jwright@atanasoff.cs.iastate.edu (Jim Wright) Subject: Atari ST anti-viral archive sites # Anti-viral archive sites for the Atari ST # Listing last changed 30 September 1989 cs.hw.ac.uk Dave Ferbrache NIFTP from JANET sites, login as "guest". Electronic mail to . Main access is through mail server. The master index for the virus archives can be retrieved as request: virus topic: index The Atari ST index for the virus archives can be retrieved as request: atari topic: index For further details send a message with the text help The administrative address is . panarthea.ebay Steve Grimm Access to the archives is through mail server. For instructions on the archiver server, send help to . uk.ac.lancs.pdsoft Steve Jenkins Service for UK only; no access from BITNET/Internet/UUCP Terminals : call lancs.pdsoft, login as "pdsoft", pwd "pdsoft" FTP : call lancs.pdsoft, user "pdsoft", pwd "pdsoft". Pull the file "help/basics" for starter info, "micros/index" for index. Anti-Viral stuff is held as part of larger micro software collection and is not collected into a distinct area. ------------------------------ Date: 30 Sep 89 09:28:58 +0000 From: jwright@atanasoff.cs.iastate.edu (Jim Wright) Subject: Documentation anti-viral archive sites # Anti-viral archive sites for documentation # Listing last changed 30 September 1989 cs.hw.ac.uk Dave Ferbrache NIFTP from JANET sites, login as "guest". Electronic mail to . Main access is through mail server. The master index for the virus archives can be retrieved as request: virus topic: index The index for the **GENERAL** virus archives can be retrieved as request: general topic: index The index for the **MISC.** virus archives can be retrieved as request: misc topic: index **VIRUS-L** entries are stored in monthly and weekly digest form from May 1988 to December 1988. These are accessed as log.8804 where the topic substring is comprised of the year, month and a week letter. The topics are: 8804, 8805, 8806 - monthly digests up to June 1988 8806a, 8806b, 8806c, 8806d, 8807a .. 8812d - weekly digests The following daily digest format started on Wed 9 Nov 1988. Digests are stored by volume number, e.g. request: virus topic: v1.2 would retrieve issue 2 of volume 1, in addition v1.index, v2.index and v1.contents, v2.contents will retrieve an index of available digests and a extracted list of the the contents of each volume respectively. **COMP.RISKS** archives from v7.96 are available on line as: request: comp.risks topic: v7.96 where topic is the issue number, as above v7.index, v8.index and v7.contents and v8.contents will retrieve indexes and contents lists. For further details send a message with the text help The administrative address is lehiibm1.bitnet Ken van Wyk new: This site has archives of VIRUS-L, and many papers of general interest. Access is through ftp, IP address 128.180.2.1. The directories of interest are VIRUS-L and VIRUS-P. uk.ac.lancs.pdsoft Steve Jenkins Service for UK only; no access from BITNET/Internet/UUCP Terminals : call lancs.pdsoft, login as "pdsoft", pwd "pdsoft" FTP : call lancs.pdsoft, user "pdsoft", pwd "pdsoft". Pull the file "help/basics" for starter info, "micros/index" for index. Anti-Viral stuff is held as part of larger micro software collection and is not collected into a distinct area. unma.unm.edu Dave Grisham This site has a collection of ethics documents. Included are legislation from several states and policies from many institutions. Access is through ftp, IP address 129.24.8.1. Look in the directory /ethics. ------------------------------ Date: 30 Sep 89 09:29:52 +0000 From: jwright@atanasoff.cs.iastate.edu (Jim Wright) Subject: IBMPC anti-viral archive sites # Anti-viral archive for the IBMPC # Listing last changed 30 September 1989 cs.hw.ac.uk Dave Ferbrache NIFTP from JANET sites, login as "guest". Electronic mail to . Main access is through mail server. The master index for the virus archives can be retrieved as request: virus topic: index The IBMPC index for the virus archives can be retrieved as request: ibmpc topic: index For further details send a message with the text help The administrative address is ms.uky.edu Daniel Chaney This site can be reached through anonymous ftp. The IBMPC anti-viral archives can be found in /pub/msdos/AntiVirus. The IP address is 128.163.128.6. uk.ac.lancs.pdsoft Steve Jenkins Service for UK only; no access from BITNET/Internet/UUCP Terminals : call lancs.pdsoft, login as "pdsoft", pwd "pdsoft" FTP : call lancs.pdsoft, user "pdsoft", pwd "pdsoft". Pull the file "help/basics" for starter info, "micros/index" for index. Anti-Viral stuff is held as part of larger micro software collection and is not collected into a distinct area. uxe.cso.uiuc.edu Mark Zinzow This site can be reached through anonymous ftp. The IBMPC anti-viral archives are in /pc/virus. The IP address is 128.174.5.54. vega.hut.fi Timo Kiravuo This site (in Finland) can be reached through anonymous ftp. The IBMPC anti-viral archives are in /pub/pc/virus. The IP address is 128.214.3.82. wsmr-simtel20.army.mil Keith Peterson Direct access is through anonymous ftp, IP 26.2.0.74. The anti-viral archives are in PD1:. Simtel is a TOPS-20 machine, and as such you should use "tenex" mode and not "binary" mode to retreive archives. Please get the file 00-INDEX.TXT using "ascii" mode and review it offline. NOTE: There are also a number of servers which provide access to the archives at simtel. WSMR-SIMTEL20.Army.Mil can be accessed using LISTSERV commands from BITNET via LISTSERV@NDSUVM1, LISTSERV@RPIECS and in Europe from EARN TRICKLE servers. Send commands to TRICKLE@ (for example: TRICKLE@AWIWUW11). The following TRICKLE servers are presently available: AWIWUW11 (Austria), BANUFS11 (Belgium), DKTC11 (Denmark), DB0FUB11 (Germany), IMIPOLI (Italy), EB0UB011 (Spain) and TREARN (Turkey). ------------------------------ Date: 30 Sep 89 09:30:43 +0000 From: jwright@atanasoff.cs.iastate.edu (Jim Wright) Subject: Macintosh anti-viral archive sites # Anti-viral archive sites for the Macintosh # Listing last changed 30 September 1989 cs.hw.ac.uk Dave Ferbrache NIFTP from JANET sites, login as "guest". Electronic mail to . Main access is through mail server. The master index for the virus archives can be retrieved as request: virus topic: index The Mac index for the virus archives can be retrieved as request: mac topic: index For further details send a message with the text help The administrative address is ifi.ethz.ch Danny Schwendener Interactive access through SPAN/HEPnet: $SET HOST 20766 or $SET HOST AEOLUS Username: MAC Interactive access through X.25 (022847911065) or Modem 2400 bps (+41-1-251-6271): # CALL B050 Username: MAC Files may also be copied via SPAN/HEPnet from 20766::DISK8:[MAC.TOP.LIBRARY.VIRUS] rascal.ics.utexas.edu Werner Uhrig Access is through anonymous ftp, IP number is 128.83.144.1. Archives can be found in the directory mac/virus-tools. Please retrieve the file 00.INDEX and review it offline. Due to the size of the archive, online browsing is discouraged. scfvm.bitnet Joe McMahon Access is via LISTSERV. SCFVM offers an "automatic update" service. Send the message AFD ADD VIRUSREM PACKAGE and you will receive updates as the archive is updated. You can also subscribe to automatic file update information with FUI ADD VIRUSREM PACKAGE sumex-aim.stanford.edu Bill Lipa Access is through anonymous ftp, IP number is 36.44.0.6. Archives can be found in /info-mac/virus. Administrative queries to . Submissions to . There are a number of sites which maintain shadow archives of the info-mac archives at sumex: * MACSERV@PUCC services the Bitnet community * LISTSERV@RICE for e-mail users * FILESERV@IRLEARN for folks in Europe uk.ac.lancs.pdsoft Steve Jenkins Service for UK only; no access from BITNET/Internet/UUCP Terminals : call lancs.pdsoft, login as "pdsoft", pwd "pdsoft" FTP : call lancs.pdsoft, user "pdsoft", pwd "pdsoft". Pull the file "help/basics" for starter info, "micros/index" for index. Anti-Viral stuff is held as part of larger micro software collection and is not collected into a distinct area. wsmr-simtel20.army.mil Robert Thum Access is through anonymous ftp, IP number 26.2.0.74. Archives can be found in PD3:. Please get the file 00README.TXT and review it offline. ------------------------------ Date: 30 Sep 89 09:31:34 +0000 From: jwright@atanasoff.cs.iastate.edu (Jim Wright) Subject: UNIX anti-viral archive sites # Anti-viral and security archive sites for Unix # Listing last changed 30 September 1989 # Note that this listing is preliminary, and will likely change. # I know the information is far from complete, but I thought it would # be a good idea to get this out now instead of wait. attctc Charles Boykin Accessible through UUCP. cs.hw.ac.uk Dave Ferbrache NIFTP from JANET sites, login as "guest". Electronic mail to . Main access is through mail server. The master index for the virus archives can be retrieved as request: virus topic: index For further details send a message with the text help The administrative address is netCS Hans Huebner netCS is a public access Unix site in Berlin which is also accessible through UUCP. sauna.hut.fi Jyrki Kuoppala Accessible through anonymous ftp, IP number 128.214.3.119. (Note that this IP number is likely to change.) ucf1vm Lois Buwalda Accessible through... wuarchive.wustl.edu Chris Myers Accessible through anonymous ftp, IP number 128.252.135.4. A number of directories can be found in ~ftp/usenet/comp.virus/*. ------------------------------ Date: Sat, 30 Sep 00 19:89:04 +0000 From: ficc!peter@uunet.uu.net Subject: Why not change OS? Rather than go through all this trouble to keep viruses out of Macs and IBM-PCs, why not abandon the unprotected operating systems wherever possible and switch to UNIX? If you need to run DOS or MacOS software, there are ways of running it under UNIX in both cases: A/UX supports Macintosh software, and the various 80386 versions of UNIX have two DOS emulators that run in the virtual 8086 emulation mode. With no direct access to the hardware possible, and with multiuser security preventing writes to files (at least in the 80386 case), the worst the virus could do would be to infect user-written programs. When they attempted to format the hard disk, or infect installed software, they would simply trap and abort the virtual DOS image. UNIX-based software is extremely unlikely to be infected, since a UNIX virus would have to infect source code to transfer out of a machine. To defuse arguments about the Internet Worm, let us note that this program was restricted to two brands of computer: VAXes and 68000-based Suns. And it infected a network that was deliberately designed to be insecure. No, UNIX is not immune to trojan horses and viruses, but by and large this sort of program is kept uninfectious and benign by the nature of the system. [Ed. I hope that you're wearing asbestos skivvies... :-) ] ------------------------------ Date: Sat, 30 Sep 89 16:38:52 -0500 From: James Ford Subject: M-1704.EXE (PC) I recently downloaded M-1704.ZIP from the Wellspring BBS. After downloading it, I ran SCAN V35 (old, I know) and to my amazement, it said that the file M-1704.EXE was infected with the "1701/1704 Version B virus"! Does this program include a string in it that might cause SCAN to indicate a virus (a false alert) or can I assume that this file is infected?? Please reply direct to me, *not* to VALERT-L....or then again, maybe the response should be posted here. I am under the impression that the Wellspring BBS (1-714-8567996) is an anti-viral storage site. James Ford (205) 348-1713 JFORD1@UA1VM.BITNET ------------------------------ Date: Sun, 01 Oct 89 01:09:25 -0400 From: dmg@lid.mitre.org (David Gursky) Subject: Follow up on Tiger Team comments. There have been a couple messages regarding my Tiger Team suggestion, some of which have some good criticisms, others of which seem to have misread or read something into my message that wasn't there. First and foremost, I must emphasize that this would be one part of an overall anti-virus strategy, and you must take the use of Tiger Teams in a "positive manner", i.e. not to *punish* users who do not follow anti-virus procedures, but to *find* such users, and having found such users, ensure that they do follow the established anti-virus procedures in the future. Punishing users that fail to do so only gets the users mad, and mad users help no one. Second, a couple people have suggested this proposal leaves live viruses floating around desktop computers in the office, after the Tiger Team had successfully penetrated one. I believe I stated in my original proposal that the first step the Tiger Team would take is to create an *image* backup of the system they will try to infect. Regardless of the success or failure in infecting the computer, the disk would be restored from the image backup taken originally. Now should the TT successfully infect the system, the computer would be "disabled"; applying a large label over the CRT would effectively tell a user they are not to use their computer until they have gone over the anti-virus procedures with someone from the "computer services" department went over these procedures with the user. Backing away from the specific subject of Tiger Teams, I wish to emphasize the problem TTs are addressing; enactment of anti-viral procedures. As an example, it is illegal in most states to sell alcohol to adults under 21. In parts of the country which have these laws and *enforce* these laws, the ease of which an adult under 21 can purchase liquor is reduced (that is to say it is harder) over parts of the country which have the laws and do not enforce them well, or do not have the laws. It is a great first step if Acme Industries issues a set of anti-viral guidelines, but unless Acme does something to see to it the employees are following these procedures, then those policies are nothing more than pieces of paper in the users wastebaskets! ------------------------------ Date: Sat, 30 Sep 89 19:56:54 -0700 From: RSRANCH@UCLASSCF.BITNET (Ran Chermesh) Subject: Configuring FluShot (PC) I've d/l FluShot ver. 1.7 from Simtel. When I tried to install it, it looked for the FLUSHOT.DAT file in drive A. If I'm not mistaken, this kind of search was not part of FluShot in the past. I looked for instruction how to configure it to drive C, but couldn't find. Did I miss anything? Can anyone suggest a way to override this default? Temporarily I did override it by preceding the FSP instruction with an ASSIGN a=c instruction. Still, this couldn't be the appropriate solution. Ran Chermesh RSRANCH@UCLASSCF.BITNET p.s. Since I'm not a member of the VIRUS-L, I'll appreciate receiving your solution directly to me. If it is the norm on this list to summarize responses and to resubmit them to the list, please let me know and I'll be glad to comply. ------------------------------ Date: 01 Oct 89 08:23:20 +0000 From: chinet!ignatz@att.att.com Subject: Re: Tiger Team comments The author of the original "Tiger Team" concept responded to a couple of critical postings with some rebuttals. As I read them, he defended the TT concept by emphasizing, several times, that the TT would be checking compliance with anti-viral policies. I ask, if this *is* the goal, couldn't the corporation provide a configuration test program that checked for the existence of corporation-approved software and methods without introducing a virus, and requiring all the intermediate overhead of special backups, etc.? Dave Ihnat Analysts International Corporation, Chicago ignatz@homebru.chi.il.us (preferred return address) ignatz@chinet.chi.il.us ------------------------------ Date: 01 Oct 89 17:58:41 +0000 From: carroll1!tkopp@uunet.UU.NET (Tom Kopp) Subject: Future AV software (PC) I had a thought earlier about a possible future Anti-viral system. It would be software based, therefore subject to its own corruption, however it seems to me to be a mix of the work of Anti-Viral gurus McAfee and Greenberg. It works something like this: A version/variant of ViruScan would run, searching not for viral-identifying code, but rather for the interrupt calls that write to a disk (a la Flu_Shot techniques). When it finds one, it looks in a table to see if that code is allowed. This table could consist of the following format: filename;offset of interrupt;filesize CRC; with the possible inclusion of just WHICH interrupt was attempting to be invoked. The user of the software could either add to the table for software that he/she has written, or wait for updated database listings from whoever wrote/maintained such a program. Also in the vein of Flu_Shot, a list could be maintained of files to 'ignore'. I do see a problem in that setting up the original database to cover the countless programs existing is a truly arduous task, however for a purpose such as this, I would think reputable software companies would provide as much assistance as possible, which could be a lot if the code was written in assembler. Is there some other fundamental element I'm missing, or is this a plausible idea? tkopp@carroll1.cc.edu or uunet!marque!carroll1!tkopp Thomas J. Kopp @ Carroll College 3B2 - Waukesha, WI ------------------------------ Date: Sun, 01 Oct 89 17:58:04 -0400 From: dmg@lid.mitre.org (David Gursky) Subject: The book you've all been waiting for? John McAfee of Interpath, National Bulletin Board Society, and Computer Virs (Virus, not Virs) Industry fame has written a book. Entitled _Computer Viruses, Worms, Data Diddles, Killer Programs, and Other Threats to Your System: What They Are, How They Work, and How to Defend Your PC, Mac, or Mainframe_, it is co-authored with Colin Haynes, and published by St. Martin's Press. I finished reading it today, and this is some preliminary thoughts I have on the book (this message would be more detailed, but I have to catch a plane to New Orleans tonight and I leave in thirty minutes). I do not like this book. I found it to be (at various points) contradictory, incomplete, and alarmist. Before the flame wars begin, let me emphasize that the whole book is not constantly contradictory, incomplete, and or alarmist, nor is any one section all three of those things. Some sections (most notably the first third of the book and the last chapter) are very alarmist. In the final chapter for instance, McAfee quotes some NBBS users about what type of viruses do they see "looming in the distance". One example cited is a modification to the electronic switches used by the phone company to reroute a call placed by caller n to the number dialed by called n-1. A second example would have the computers controlling the nation's traffic lights (the computers are made by one of three companies) all turn green in all directions on a given Friday. I leave it as an exercise to Virus-L readers to find where these are flawed, other than the obvious one that neither of these are viruses per se, but are examples of destructive measure viruses could be put to. In between the beginning and the end of the book, McAfee focuses on a technical discussion of viruses, and he does, alright. There are much better books (IMO) on the market about PC viruses (such as the Compute book) or viruses in general (Ralf Burger's _Computer Viruses, A High Tech Disease_), but if you are comfortable with McAfee's paradigm's, then his work is acceptable. If you are not comfortable with McAfee's paradigm, or if you are concerned with viruses in the Macintosh environment (or to a lesser degree, the mainframe environment), you will get awfully confused. The book has a very heavy PC bias, and (for example) trying to fit McAfee's generic description of viruses into the Macintosh paradigm does not work easily. I will be out of town for two weeks, and Virus-L will be on vacation by the time I get back. When I do get back into town, I will write a more comprehensive review for Virus-L. What it all comes down to is this. McAfee & Haynes' book is no great shakes; it simply is not well written. This is not to call John McAfee names or anything, but "he should not give up his day job". My advice is to buy a copy of the NIST paper (which is shorter, more concise, and has a greater proportion of useful information) and a good set of anti-virus tools for your computer. Viruscan is one of the best for the PC from what I understand, and a bargain at $15. ------------------------------ End of VIRUS-L Digest ********************* 3-Oct-89 11:44:18-GMT,19424;000000000001 Received: from RUTVM1.RUTGERS.EDU by topaz.rutgers.edu (5.59/SMI4.0/RU1.1/3.04) id AA26962; Tue, 3 Oct 89 07:42:52 EDT Message-Id: <8910031142.AA26962@topaz.rutgers.edu> Received: from RUTVM1.RUTGERS.EDU by RutVM1.Rutgers.Edu (IBM VM SMTP R1.2.1MX) with BSMTP id 5007; Tue, 03 Oct 89 07:18:11 EDT Received: from RUTVM1.LISTSERV by RUTVM1.RUTGERS.EDU (Mailer R2.04RU) with BSMTP id 5004; Tue, 03 Oct 89 07:17:31 EDT Date: Tue, 3 Oct 89 07:07:30 EDT Reply-To: VIRUS-L@ibm1.cc.lehigh.edu Sender: Virus Discussion List From: "The Moderator Kenneth R. van Wyk" Subject: VIRUS-L Digest V2 #210 Comments: To: VIRUS-L@ibm1.cc.lehigh.edu To: Multiple recipients of list VIRUS-L VIRUS-L Digest Tuesday, 3 Oct 1989 Volume 2 : Issue 210 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: Why not change OS? re: Future AV software (PC) List of PC viruses VGA2CGA.ARC (or .ZIP) infected with virus (PC) Re: Future AV software (PC) Re: Posting to VALERT-L re: M-1704 (PC) nVIR B (Mac) Re: Viruses in Commercial Software New PC Virus (AIDS Virus) --------------------------------------------------------------------------- Date: 02 Oct 89 00:00:00 +0000 From: David.M..Chess.CHESS@YKTVMV Subject: re: Why not change OS? Hm. You seem to be assuming, among other things, that: - If a virus can't talk directly to the hardware or to files belonging to other folks, it can't do any serious harm, and - UNIX programs are exchanged only as source, not as binaries. I'd disagree with both of those claims; the Jerusalem virus, one of the most widespread and troublesome in the PC world, doesn't talk directly to the hardware, and doesn't rely on being able to write out of the user's own space. I imagine everyone on the list can think of a number of nasty/destructive/confusing things that a virus could do even if it only had access to the user's own data files, and couldn't write direct to hardware (I won't list any here, hehe!). As UNIX and UNIX-derived systems continue to spread beyond the programmer community, program exchange among groups using the same hardware will tend, I would expect, to include more exchange of binaries. I wouldn't expect to see a virus that could infect more than one or two hardware platforms in the near future (cross fingers), but a virus that could spread to any machine in one of the more popular UNIX hardware categories would be quite enough to cause problems for lots of folks! While I don't know of any UNIX viruses at the moment, I would disagree with the suggestion that UNIX is inherently virus-resistant enough to make it worthwhile switching OS's in hopes of being able to forget about virus protection! The same applies to any other general-purpose OS around; viruses *don't* need insecure systems to spread and do Bad Things. That's the whole point... DC IBM T. J. Watson Research Center UNIX is a trademark of AT&T (or Bellcore, or someone like that) ------------------------------ Date: 02 Oct 89 00:00:00 +0000 From: David.M..Chess.CHESS@YKTVMV Subject: re: Future AV software (PC) Unfortunately, it's just about impossible to scan for new viruses by examining the on-disk image of programs, and looking for things like INTs. Three (at least) of the families of PC viruses out in the world today store themselves on disk in "garbled" form, with only a little "degarbler" stored in clear. That degarbler doesn't contain any INTs or other suspicious instructions, and the garbled part of the virus appears to be random data. The nasty instructions don't appear until the virus executes, and the degarbler converts the garbled stuff to code. So it's really only possible to catch these things at runtime (as Flushot+ and similar programs try to do), not on disk... DC ------------------------------ Date: Mon, 02 Oct 89 17:54:26 +0200 From: Y. Radai Subject: List of PC viruses On May 16 I submitted a list of 20 PC viruses to VIRUS-L. Since then, the Terrible Twenty have become the Threatening Thirty (Plus Two). Here's the list updated to the present (well, actually, only to yesterday; at the current rate there'll probably be at least five more today :-) ). PC-DOS/MS-DOS Viruses ===================== No. of First Names Strains Type Appearance ----- ------- ---- ---------- 1. Brain, Pakistani, Ashar 8 Boot sector 7K F Jan? 86 2. Merritt, Alameda, Yale 8 Boot sector 1K F Apr? 87 3. South African, Friday 13th 2 COM D ? 87 4. Lehigh 2 COMMAND.COM RO 0 Nov 87 5. Vienna, Austrian, Dos-62, Unesco 3 COM D 648 Dec? 87 6. Israeli, Friday-13, Jerusalem 12 COM/EXE R 1813/1808 Dec 87 7. April-1-Com, Suriv-1 1 COM R 897 Jan 88 8. April-1-Exe, Suriv-2 1 EXE R 1488 Jan 88 9. Ping-Pong, Bouncing-Ball, Italian 3 Boot sector 2K Mar 88 10. Marijuana, Stoned, New Zealand, 2 Boot sector 1K; Early 88 Australian partition record on hard disk 11. Nichols 1 Boot sector Apr 88 12. Missouri 1 Boot sector May 88 (89?) 13. Agiplan 1 COM R 1536 Jul 88 14. Cascade, Autumn, Blackjack 6 COM R 1701/1704 Sep 88 (87?) 15. Oropax, Music 1 COM RD 2756 to 2806 Feb 89 16. DenZuk, Venezuelan, Search 6 Boot sector 7K F Early 89? 17. Dbase 1 COM/EXE R Mar? 89 18. DataCrime 2 COM D 1168/1280 Mar 89 19. 405 1 COM DO 405 Apr? 89 20. Screen 1 COM R May? 89 21. FuManchu 1 COM/EXE R 2086/2080 May? 89 22. Ohio 1 Boot sector May 89 23. Icelandic, Saratoga 3 EXE R 656/642/632 Jun? 89 24. Typo 1 Boot sector 2K Jun 89 25. Traceback 1 COM/EXE RD 3066 Jun 89 26. Disk Killer 1 Boot sector Jun? 89 27. Swap 1 Boot sector 2K Jul 89 28. DataCrime II 1 COM/EXE D 1514 Jul 89 29. Vacsina 1 COM/EXE R 1206 Aug 89 30. Mix1 1 EXE R 1618 Aug 89 31. Syslock, 3555 1 COM D 3555 Sep 89 32. Dark Avenger 1 COM/EXE 1800 Sep 89 -- Total no. of strains 77 Summary by type: Boot = 11, COM = 10, EXE = 3, COM/EXE = 7, COMMAND.COM = 1. Among file viruses, Resident = 12, Direct = 6, Resident-Direct = 2. Notes: 1. In the "Type" column, "COM" or "EXE" indicates the type of files infected. "R" stands for "resident", meaning that when an infected program is run the virus makes itself RAM-resident (hooking one or more interrupts); usually such a virus infects subsequently executed programs of the appropriate type, e.g. COM files. "D" stands for "direct", meaning that it searches the disk for an uninfected file and infects it; normally such a virus does not stay resident. (However, it is possible for a virus to be both resident and direct in this sense.) "O" indicates that the virus overwrites the beginning of the file instead of appending or prepending itself to it. The number(s) after the "R" or "D" indicate the number of bytes by which the virus extends files which it infects (however, in the case of EXE files, the total size of the file after infection will get rounded up to the next multiple of 16 if it is not already such a multiple). The number after the "O" is the number of bytes overwritten. In the case of a boot-sector virus, the number of the form "nK" indicates the amount of RAM which the virus occupies. "F" means that the virus infects only diskettes. 2. I include only those viruses which have spread publicly, as opposed to localized test viruses (of which there may be hundreds). (The "Pentagon virus" is deliberately excluded since as far as I know it has not spread publicly; in fact, in the form it was received in the UK, it cannot spread at all.) 3. By definition of "virus", this list does not include non-replica- ting software. 4. Questionable cases: (a) I suspect that the "Lotus 123 virus" and the "Cookie virus" repor- ted recently in VIRUS-L may not be true viruses, and I have therefore decided not to include them, at least for the time being. (b) Although I have included the Dbase and Screen viruses reported by Ross Greenberg, no one else currently on VIRUS-L seems to have encoun- tered them. Jim Goodwin claimed that Dbase does not replicate and hence is not a virus, though it's possible that Jim and Ross were talking about two different things. (c) In May 88 I read about a "retro-virus" which infects 3 specific programs and is capable of reinfecting files after apparently being eradicated. Does anyone have any further info on this virus? (d) I have heard of spreadsheet viruses which occasionally change a value by a small amount, but I have not included them in the table. Further info would be appreciated. We frequently find new viruses which have evidently been created by using an existing virus as a starting point and then modifying it. When should the new creature be considered a new virus and when should it be considered as merely a new strain of the same virus? The cri- terion I have tried to follow (though I probably haven't been entirely consistent) is as follows: If the "damage" part of the virus has been qualitatively altered, or if a virus has been altered to infect additional files (e.g. EXE files where the original infected only COM files), then I classify it as a separate virus. (E.g. although FuManchu, Typo, DataCrime-2, and Mix1 are based on Israeli-Friday13, Ping-Pong, DataCrime-1 and Icelandic-1, resp., I consider these as separate viruses.) If code has been altered, but only by something minor, such as changing a target date or the number of infections required to trigger the damage, or if the alteration seems to be merely an attempt on the author's part to *improve* the code of an existing virus without adding new features, then I regard it as a different strain of the same virus. If the only difference is that only strings (e.g. messages or volume labels) have been modified, then I do not consider it as even a sepa- rate strain. Corrections and additions to this list are welcome. (I'm particu- larly curious about those questionable dates.) Please send your cor- rections directly to me; I'll post an updated version of this table from time to time. I have received suggestions to include additional info in the table, such as the symptoms and damage caused by each virus, what types of disks it infects, etc. While I agree that such information would be very useful, it is beyond the intended scope of this table, both be- cause of the difficulty of describing this information in such a short space and because the answers often depend on the particular strain of the virus. This would make the table much more complicated than it was intended to be. Those interested in further information on the viruses listed here will eventually find it in various catalogs under preparation, e.g. one by David Ferbrache and another by the Virus Test Center at the Univ. of Hamburg (these include non-PC viruses as well). Acknowledgments: I have drawn on information provided by many people. Postings in VIRUS-L are too numerous to mention individual names, but among those who have corresponded with me personally, I would like to thank Dave Ferbrache, Dr. Alan Solomon, Joe Hirst, Prof. Klaus Brunnstein, Fridrik Skulason, John McAfee, Bernd Fix, Otto Stolz, and David Chess. Y. Radai Hebrew Univ. of Jerusalem ------------------------------ Date: Mon, 02 Oct 89 11:08:00 -0600 From: Keith Petersen Subject: VGA2CGA.ARC (or .ZIP) infected with virus (PC) A BBS operator in the Detroit area received an MSDOS program infected with a virus. The file, VGA2CGA.ARC (or .ZIP) - a program which claims it can display VGA graphics on a CGA display, has not been distributed in Detroit and no systems were affected as far as we know. The date/time stamps of the member files in this archive are April 1, 1989 (April fools day). The BBS in California where this file was obtained has been notified to remove the file. Please let me stress that SIMTEL20 does NOT have this program in its archives. I am just acting as a go-between to pass the warning to this newsgroup. [Ed. See followup, on "AIDS" virus, from Alan Roberts in this digest.] - --Keith Petersen Maintainer of SIMTEL20's CP/M, MSDOS, and MISC archives Internet: w8sdz@WSMR-SIMTEL20.Army.Mil [26.2.0.74] Uucp: {ames,decwrl,harvard,rutgers,ucbvax,uunet}!wsmr-simtel20.army.mil!w8sdz ------------------------------ Date: 02 Oct 89 21:32:49 +0000 From: jwright@atanasoff.cs.iastate.edu (Jim Wright) Subject: Re: Future AV software (PC) In article <0014.8910021145.AA27888@ge.sei.cmu.edu> carroll1!tkopp@uunet.UU.NET (Tom Kopp) writes: | A version/variant of ViruScan would run, searching not for | viral-identifying code, but rather for the interrupt calls that write | to a disk (a la Flu_Shot techniques). When it finds one, it looks in | a table to see if that code is allowed. There is a program to do this already. CHK4BOMB will scan a program and report on anything "suspicious" it finds. This was originally meant to find Trojan Horses, but could work against some viruses as well if used in conjunction with other programs. One thing it cannot find is code which is self-modifying, thus hiding the actual low-level access to the disk controller. - -- Jim Wright jwright@atanasoff.cs.iastate.edu ------------------------------ Date: Mon, 02 Oct 89 18:18:56 -0500 From: James Ford Subject: Re: Posting to VALERT-L re: M-1704 (PC) I recently posted a question on VALERT-L about the file M-1704.EXE. SCAN V36 stated that it was infected. I now know, from McAfee and others, that the 1704 virus is encrypted. Since it is, M-1704 must have a specific hex search string in it....one that will indeed cause SCAN to flag it. This is *normal* (thats as technical as I can get....I don't know more, and what I just said is probably techincally wrong). I hope that my posting of the VALERT-L message does not reflect negatively on the Wellspring BBS. The Wellspring BBS is a top-notch BBS, and its anti-viral file collection is among the best in the country. If I gave you a wrong impression of Wellspring, I apologize. I would post this statement about the Wellspring BBS on VALERT-L, but have been informed that VALERT-L is not suppost to be carrying such postings. JF Acknowledge-To: ------------------------------ Date: Mon, 02 Oct 89 19:46:00 -0500 From: Subject: nVIR B (Mac) I recently came across the nVIR B virus on a cluster of Macs. I removed it using Disinfecant 1.5 and appears to be gone. What problems does nVIR B cause? Does it delete files, do annoying things, or simply spread? Being a semi-public cluster, how much of a concern is its presence? ------------------------------ Date: 03 Oct 89 02:23:01 +0000 From: bnr-di!borynec@watmath.waterloo.edu (James Borynec) Subject: Re: Viruses in Commercial Software In article <0008.8909281133.AA14331@ge.sei.cmu.edu>, TMPLee@DOCKMASTER.ARPA wri tes: > In commenting on viruses being distributed (accidentally, of course) > through commercial software someone recently mentioned that someone > near him had been hit by a virus that was in a shrink-wrapped copy of > WordPerfect. I'm skeptical... It happened. A co-worker bought a copy of WordPerfect for his Amiga. When it came to him, it was infected. Those are the facts as he told them to me. If anyone wants more details I am willing to supply them. It probably won't do any good because the problem has been fixed. If anyone is collecting historical information and wants more details send E-mail. (BTW. to the person who sent me E-mail on this topic, did my reply get through to you?) The story behind this goes something like: WP sold the distribution and support rights for the Amiga version of WP for Canada to a company in Ontario. That company had some problems. That company no longer has the redistribution rights. I personally have been hit TWICE by viruses in commercial software. From different vendors. Once when I was examining a popular speech synthesis package for my Mac, and once when we got our TI micro-explorer. Just the thing, factory loaded viruses. To summarize: It happens. Treat ALL software entering your system with caution. James Borynec - -- UUCP : utzoo!bnr-vpa!bnr-di!borynec James Borynec, Bell Northern Research Bitnet: borynec@bnr.CA Box 3511, Stn C, Ottawa, Ontario K1Y 4H7 ------------------------------ Date: Mon, 02 Oct 89 21:45:03 -0700 From: portal!cup.portal.com!Alan_J_Roberts@SUN.COM Subject: New PC Virus (AIDS Virus) A new PC virus was submitted to the CVIA from Keith Peterson (who maintains the SIMTEL20 MSDOS archives). This virus replicates in COM files and has the unusual capability of infecting generic COM files internally - without changing the real size of the file (unlike the zero-bug virus which maintains an "apparent" constant infected file size). Small COM files are infected externally, and the files sizes, for all files under 10K, changes to 13952 bytes - another unusual characteristic. The virus displays a full screen graphic with the the word "AIDS" occupying the bottom half of the screen. The top half contains a long rambling message from the author informing the user of how stupid he has been for using public domain software. SCANV40 has been updated to identify the virus. It is not yet known how destructive the virus may be (all tests have been done with a disabled hard disk). More info forthcoming. ViruScan identifies the virus as the AIDS Virus. Thanks to Keith Peterson for his quick identification of the virus and for his timely response. Alan ------------------------------ End of VIRUS-L Digest ********************* 4-Oct-89 13:40:53-GMT,18229;000000000001 Received: from RUTVM1.RUTGERS.EDU by topaz.rutgers.edu (5.59/SMI4.0/RU1.1/3.04) id AA18649; Wed, 4 Oct 89 09:39:27 EDT Message-Id: <8910041339.AA18649@topaz.rutgers.edu> Received: from RUTVM1.RUTGERS.EDU by RutVM1.Rutgers.Edu (IBM VM SMTP R1.2.1MX) with BSMTP id 9842; Wed, 04 Oct 89 08:50:44 EDT Received: from RUTVM1.LISTSERV by RUTVM1.RUTGERS.EDU (Mailer R2.04RU) with BSMTP id 9840; Wed, 04 Oct 89 08:44:37 EDT Date: Wed, 4 Oct 89 07:15:17 EDT Reply-To: VIRUS-L@ibm1.cc.lehigh.edu Sender: Virus Discussion List From: "The Moderator Kenneth R. van Wyk" Subject: VIRUS-L Digest V2 #211 Comments: To: VIRUS-L@ibm1.cc.lehigh.edu To: Multiple recipients of list VIRUS-L VIRUS-L Digest Wednesday, 4 Oct 1989 Volume 2 : Issue 211 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: New virus? - further report (Mac) Lost mail in U.K. Tiger Teams Re: Followup on new virus (Mac) Columbus Day Virus in the Military Virus protection (PC) NIST Special Publication Re: viruses in Commercial Software Correction to previous posting (Mac) new IBMPC anti-virals UNIX virus proof?! (UNIX) Jerusalem Virus -B (PC) --------------------------------------------- Date: 03 Oct 89 14:49:03 +0000 From: jap2_ss@uhura.cc.rochester.edu (Joseph Poutre) Subject: New virus? - further report (Mac) Here is a further report on the possible virus at the U of R. The student consultants at the University computing center made copies of programs they believed infected and sent them to our computer center. I had an infected copy of Macwrite 5.01 for a while., where I discovered the added STR and the changed ICN. I have had reports of Macwrite II being attacked, but the info I have is inconplete. I am still trying to get another infected program, but I am never around when an infected disk is found. When I get one those that requested a copy will be sent one via email, if it works. The infected System on the consultants' hard drive is 6.0.2, and the only symptom it has shown so far is the "Last Modified" date and time change at irregular intervals, including this morning. I was able to induce a change by repeatedly doing a Get Info on the system. The virus probably found its way onto the disk when a consultant put recovered files from a disk showing what may be sysmptoms of the virus onto the hard drive. Vaccine is installed in teh System folder, and did nothing. The system also has NVIR immunity. The applications known to be attacked, so far, are Macwrite 5.01, Macwrite II, the System and its associated files. All of them, even the clipboard. I just watched to Last Modified date change on Laserwriter change during a copy. (Needless to say the consultants are working on replacing and File Locking everything. This appears to protect against the virus.) I will obtain copies of the infected stuff and try to do some comparisons using Resedit. To repeat, Disinfectant 1.2 has no effect, and Vaccine does not protect against it, at least from infecting within a disk. I plan to spend today working with infected and non-infected programs, and report my findings, and those of the others working on tis problem. Joseph Poutre (The Mad Mathematician) jap2_ss@uhura.cc.rochester.edu Understand the power of a single action. (R.E.M.) ------------------------------ Date: Mon, 02 Oct 89 09:40:10 -0000 From: "David.J.Ferbrache" Subject: Lost mail in U.K. Due to disruption of the mail gateway at Heriot-Watt University mail during the month of September has been intermittent. Anyone who has sent mail to me and not received a reply, please accept my apologies and resend the letter. The info-server facility is currently clearing a backlog of requests and should return to normal service shortly. Many thanks - ------------------------------------------------------------------------------ Dave Ferbrache Internet Dept of computer science Janet Heriot-Watt University UUCP ..!mcvax!hwcs!davidf 79 Grassmarket Telephone +44 31-225-6465 ext 553 Edinburgh, United Kingdom Facsimile +44 31-220-4277 EH1 2HJ BIX/CIX dferbrache - ------------------------------------------------------------------------------ ------------------------------ Date: 03 Oct 89 14:03:00 +0700 From: "Okay S J" Subject: Tiger Teams In VIRUS-L V2NO208 "Thomas B. Collins, Jr." writes: >Say I get my new system, put all the software on >it, and run a few virus scanners that turn up nothing. I then run all >applications from my hard drive, and don't use any floppy disks. It >wouldn't make sense for me to check my hard drive every day for viruses, >because they don't just pop up from nowhere. You're discounting the fact that your machine could be on a network. Having an infected machine on a network where one transfers files between machines can be just as bad as sticking a floppy in the machine. One shot does not cure all >If I did add software to my system, I would check it for viruses before >adding it. I think it would make more sense for the Tiger Teams to come >in in the middle of the day, ask you to please save your work, and then >run a virus checker on your system. It would cause too much of a loss of productivity and interruption of the work routine. Night is better if you're going to do it. Plus the public embarrasment of having ones machine checked. Seriously, its kind of like any test for drugs or AIDS or anything like that. Its not so much as to whether you are infected, but just the idea that it was done. After all, why have a test done if there isn't some suspicion...This at least would be the view of most people around those who had their machines tested. 'Did you hear George got busted by the Tiger Team last week?---They didn't find anything, but you never know....' >If anything is found, you are "cited" as letting a virus into your system. >If you're clean, you go back to work, and the Tiger Team moves on. What exactly does 'cited' mean? Disciplined?, public marked as a electronic leper in the company? fired? --Now that we've established how they would operate, what should be the penalties for those 'caught'? Stephen Okay Technical Aide, The MITRE Corporation x6737 OKAY@TAFS.MITRE.ORG/m20836@mwvm.mitre.org 'Geez...I actually have to use a disclaimer now, I must be getting important!' Disclaimer:Its mine, mine, mine, mine, mine !!!!!!!!!!!!!! ------------------------------ Date: 03 Oct 89 16:14:59 +0000 From: eplrx7!milbouma@uunet.UU.NET (milbouma) Subject: Re: Followup on new virus (Mac) >No anti-virus program has been able to find it, including Interferon, >Virus Rx, Anti-pan, and Disinfectant 1.2. If this is recognized by anyone, >please email me ASAP at the address below with devirusing help. I tried to e-mail but the message bounced. I do not recognize the virus by your description, but if it is new then no one will including the antiviral apps that you mention. I can recommend Symantec's new antiviral package, SAM, which will flag any abnormal writes from an application (like Vaccine if you're familiar with it, but better than Vaccine). SAM will at least protect your machines from getting infected and also has a Virus scanner program that scans for known viruses and can also repair irreplaceable apps that are infected. Part of the protection init also will ask you if you want to scan a floppy for known viruses whenever you insert one. I also recommend that you contact Symantec and give them a copy of your virus so they can update their Virus scanner program. Symantec can be contacted at (408) 253-9600, (800) 441-7234. Please keep the net posted on further developments with this virus. I would especially be interested to know if the SAM INIT flags infection attempts by the virus. Thanks (I do not work for Symantec) ------------------------------ Date: Tue, 03 Oct 89 11:10:34 -0600 From: Chris McDonald ASQNC-TWS-RA Subject: Columbus Day Virus in the Military While I did not see the computer chronicles report referenced by a poster in a recent Virus-L edition, I would propose that there really is no accurate way at the present time to gauge any computer viral infection within the military given existing policies and organizational structures. The diversity of organizations has resulted in differing policies as to whether such reporting is or is not mandatory. This "discretionary" rather than "mandatory" reporting ensures in my opinion that viral infections go unreported. Indeed, I am aware of an outbreak of the Israeli B virus strain which infected several PCs at a particular Army activity which I subsequently learned was not reported through its chain-of-command. In all fairness the written policies applicable to that activity do not make reporting mandatory. In so far as the Columbus Day virus is concerned, the Army's Information Systems Command through a variety of sources has tapped the resources of Virus-L to alert its users as to the potential threat. An advisory message on the subject has been distributed utilizing information first seen on Virus-L. Other Army Commands have retransmitted the same information. I would like to propose that the military subscribers to Virus-L perhaps pursue the problem of reporting by answering these questions: 1. Has your site experienced a viral infection? 2. What viruses were present? 3. Was it reported to the next level of command? I am volunteering to compile the results and then post a summary of the responses received to Virus-L. I will of course ensure the confidentiality of the identity of all sites. Responses should be sent to me directly at . If this is unacceptable, then perhaps someone out there in NETLAND has a better idea. Parenthetically, I wonder if Ken might provide a breakdown of who actually subscribes to Virus-L in terms of military, university, and contractor subscribers? This would be important to assess the level of participation. [PS: Congratulations on your marriage!] [Ed. Thanks! It would be extremely difficult to quantify the different VIRUS-L subscribers, particularly since we're now distributing VIRUS-L via the comp.virus Usenet newsgroup. I can tell you, however, that the actual mailing list contains just shy of 1300 subscribers, over 200 of which are redistribution points. These sites represent a solid cross-section of educational, commercial, military, and government sites in several countries. Most (perhaps 70%) of the sites are educational, with approximately equal numbers of com, mil, and gov sites. Let me stress that these are not accurate numbers for any sort of statistical analysis.] ------------------------------ Date: Tue, 03 Oct 89 14:01:11 -0600 From: Brian Piersel Subject: Virus protection (PC) I'm a new owner of an IBM AT compatible computer, and so I am not very familiar with the various anti-virus programs. Could someone explain to me how these work, and/or recommend one to get? Respond directly to me, if possible. Thanks in advance... ------------------------------ Brian Piersel BITNET: S1CH@SDSUMUS ICBM: 96.50W 44.20N INTERNET: S1CH%SDSUMUS.BITNET@VM1.NoDak.EDU (The Internet address doesn't always work) "Live long and prosper." ------------------------------ Date: Tue, 03 Oct 89 14:16:52 -0600 From: Chris McDonald ASQNC-TWS-RA Subject: NIST Special Publication I would like to add some additional thoughts to those who have already commented on the NIST "Computer Viruses and Related Threats: A Management Guide." 1. I believe there is a signifiant error on page 2-6. The report in discussing the INTERNET Worm states: "It was unclear what the network worm's objective was, as it did not destroy information, steal passwords, or plant viruses or Trojan horses." I think there is substantial evidence to prove that the Worm in causing denial of service attacks did indeed destroy information. Donn Seeley has made the point that the author of the Worm program specifically "deleted" an audit file so as to hide his location. There are also numberous reports that the program successfully "captured" passwords on other hosts to which the Worm author was not entitled. The NIST authors reference Dr. Spafford's report on page A-1 which addresses the "stealing" of passwords. Both Seeley's and Spafford's analysis of the incident can be found, along with other related papers, in the Jun 89 edition of the "Communications of the ACM." This ACM edition is probably the best reference on the entire incident available in the public domain. I think it should have been included in the NIST reference list. 2. I differ from several commentators who suggest that the document is "prejudiced" against the use of public domain and shareware products. I think on pages 3-3 and 5-3 the document stresses only that organizations should develop a clear policy on the acquisition and on the use of such software. 3. I am struck by the lack of any reference to Virus-L, RISKS Forum and other INTERNET services which have for years provided we users the best available, open source information on the subject of computer viruses. There is also little in the way of reference to the work of professional associations such as ACM, IEEE, the Computer Security Institute, and the Information Systems Security Association in addressing the computer virus phenomenon. Surely "technical managers", who are the audience for this publication, could use such resources to implement the virus prevention suggestions in the NIST publication. Chris Mc Donald White Sands Missile Range ------------------------------ Date: Tue, 03 Oct 89 12:11:00 -0400 From: Subject: Re: viruses in Commercial Software We too have been hit, though not recently. Last semester, a freehand disk from Aldus had scores on it right out of the box. These 'professionals' should pay more attention to what they are doing. Alex Z... . . . ------------------------------ Date: Tue, 03 Oct 89 20:31:00 -0500 From: Subject: Correction to previous posting (Mac) Sorry, folks, I spread a little misinformation without realizsing it. I have Disinfectant 1.2, not 1.5. (BTW- does anyone know where the latest versions can be obtained as they become available?) I had gotten swamped with requests for 1.5. Sorry! ------------------------------ Date: Tue, 03 Oct 89 21:37:54 -0500 From: jwright@atanasoff.cs.iastate.edu (Jim Wright) Subject: new IBMPC anti-virals New additions to the archives. For the most recent site listings, see vol 2 num 209 of VIRUS-L (or better yet, save those monthly site lists!). All the files in this batch are shareware. bootchk.exe Program to verify boot sector of disk. Performs comparison with secure copy of boot sector. To be used in autoexec.bat. Sent to me by author. Version 1.00 (first release). Self-extracting zip. m-1704.arc Update to previous file of same name. Only change is in docs to warn of possible false alert issued by viruscan. Direct from author's BBS. netscan.arc Network compatible program to scan disks for known viruses. Version 0.4v33, update to previous releases. Direct from author's BBS. scanrs39.arc Resident program to scan executables for viruses before loading. Version 0.9v39, update to previous releases. Note minor change in spelling of archive name. Direct from author's BBS. scanv40.arc Program to scan disk and report any viruses found. Version 0.7v40, update to previous releases. Direct from author's BBS. shez48.exe Shell program for manipulating archives which, with this new release, is compatible with viruscan. Version 4.8. From HomeBase where it was placed by author. Self-extracting LZH archive. [ I was unable to get the viruscan aspect to work as advertised ] [ but I only put forth a minimal effort. -- jrw ] BOOTCHK.EXE Verifies boot sector against secure copy, v1.00 M-1704.ARC Repairs and removes infections of 1704A and 1704B viruses NETSCAN.ARC Network compatible program to scan for viruses, 0.4v33 SCANRS39.ARC Resident program to check for viruses, 0.9v39 SCANV40.ARC Scans disks and reports viruses found, 0.7v40 SHEZ48.EXE Shell for archive manipulation w/ virus checking, v4.8 Jim ------------------------------ Date: Tue, 03 Oct 00 19:89:58 +0000 From: ficc!peter@uunet.uu.net Subject: UNIX virus proof?! (UNIX) I wouldn't say UNIX is virus-proof (I posted a hoax article about a UNIX virus over a year ago, just before the Internet Worm incident), but it's sure a hell of a lot more virus-resistant than DOS. ------------------------------ Date: 04 Oct 89 07:14:43 +0000 From: consp06@bingvaxu.cc.binghamton.edu Subject: Jerusalem Virus -B (PC) SUNY Binghamton has been hit by the Jerusalem Virus. It seems to be spreading pretty well. We are looking for: 1) Advice. 2) SCAN38, SCANRES, etc... any of those. 3) UNVIRUS We have SCAN28, and we want to know where to get everything else we need to arm ourselves against this nasty villain. Thank you very much. -Robert Konigsberg ------------------------------ End of VIRUS-L Digest ********************* 4-Oct-89 21:51:57-GMT,21479;000000000001 Received: from RUTVM1.RUTGERS.EDU by topaz.rutgers.edu (5.59/SMI4.0/RU1.1/3.04) id AA12316; Wed, 4 Oct 89 17:50:49 EDT Message-Id: <8910042150.AA12316@topaz.rutgers.edu> Received: from RUTVM1.RUTGERS.EDU by RutVM1.Rutgers.Edu (IBM VM SMTP R1.2.1MX) with BSMTP id 2067; Wed, 04 Oct 89 16:54:47 EDT Received: from RUTVM1 by RUTVM1.RUTGERS.EDU (Mailer R2.04RU) with BSMTP id 2061; Wed, 04 Oct 89 16:07:33 EDT Date: Wed, 4 Oct 89 14:08:22 EDT Reply-To: VIRUS-L@ibm1.cc.lehigh.edu Sender: Virus Discussion List From: "The Moderator Kenneth R. van Wyk" Subject: VIRUS-L Digest V2 #212 Comments: To: VIRUS-L@ibm1.cc.lehigh.edu To: Multiple recipients of list VIRUS-L VIRUS-L Digest Wednesday, 4 Oct 1989 Volume 2 : Issue 212 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: Virus Commentary Re: Virus Commentary The invincible virus (Ghost virus) (Atari ST) Information wanted Re: New virus? (Mac) nVIR B Details (Mac) Submission for comp-virus New Mac Virus - Further Diagnostic Help Where to Get Mac Anti-Virals datacrime II antidote (PC) OGRE virus in Arizona (PC) --------------------------------------------------------------------------- Date: Sun, 24 Sep 89 15:12:00 -0600 From: Frank Starr <55srwlgs@sacemnet.af.mil> Subject: Virus Commentary Sabotaged Program Reactions - An Editorial Review by Frank Starr The continuing threat of virus and Trojan Horse programs - which I prefer to call sabotaged programs, has begun to spark some reaction from the upper levels of the Department of Defense. Concurrent with the discovery of the so-called "Columbus Day Time Bomb", previously known as the Datacrime Virus, has come a series of directives which may serve to eliminate the use of all forms of shareware by D.O.D. personnel on D.O.D. microcomputers. Air Force users first received word of the Columbus virus from a message published by the USAF Office of Special Investigation, republished and mass mailed through MILNET/DDN, the D.O.D. e-mail system. Two suspected sources have been listed - a European extremist group in the spiritual sway of Bader Meinhoff, and a Norwegian group displeased with celebrations honoring Columbus, while ignoring Norse discoveries preceeding those of European explorers. Later communiques identified the virus as the Datacrime variety, capable of trashing the FAT area of a hard drive. From the first message to all others received to date, a prevailing directive has been to cease using all software downloaded from private bulletin boards. Various interpretations have gone so far as to conclude that only vendor supplied software should be used, to the absolute exclusion of everything else, whether shareware available for purchase after an initial test period, or freeware for which no fee or donation is ever asked. All of this confusion promises to cause a lot of D.O.D. micro users to cut themselves off from anything except commercial software, purchased through government contracting channels. This in spite of the fact that there have even been reports about commercial software occasionally being sabotaged by temporary employees (as reported in an issue of Government Computer news about a year ago. Sorry, specific issue forgotten). There are a number of micro bulletin boards in D.O.D., some of which offer shareware software for evaluation to potential customers. Some of the SYSOPs of these systems forsee a call to close down operations, based on reactions to sabotaged software threats, and rough drafts of official regulations to control software on D.O.D. micros (see the September/October C2MUG bulletin, page 5). Although there are some advisories for users to back up all software on D.O.D. micros, more attention seems to be going towards the elimination of all non-contract software on D.O.D. micros. Since sabotaged programs are more often reported in connection with softwaree downloaded from public RBBS systems, this game plan can be understood, if not readily supported. However, with micro user education still a lower priority object in many areas, and software backup not a widespread practice, it seems that, especially with funding cuts a now and future reality, more attention would better be given to how to defend against sabotaged programs, and perhaps the avoidance of all forms of shareware could be reevaluated. Frank Starr ------------------------------ Date: Sun, 24 Sep 89 18:03:00 -0600 From: "Frank J. Wancho" Subject: Re: Virus Commentary Frank, I just read and reread your editorial. I fear that possibly many people will misread it, overlooking certain key words and phrases, such as "may" in "may serve to eliminate," "various interpretations," "foresee," "seems" in "more attention seems to be," etc. The actual point of your editorial, with which I agree, is in your last sentence, which should have been a paragraph by itself (starting with the word, "However," and broken into several sentences: Micro user education is still a low priority activity in many areas, and software backup not a widespread practice. With funding cuts a now and future reality, more attention should be given to defending against sabotaged programs. Then, perhaps, the trend toward avoiding all forms of shareware could be reevaluated. - --Frank ------------------------------ Date: 03 Oct 89 14:17:35 +0000 From: erwinh@solist.htsa.aha.nl (Erwin d'Hont) Subject: The invincible virus (Ghost virus) (Atari ST) First I would like to make my excuse for not giving enough information in my last (and first in my career) message to usenet. I asked some information about the Ghost Virus on the Atari ST, well I forgot to mention the computersystem and the kind of information I requested Well here goes all or nothing : Since a few months I'm being bugged by a virus that inverses the mousepointer. So after I figured that it could be a virus, I pulled out my trusty Viruskiller (VDU - Virus Destruction Utility V1.4) and became aware of this "Ghost Virus". After wiping the virus from all my disks I thought I would be save, but none could be more true. This virus returned every time. Maybe it is a link-virus that somehow manages to copy itself into the bootsector so that it can begin it's faul work again. But the VDU doesn't reconize any link-virus on any of my disks, so my question to all of you is : Is there some way to get rid of this virus without formatting all my disks ?? Erwin WARNING : Never crunch a file or disk without checking it !!!!!!!!!!!!!! ------------------------------ Date: 04 Oct 89 02:50:40 +0000 From: cvl!cvl!umabco!bgoldfar@uunet.UU.NET (Bruce Goldfarb) Subject: Information wanted I am looking for addresses (phone numbers ideal) for the Computer Virus Industry Association and the National Bulletin Board Society. Any and all help is deeply appreciated. Bruce Goldfarb umabco!bgoldfar@cvl.umd.edu (or) cvl!umabco!bgoldfar ------------------------------ Date: Mon, 02 Oct 89 16:05:35 -0400 From: Joe McMahon Subject: Re: New virus? (Mac) >Subject: New virus? (Mac) I'm afraid so... >We here at the University of Rochester may have discovered a new >virus, or a variation on a theme. What it does is infect Macwrite ... (sundry details omitted) > ... Disinfectant 1.1 doesn't work, so please email me the >latest version of disinfectant to try... I'm afraid it won't help. You should send some mail to John Norstad *immediately* and let him know about it. He may request a copy of your infected files. His net address is in the Disinfectant documentation. >The virus definitely attacks Macwrite. It adds a str ID 801 and >modifies the icon to say Macwite instead of the standard application >icon. The application increases in size by 104 bytes, 56 in the >string. they are added in sector 014F, according to Fedit Plus 1.0. Actually, you should check it out with ResEdit and see what resource they get added to. Ditto for the System; look for INIT resources. There are a few that are supposed to be there, but the virus may add new ones. (more details omitted) This sounds very much like a new virus. Have you Vaccine or GateKeeper installed? Either should keep infections from spreading, unless the virus is doing its own disk I/O at the driver level (very dangerous and could lead to screwed-up disks). Things to try: - Write-protect a known-clean version of MacWrite and try running it on the infected system. - Change another application's signature (type/creator) to MacWrite's and see if the virus tries to infect it. - Name MacWrite something else and see if it is attacked. - Look at the system healp with Macsbug and and try to identify all of the resources loaded into it. This may help in tracking down the infection mechanism. I'd appreciate hearing further details; post them to me personally if you'd like. --- Joe M. ------------------------------ Date: Tue, 03 Oct 89 10:16:41 -0400 From: Joe McMahon Subject: nVIR B Details (Mac) asks: >I recently came across the nVIR B virus on a cluster of Macs. I removed >it using Disinfecant 1.5 and appears to be gone. > >What problems does nVIR B cause? Does it delete files, do annoying things, >or simply spread? Being a semi-public cluster, how much of a concern >is its presence? It does annoying things (beeps or says "Don't Panic"). Since it also grabs space in the system heap AND installs a VBL task, it can cause memory problems and timing problems, causing printing failures and crashes. Its presence is always a concern. Think of it as a public health problem. Your cluster, if left infected, would be a reservoir of infection and a potential source of spread, no matter how much time other clusters spent cleaning themselves up. Get Vaccine or GateKeeper installed on those Macs. Now. You must have either not had them installed, or someone has been turning them off. If you suspect that someone is deliberately infecting the cluster, you might want to set up a virus-scanning station that all disks must be passed through before they are used on your cluster. The Disinfectant documentation will tell you how to do this. --- Joe M. ------------------------------ Date: 04 Oct 89 13:08:50 +0000 From: kkk@ohdake.uta.fi (Kimmo Kauranen) Subject: Submission for comp-virus Where could I get a copy of "Proceedings..." Hey! There is been in some articles a mention about the book "Stephen J. Ross (ed.) Computer Viruses - Proceedings of an Invitational Symposium, Oct 10-11,1988. New York: Deloitte, Haskings & Sells, 1989." I 'd like to get it, but where could I order it? Thanks beforehand Kimmo Kauranen ------------------------------ Date: Wed, 04 Oct 89 09:51:17 -0400 From: Joe McMahon Subject: New Mac Virus - Further Diagnostic Help Try using GateKeeper and shutting down ALL accesses to files. See if that will show you what's being copied into the files. It should be in the GateKeeper Log. --- Joe M. ------------------------------ Date: Wed, 04 Oct 89 09:46:05 -0400 From: Joe McMahon Subject: Where to Get Mac Anti-Virals CTDONATH@SUNRISE.BITNET asks: ...where can we get the most recent versions {of anti-viral software} ? On BITNet, the LISTSERV at our node (SCFVM) has a virus-removal package consisting of Disinfectant, Virus Rx, Vaccine, GateKeeper, and some other files. You can subscribe to this package and receive updates automatically by obtaining a LISTSERV password and AFD ADDing the package. On Internet, sumex-aim.stanford.edu has anti-virals in the /info-mac/virus directory. apple.apple.com in the pub/dts/mac/tools directory has the newset version of Virus Rx. Hope this helps. --- Joe M. ------------------------------ Date: 04 Oct 89 18:14:00 +0700 From: NOAM@SARA.NL Subject: datacrime II antidote (PC) On or after the 12th of October, an undetermined number of computer 'viruses' are scheduled to start erasing the data of their unsuspecting hosts. One virus in particular, known as 'DATACRIME II', is an especially nasty specimen, as it not only spreads very rapidly, but also formats the hard disk of any computer it infests, permanently destroying all of the contents. DATACRIME was first detected in the Netherlands, and the leading computer publication of that country, PERSONAL COMPUTER MAGAZINE, commissioned computer expert Rikki Cate to write an 'antidote' program for its readers. Cate, an American who lives in the Netherlands, is a programmer specialized in this kind of work. Cate's Cure was an overnight sensation. Featured on radio, television and in Holland's leading newspapers, thousands of copies were distributed within the first few days and it has already inspired a number of hastily composed imitations. Even the Dutch police have begun distributing a version of their own. Cate's Cure, however, claims superiority to all of these. It is much faster, it actually removes the virus, it repairs damaged programs, it automatically searches all the directories on the hard disk, and it provides permanent protection against formating of the hard disk or new infections by the virus. None of the other programs released have any of these features. This is believed to have been confirmed in an independent test carried out by the Dutch Railways. In view of the huge demand and the clear anxiety indicated by that, Cate has decided, with the approval of PCM, to make the antidote more widely available at a cost of $10 per disk. Additional information can be obtained from her directly by calling 31-20-981963 in Amsterdam. Fax: 31-20-763706, telex 12969 neabs nl, Fido 2:280/2, electronic mail 31-20-717666, all marked to her attention. [Ed. Any chance of getting a copy of Catee's Cure on this side of The Pond, for electronic distribution?] ------------------------------ Date: Wed, 04 Oct 89 10:18:00 -0700 From: Subject: OGRE virus in Arizona (PC) Original_From: Paul Balyoz A new, extremely nasty virus has been discovered on some IBM PCs in the state of Arizona. This virus, known as OGRE, has been found on some disks in Flagstaff and nearby areas. This is the first recognition of said virus that has come to my attention. This memo gives a description of the virus and possible ways of recognizing and removing it. DESCRIPTION The OGRE virus tries to infect any disks it sees that haven't yet been infected with itself. It counts the number of disks it has infected as it goes along. It does no harm until after it has infected a certain number of disks. After that point it will display a message on the screen at boot time identifying itself as the COMPUTER OGRE dated April 1, and telling you to leave your machine alone as it begins "stomping" blocks on the disk randomly, by writing blocks full of one character all over the disk. This holds true for both floppy disks and hard disks. The damage done in this manner is virtually irrepairable. Once this happens the hard disk usually needs to be reformatted (which effectively erases everything on on disk). If backup copies of the files from that disk were made, it can be restored back onto the reformatted disk, and all is well again (until the next time). If you see this message appear on your screen, ignore the warning and TURN YOUR COMPUTER OFF IMMEDIATELY! The quicker you turn it off, the less damage it will have done. The first blocks it destroys are the boot blocks and file and directory information; files go after that. If stopped in time, the files on the disk may be retrieved using various disk utility programs. TECHNICAL DETAILS The OGRE virus spreads by writing copies of itself onto 3 unused blocks on the disk. It then marks those blocks as being "bad," so that normal disk usage won't ever choose those blocks for storing ordinary data. Thus the virus can stay on the disk without being bothered. The important step is when it modifies the boot blocks of the disk so that next time the disk is booted, the special code on those three blocks is executed, and the virus can try to infect new disks. Thus, every time the disk is booted thereafter, the OGRE code is executed, and can do what it has been programmed to do. Because the OGRE virus operates at such a "low level," none of the existing virus detection/elimination programs currently in existence for the IBM PC will work. Note that OGRE doesn't create or modify any of the files on the disk at the time of infection, nor does it effect the FAT in any way. Thus it is virtually undetectable by present means, until special programs are developed to detect and remove it. RECOGNIZING THE VIRUS If you have a "disk zap" or "sector edit" type of program, you can use that to see if the OGRE virus has infected each of your disks. You'll want to search the disk for the string "OGRE" (those four upper-case ascii characters) or "COMPUTER OGRE" to be sure. You will know by the surrounding text if each occurrance of the string is truly the virus or not. The software package "Norton Utilities" has a program that can do this sort of disk-searching function. The most important place to look are the boot- blocks on the disk. If the string exists in that area, your disk is probably infected. Note: It is possible for normal information on the disk to spell out the string "OGRE" just by chance. As I understand it, that string being found in the boot-blocks nearly guarantees infection. The text before and after the string must be viewed to be sure. There is a date of April 1, and a copy- right notice, as well as the English text that it can display. You will know from the context whether your disk is infected or not. CLEANING AN INFECTED DISK File copying will "clean" an infected disk. Because OGRE doesn't effect any files, per se, a good method for cleaning up an infected disk that hasn't been "stomped on" yet would be to copy all of the files off that disk onto a freshly formatted one. Of course you'll want to be sure that the virus isn't running while you do this, or it will quickly infect the new disk as well! Boot your computer from an original system disk that was distributed with your computer. Make sure it is write-protected before booting. If this disk has never been un-write-protected, then it can't ever have been infected. Then go ahead and format the new disk, and copy your files to it. The infected disk you just copied all the files off of can now be formatted to clean it up, and files copied back onto it again. FUTURE VIRUS DETECTION IDEA Checksum the boot blocks. A program should be written to run a set of checksums on the boot blocks of your disk, and remember the number somewhere. When run thereafter it can recompute the checksum and compare it to the one recorded previously. If the two checksums do not match exactly then the boot blocks have been modified, which is not a normal thing to have happen. The program can then notify the user that, "The boot blocks on this disk have changed; you may have a virus." If this program were written and launched from the AUTOEXEC.BAT file on all bootable disks, then the user would know immediately if they were infected. Of course, the OGRE virus would have already been executed once by then, since the disk was booted before the AUTOEXEC.BAT file was read, so it may have infected another disk; but it won't have gone on the rampage yet. The user would thus have pre-knowledge of the infection, and can combat it before any damage is done. DISCLAIMER I have not personally seen the virus nor any disks damaged by it. SOURCE INFORMATION This new virus was discovered by members of the staff at Computer Solutions here in Flagstaff Arizona. They are working on disassembling the virus and will hopefully come up with a virus removal procedure or program. The current theory is that it originated somewhere in the Phoenix area, but nothing is sure yet. Computer Solutions is trying to contact as many people as they can to warn them about this new problem. You are encouraged to make copies of this memo in any form and distribute them to anyone who might need to know this information. You can contact Computer Solutions at 602-774-1272 during the day. submitted by: *usual disclaimers* --------------------------------------------------------------------- - Bob Wier Northern Arizona University Ouray, Colorado & Flagstaff, Arizona ...arizona!naucse!rrw | BITNET: WIER@NAUVAX | WB5KXH ------------------------------ End of VIRUS-L Digest ********************* 5-Oct-89 11:59:45-GMT,16136;000000000001 Received: from RUTVM1.RUTGERS.EDU by topaz.rutgers.edu (5.59/SMI4.0/RU1.1/3.04) id AA09021; Thu, 5 Oct 89 07:57:50 EDT Message-Id: <8910051157.AA09021@topaz.rutgers.edu> Received: from RUTVM1.RUTGERS.EDU by RutVM1.Rutgers.Edu (IBM VM SMTP R1.2.1MX) with BSMTP id 4202; Thu, 05 Oct 89 07:53:40 EDT Received: from RUTVM1 by RUTVM1.RUTGERS.EDU (Mailer R2.04RU) with BSMTP id 4199; Thu, 05 Oct 89 07:51:15 EDT Date: Thu, 5 Oct 89 07:42:35 EDT Reply-To: VIRUS-L@ibm1.cc.lehigh.edu Sender: Virus Discussion List From: "The Moderator Kenneth R. van Wyk" Subject: VIRUS-L Digest V2 #213 Comments: To: VIRUS-L@ibm1.cc.lehigh.edu To: Multiple recipients of list VIRUS-L VIRUS-L Digest Thursday, 5 Oct 1989 Volume 2 : Issue 213 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: Pointer to Cohens publications Re: Followup on new virus (Mac) Re: Why not change OS? About the DH&S proceeding(s)... Re: OGRE virus in Arizona (PC) Increasing rate of virus appearances Binghamton Jerusalem-B virus - The day after. (PC) M-1704 question (PC) WSMR newspaper article on Anti-Virus program --------------------------------------------------------------------------- Date: Wed, 04 Oct 89 19:18:50 -0500 From: Christoph Fischer Subject: Pointer to Cohens publications Hello I need the exact bibliographic data of Fred Cohen's dissertation and publications in the field of computerviruses. If there exists an downloadable printfile with such material I would be very happy about any hints. Thanks Chris ***************************************************************** * Torsten Boerstler and Christoph Fischer and Rainer Stober * * Micro-BIT Virus Team / University of Karlsruhe / West-Germany * * D-7500 Karlsruhe 1, Zirkel 2, Tel.: (0)721-608-4041 or 2067 * * E-Mail: RY15 at DKAUNI11.BITNET or RY12 at DKAUNI11.BITNET * ***************************************************************** ------------------------------ Date: 04 Oct 89 18:09:20 +0000 From: ut-emx!chrisj@cs.utexas.edu (Chris Johnson) Subject: Re: Followup on new virus (Mac) In article <0004.8910041115.AA07054@ge.sei.cmu.edu> eplrx7!milbouma@uunet.UU.NE T (milbouma) writes: >I can recommend Symantec's new antiviral package, SAM, which will flag >any abnormal writes from an application (like Vaccine if you're >familiar with it, but better than Vaccine). SAM will at least protect >your machines from getting infected and also has a Virus scanner >program that scans for known viruses and can also repair irreplaceable >apps that are infected. Part of the protection init also will ask you >if you want to scan a floppy for known viruses whenever you insert >one. Of course, as an alternative to SAM, you can save yourself a lot of money and go with GateKeeper 1.1.1, which has not only been stopping viruses around the world 6 months longer than SAM (and all the other johnny-come-lately commercial systems), but is completely free. Furthermore, I gather that GateKeeper is significantly more configurable than SAM insofar as it maintains a privilege list which can be easily viewed and edited (I've never used SAM, so I don't speak from first-hand experience on this point, but people assure me that it's a *very* important difference in practice). If you need telephone support, though, SAM is clearly better for you... the closest thing to interactive support available with GateKeeper is email. GateKeeper doesn't provide a virus-scanner, but with Disinfectant available (also for free) it's not much of a problem. One other thing that makes GateKeeper unique in the world of Macintosh anti- virus systems is that it keeps a log file that details exactly what virus related operations have been attempted, when, by whom and against whom. GateKeeper 1.1.1 (as well as Disinfectant) is available from most archive sites, including a local system, ix1.cc.utexas.edu in the microlib/mac/virus directory. Well, happy virus hunting no matter what system you choose, - ----Chris (Johnson) - ----Author of GateKeeper ------------------------------ Date: Wed, 04 Oct 89 17:01:06 -0400 From: Tim Endres Subject: Re: Why not change OS? Better than changing OS to get better virus "resistance", why not encourage the systems designers at Apple and IBM to implement protection in their respective operating systems? An entire document dedicated to stopping virus acitivity at the OS level was mailed to John Sculley at Apple. Yet, to this day, even with an entire new OS release, not one of the suggestions given has been implemented! I am sure that there are many complex issues facing a company such as Apple, with regards to this problem, and changes at the OS level to deal with viruses will, and probably should, be slow. Further, I must give Apple credit for the action they did take when Macintosh viruses first surfaced. In some cases, they sent their own engineers to infected sites for investigation and assistance. They were the first to engage in "Virus Awareness" campaigns. Unfortunately, we have seen no work at the OS level. What users should be doing, is overtly pressuring computer manufacturers to address this need at the OS level, and start buying equipment from vendors who move in that direction. ------------------------------ Date: Wed, 04 Oct 00 19:89:18 +0000 From: utoday!greenber@uunet.UU.NET (Ross M. Greenberg) Subject: About the DH&S proceeding(s)... I wasn't too happy with the end result of what DH&S (Steve Ross works for them) produced. The invitational excluded a number of people (including me, so this might be a biased report). The only person there really familiar with the world of PC and other micro viruses was Pam Kane (Panda Systems & Dr. Panda Utilities - good stuff!). They spent a great deal of time on nomenclature. Something like two days. Very little on practical "how-to's" or anything at all of a technical nature. The conclusion of the report is basically a sales-promo piece on why you should hire DH&S consultants if you have a virus problem or wish to make sure you don;t get one. I consider this mailing list *considerably* more informative, objective, and honest. Note: I ended up attending the symposium, then being asked to leave when I mentioned that it seemed inappropriate to give this little meeting any credibility when only three or four people there, out of the 50 or so who presented, had *ever* seen a virus. To be honest, I was a gate crasher. Ross M. Greenberg Author, FLU_SHOT+ ------------------------------ Date: 04 Oct 89 23:15:47 +0000 From: jwright@atanasoff.cs.iastate.edu (Jim Wright) Subject: Re: OGRE virus in Arizona (PC) In article <0011.8910041808.AA09177@ge.sei.cmu.edu> WIER@NAUVAX.BITNET writes: | Because the OGRE virus operates at such a "low level," none of the | existing virus detection/elimination programs currently in existence | for the IBM PC will work. | | FUTURE VIRUS DETECTION IDEA | | Checksum the boot blocks. The new program BootChek goes one better than this. It will compare the entire boot block with a secured copy. Since it is small, this comparison is fast, and better than a checksum. If a change is detected, the computer is halted. WARNING: This will detect any *change* in the boot block. If you start with an infected system, this won't help. - -- Jim Wright jwright@atanasoff.cs.iastate.edu ------------------------------ Date: Wed, 04 Oct 89 20:39:29 -0400 From: RREINER@YORKVM1.BITNET Subject: Increasing rate of virus appearances It is my impression, judging primarily from reports on VALERT-L, that the rate at which new viruses are appearing has accelerated substantially in recent weeks. There was previously what seemed a stable rate of one new virus every few weeks; this seems now to have become one new virus every few days. Has anyone been keeping more careful records? What is the rate of increase of the rate of increase? Richard J. Reiner BITNET == rreiner@vm1.yorku.ca Internet == grad3077@writer.yorku.ca Compu$erve == 73457,3257 ------------------------------ Date: 05 Oct 89 04:31:42 +0000 From: consp06@bingvaxu.cc.binghamton.edu Subject: Binghamton Jerusalem-B virus - The day after. (PC) Thanks to all of you who responded so quickly to my messages for help. We now have several programs that will arm us in controlling the virus. Any more messages, although appreciated, are unnecessary. It's good to see that people are so eager to help when a crisis occurs. -Robert Konigsberg ------------------------------ Date: Wed, 04 Oct 89 15:07:00 -0400 From: Jim Shanesy Subject: M-1704 question (PC) We (Don Kazem of our Technical Systems group, and myself, a programmer/analyst) have just downloaded M-1704.ARC from the Homebase bulletin board and found upon reading the documentation that SCANV40 is supposed to detect M-1704.EXE as a virus. It does not. We both ran SCANV40 (also obtained from Homebase) on our respective hard disks and SCAN reports them both as clean. Don's machine is a PS/2 Model 70 with ESDI-controlled 120 Meg hard disk, and mine is a PS/2 Model 60 with ESDI-controlled 66 Meg hard drive. We are reluctant to run this program until we verify that it is not indeed infected, since its behavior is different from that described in the documentation. Any comments, Mr. McAfee? [Ed. I believe that the newer ViruScan versions were modified to *not* produce this false alarm; perhaps Mr. McAfee can confirm this.] ********************************************************************** Jim Shanesy JSHANESY@NAS.BITNET Office of Computer and Information Technology National Academy of Sciences 2101 Constitution Ave., NW Washington, DC 20418 (202)-334-3219 ********************************************************************** ------------------------------ Date: Wed, 04 Oct 89 12:58:00 -0600 From: Chris McDonald ASQNC-TWS-RA Subject: WSMR newspaper article on Anti-Virus program THE WSMR ANTI-VIRUS PROGRAM The subject of computer "viruses" has attracted considerable attention in the last three years. The publicity of a Columbus Day virus and the continuing infection rates of several Friday the 13th viruses has pointed out the necessity of ensuring all users are aware of common sense policies and procedures to minimize the threat of viral attacks. This article attempts to describe our virus defense program at the Range. We at White Sands have a unique history in viral research. In the summer of 1984 we at White Sands Missile Range sponsored a computer virus "experiment" by a University of Southern California (USC) undergraduate, Mr. Fred Cohen. Fred went on to obtain his PhD and has written and lectured extensively on the computer virus phenomenon. So we have had some direct experience in the area at a rather early stage. The definition of a "virus" from Dr. Cohen's original research work is short, but extremely important to understand some recent viral attacks. He defined a "virus" as "a computer program that can infect other programs by modifying them to include a possible evolved copy of itself." With the infection property a virus can spread throughout a computer system or network using the authorizations of every user who might use it to infect their own programs. Viruses can spread on personal computers as well as on mainframes. For a variety of reasons we have seen the majority of viruses infecting personal computers. An Israeli researcher has published a catalog of 77 identified MS-DOS viruses, including their variations, as of 2 Oct 89. Other researchers have identified at least 10 Macintosh viruses, including variations, as of 3 Oct 89. "Variations" occur as individuals receive a copy of an original virus and then make some change to it for the purpose of creating a "new" virus. If a "computer virus" is similar to a "biological virus," then could one apply the defenses or at least the methodology used to counter infectious human diseases to the issue of automation security? On the assumption that the comparison holds, then prevention, treatment and education would seem logical control measures. We can limit our exposure to computer viruses by controlling and by monitoring the source of our software. We can "buy" from reputable sources. We can apply the two-person rule to the development and to the review of software which we develop in-house. If we must use public domain and shareware software, then we have an obligation to observe the policies and procedures which our particular organization has for the acquisition, control and testing of such software. Users should also be aware that certain tenant activities at WSMR prohibit the use of public domain software. We have at our disposal both commercial and shareware software products to detect known computer viruses. We have advertised over the Workplace Automation System (WAS) electronic bulletin board the availability of VIRUSCAN which specifically detects several Friday the 13th and Columbus Day viruses identified as the DatacrimeI and DatacrimeII viruses. Users can contact either Bob Rothenbuhler, the installation systems security manager, at 678-4236, or Chris Mc Donald, an ISC information systems management specialist, at 678-4176 for assistance. There are a variety of "disinfectant" programs for the MS-DOS and for the Macintosh worlds which we maintain in the event of a viral outbreak. We also have access to the resources of the National Computer Security Center (NCSC), the Computer Virus Industry Association (CVIA), and the Computer Emergency Response Center (CERT) in the event of viral attacks. While it is impossible to stockpile all possible "treatment" remedies, we have at least a good foundation. Finally, an article such as this serves to "educate" you, the user community, as to the threats and to some of the defenses applicable to the computer virus problem. We have available a briefing on computer viruses entitled "Everything the New England Journal of Medicine will never tell you!" which discusses this subject in some detail. The Information Systems Command has also initiated an eight hour training class, "Protection of Automation Resources", which will address the whole subject of automation security, to include viruses. Both Bob and Chris are always available to answer specific questions and to assist users within their respective fields of interest. While we cannot eliminate computer viruses, we can maintain a program of prevention, detection and education to minimize the possibly negative impact on our computing environment. Using good common sense computing practices can reduce the likelihood of contracting and spreading any virus. - Backup your files periodically - Control access to your PC or terminal and limit use to those people whom you know and trust - Know what software should be on your system and its characteristics - Use only software obtained from reputable and reliable sources - Test public domain, shareware, and freeware software before you use it for production work - If you suspect your PC contains a virus, STOP using it and get assistance ------------------------------ End of VIRUS-L Digest ********************* 5-Oct-89 20:32:09-GMT,8021;000000000001 Received: from RUTVM1.RUTGERS.EDU by topaz.rutgers.edu (5.59/SMI4.0/RU1.1/3.04) id AA00453; Thu, 5 Oct 89 16:30:00 EDT Message-Id: <8910052030.AA00453@topaz.rutgers.edu> Received: from RUTVM1.RUTGERS.EDU by RutVM1.Rutgers.Edu (IBM VM SMTP R1.2.1MX) with BSMTP id 6351; Thu, 05 Oct 89 16:23:01 EDT Received: from RUTVM1 by RUTVM1.RUTGERS.EDU (Mailer R2.04RU) with BSMTP id 6348; Thu, 05 Oct 89 16:18:58 EDT Date: Thu, 5 Oct 89 15:47:40 EDT Reply-To: VIRUS-L@ibm1.cc.lehigh.edu Sender: Virus Discussion List From: "The Moderator Kenneth R. van Wyk" Subject: VIRUS-L Digest V2 #214 Comments: To: VIRUS-L@ibm1.cc.lehigh.edu To: Multiple recipients of list VIRUS-L VIRUS-L Digest Thursday, 5 Oct 1989 Volume 2 : Issue 214 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: paper comparing biological and computer viruses CNN coverage of Columbus Day Virus and Friday 13th Virus The DataCrime viruses (PC) Two new PC viruses That's the news... --------------------------------------------------------------------------- Date: 05 Oct 89 06:07:51 +0000 From: munnari!gara.une.oz.au!pmorriso@uunet.UU.NET (Perry Morrison MATH) Subject: Re: paper comparing biological and computer viruses SOFPJF@UOGUELPH.BITNET (Peter Jaspers-Fayer) writes: > This is an outline for a semi-serious paper on the similarities > between biological and computer viruses, and the efforts to understand > and combat them. I present it here in the hopes that others may wish > to contribute a paragraph or so (sorry no money, but I'll give credit > for any material I receive). I wrote a short paper published in the Futurist which introduces the analogy of software and organic viruses. For historical adequacy of your paper, I'd appreciate it if you included it in your bibliography: Morrison, P.R. "Computer Parasites May Cripple Our Computers", The Futurist, 1986, 20(2), 36-38. _ _______________________W_(Not Drowning...Waving!)______________________ Perry Morrison Ph.D, V.D (and scar). SNAIL: Maths, Stats and Computing Science, UNE, Armidale, 2351, Australia. perrym@neumann.une.oz or pmorriso@gara.une.oz Ph:067 73 2302 ------------------------------ Date: Thu, 05 Oct 89 08:51:37 -0500 From: Jim Ennis Subject: CNN coverage of Columbus Day Virus and Friday 13th Virus Hello, Viruses were covered on the CNN 'AT&T Information and Technology' segment of the CNN Daybreak show Weds, 10/4/89. There was a good non-techie description of what a virus is, how it spreads and some safe computing (safe sex) practices. They did not mention how to detect the virus and remove, or who you could contact for more information. They had short pieces with Winn Schwartau 'American Computer Security', Richard Carr 'NASA', and Ross Greenberg 'Software Author'. The show seems to be lumping all computer security problems as 'viruses', it did not attempt to differentiate (sp?) the different types of problems facing computers. Also, they said that the virus will not affect many people, they did not give any estimates on the number of possible infections (which from following this list is pretty small). The segment might run on Sunday during the 'Science & Technology' half hour show (usually in the early afternoon). It was only about 3-4 minutes long. Jim Ennis UCF Computer Services ------------------------------ Date: Thu, 05 Oct 89 17:13:10 +0200 From: Y. Radai Subject: The DataCrime viruses (PC) In August, Alan Roberts, David Chess, and Kelly Goen discussed the DataCrime II virus on VIRUS-L, but only from one point of view: that it's encrypted and that the decryption code includes a routine which prevents looking at the code with a single-step utility. Unless I missed something, none of them thought of telling us anything else concerning how DC-2 differs from the original DC. Much later, however, we did learn several additional differences, for example: (1) DC-2 infects EXE as well as COM files. (2) It increases file size by 1514 bytes. (3) Whereas DC avoids infecting COM files whose 7th letter is "D" (thus avoiding infection of COMMAND.COM), DC-2 avoids infecting COM files whose 2nd letter is "B" (presumably so as not to infect IBMBIO.COM and IBMDOS.COM). So far, so good. But I have since discovered that there was one very important difference which (again, assuming that I haven't missed anything) was not mentioned by anyone on the List: Whereas DC per- forms its damage (low-level format of cylinder 0 of the hard disk) on any day between Oct 13 and Dec 31 of any year, DC-2 does it on any day between Jan 1 and Oct 12, except on Sundays! Y. Radai Hebrew Univ. of Jerusalem ------------------------------ Date: Thu, 05 Oct 89 14:33:43 +0200 From: Y. Radai Subject: Two new PC viruses Two new viruses have been discovered in Israel. One of them is called the Alabama virus. It infects EXE files and increases their size by 1560 bytes. Unlike many other resident viruses, it does not use Int 21h function 31h to stay resident. It loads itself 30K under the highest memory location reported by DOS, but (unlike MIX1) it does not lower the amount of memory reported by BIOS or DOS. It hooks Int 9 and checks for Ctrl-Alt-Del. (It uses IN and OUT commands to confuse anti-virus people.) When it identifies this com- bination it causes an apparent boot but remains in RAM. After 1 hour of operation (the virus checks the time on each Int 9 or Int 21 call), the following flashing boxed message appears: SOFTWARE COPIES PROHIBITED BY INTERNATIONAL LAW.............. Box 1055 Tuscambia ALABAMA USA. This virus does not necessarily infect the file which is currently being executed. First it looks for an uninfected file in the cur- rent directory, and if it finds one it infects it. Only if it does not find one does it infect the executed file. But sometimes, when it finds an uninfected file, instead of infect- ing it, it will *exchange* it with the currently executed file without renaming it, so that the user will think that he is executing one pro- gram while he is actually executing another one! I have less information about the other virus (not even a name for it). It adds 4096 to all infected files (both EXE amd COM, incl. COMMAND.COM). But when you perform DIR you don't see the increase in file size since the virus shows you the *original* (uninfected) sizes. Like the Alabama and MIX1, it does not use the usual TSR function. It also uses INs and OUTs to confuse single-step utilities. My thanks to Eli Shapira for this info. Y. Radai Hebrew Univ. of Jerusalem ------------------------------ Date: Thu, 05 Oct 89 16:00:00 EDT From: "Kenneth R. van Wyk" Subject: That's the news... To quote Saturday Night Live's Dennis Miller, That's the news and I am out of here! VIRUS-L/comp.virus will be back on-line when I return from Maui/Kaui on Oct. 23. Until then, use VALERT-L for *VIRUS ALERTS* only. Please do not use VALERT-L for anything other than virus alerts. Aloha, :-) Ken van Wyk ------------------------------ End of VIRUS-L Digest ********************* 6-Oct-89 20:30:12-GMT,18902;000000000003 Received: from RUTVM1.RUTGERS.EDU by topaz.rutgers.edu (5.59/SMI4.0/RU1.1/3.04) id AA21132; Fri, 6 Oct 89 16:25:03 EDT Message-Id: <8910062025.AA21132@topaz.rutgers.edu> Received: from RUTVM1.RUTGERS.EDU by RutVM1.Rutgers.Edu (IBM VM SMTP R1.2.1MX) with BSMTP id 0664; Fri, 06 Oct 89 16:22:32 EDT Received: from RUTVM1 by RUTVM1.RUTGERS.EDU (Mailer R2.04RU) with BSMTP id 0661; Fri, 06 Oct 89 16:22:25 EDT Date: Fri, 6 Oct 89 16:06:27 EDT Sender: Virus Discussion List From: "The Moderator Kenneth R. van Wyk" Subject: VIRUS-L Digest V2 #215 Comments: To: VIRUS-L@ibm1.cc.lehigh.edu To: Multiple recipients of list VIRUS-L VIRUS-L Digest Friday, 6 Oct 1989 Volume 2 : Issue 215 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: IBM-supplied antivirus software (IBM PC) re: The DataCrime viruses (PC) The not so new virus (Mac) New Mac Virus Appears in Sweden (Mac) Viruses that inhabit "bad" blocks (PC) Re: Why not change OS? Tiger Teams (General) Re: UNIX virus proof?! (UNIX) New Mac Virus Not In 'Moria' But in SuperClock3.5! Re: OGRE virus in Arizona (PC) Now I'm *REALLY* going... --------------------------------------------------------------------------- Date: Thu, 05 Oct 89 16:18:45 -0400 From: "E.C. Greer" Subject: IBM-supplied antivirus software (IBM PC) Below is the text of an announcement recently made by IBM. We got this from our IBM representative. It's not particularly clear to me exactly which viruses this software works for, but I thought I'd pass it along. There is a number to call for more information. September 29, 1989 MEMORANDUM TO: IBM Business Partners SUBJECT: Personal Computer Virus Detection There is an increasing awareness in the industry of the existence of disruptive computer viruses. Several personal computer viruses exist which are expected to activate after October 12, 1989. These viruses can erase a DOS or OS/2* file or render the files on the fixed disk inaccessible. Although the number of reported occurrences is low, this is to alert you to the potential risk of these viruses and to provide you with a program to assist you in detecting them. Enclosed are 3.5 inch and 5.25 inch diskettes with the IBM Virus Scanning Program for personal computers and its license agreement. At your discretion, you may make copies for your customers. Also included are a fact sheet on the IBM Virus Scanning Program and a virus question and answer document. We recommend that you and your customers run the IBM Virus Scanning Program on all of your personal computers using DOS and/or OS/2 as soon as possible prior to October 12th. If you provide customers a copy of these diskettes, you must also pro- vide them with a copy of the license agreement. To ensure a virus free copy, you must follow the instructions in the READ.ME file on the diskette. You should "write protect" all copies of the original disk- ettes. The READ.ME file also contains additional information on the IBM Virus Scanning Program. There is a $35.00 charge for this program. Payment is to be made by the customer directly to: IBM Corporation Grand Central Station P.O. Box 2646 New York, NY 10163 Alternatively, your customer may order the IBM Virus Scanning Program (part number 64F1424) at a cost of $35.00, with a major credit card, directly from the IBM fulfillment center by calling 1-800-426-7282. IBM Virus Scanning Program Fact Sheet + _____________________________________ WARNING - BEFORE USING THE IBM VIRUS SCANNING PROGRAM MAKE CERTAIN THAT THE COPY YOU INTEND TO USE COMES FROM A SECURE UNINFECTED SOURCE, AND THAT THE DISKETTES' WRITE PROTECT TAB IS IN PLACE IF THE DISKETTE IS NOT PERMANENTLY WRITE PROTECTED. The IBM Virus Scanning Program has been developd by IBM to aid in the detection of some computer viruses and is being used internally by IBM to detect computer viruses. The program is designed to scan boot records and executable files looking for signatures of viruses known to IBM when the program was written. A signature is a bit pattern that is indicative of a particular virus. The files that are scanned by the IBM Virus Scanning Program must be in their native executable form (e.g., not encrypted and not packed) in order for signature matching to occur. There may be other viruses that currently exist, or will exist in the future, that the IBM Virus Scanning Program will not detect. We know of no available, guaranteed solution to computer viruses, so we recommend regular backups of your data, caution in acquiring and using software and good security practices. Description of the IBM Virus Scanning Program +_____________________________________________ The program tests executable files on disks for signature strings that are found in some common DOS computer viruses. For each drive specified it will also test the drive for boot sector viruses. To use it, simply type at the command prompt (for example) VIRSCAN C: to scan the executable files on the C: drive or VIRSCAN A: to scan the executable files on the A: drive or VIRSCAN n: n: n: to scan multiple drives (n = drive id) Type VIRSCAN without any arguments for some help. Files infected with a virus should be erased and replaced with uninfected copies (obtained from the original source, such as original manufacturer's diskettes, in-house source code, backup copies, etc). NOTE: Prior to restoring any files, run the program against the diskette from which you plan to restore to ensure it is virus-free. Technical Detail: +________________ VIRSCAN.EXE is the executable program. It will run under DOS 2.0, 2.1, 3.1, 3.2, 3.3, 4.0 and OS/2* 1.0, 1.1, and 1.2. It will not support OS/2 1.2 with high performance file system names. Virus detection programs and services are available from other companies and you may also wish to advise your customers of these. The IBM Virus Scanning Program will not detect all personal computer virus possibili- ties and should be considered complementary to, and not a substitute for, established security and backup procedures. If you have any questions, please call the NDD National Support Center at 1-800-IBM-PROD or contact your IBM marketing representative. R. F. Martino Vice President Marketing Enclosures * Trademark of the IBM Corporation ------------------------------ Date: 05 Oct 89 00:00:00 +0000 From: David.M..Chess.CHESS@YKTVMV Subject: re: The DataCrime viruses (PC) > DC-2 does it on any day > between Jan 1 and Oct 12, except on Sundays! That's not true for the sample that I've seen. I suspect someone's just misreading the code (it's easy to do; that area is rather convoluted). It could be a new variant, of course, but if it really *did* do its damage between Jan 1 and Oct 12, wouldn't it have basically Gone Off by now? I think your source is just misinformed. There does seem to be a day-of-the-week check in there, but I'm not sure what it does at the moment (not damaging on Sundays is possible, but I wouldn't want to promise anyone!). In summary, the important differences that I know of between the DataCrime (1168 and 1280 strains) and the DataCrime II are that the II: - Makes COM files 1514 bytes longer when it infects them - Also infects EXE files - Stores itself garbled on disk (except for the degarbler) - Has a slightly different message ("* DATACRIME II VIRUS *") Otherwise, it's the same beast, with the same damage conditions. Of course there may be more variants that I haven't seen! DC ------------------------------ Date: 05 Oct 89 20:59:34 +0000 From: jap2_ss@uhura.cc.rochester.edu (Joseph Poutre) Subject: The not so new virus (Mac) Enclosed is a mail message written by a fellow consultant. When it first appears, it's just a form of the nVIR virus which AntiPan works very well to eradicate. But it seems to be a self modifying code which causes it to mutate to an unrecognizable form. SO, what do we do about it, you ask? Well, we have had exceedingly good success in both TAGGING and ERADICATING the virus with a program called SYMANTEC ANTI-VIRUS CLINIC. If the virus is tagged, it can be eradicated with AntiPan, or it can be eradicated with SAM, the SYMANTEC ANTI-VIRUS CLINIC. So when people bring you their disks to have checked, please run SAM on them. It's very easy, there will be instructions at the desk. Copies of this message and an infected application will be sent to all those who requested copies, and any others who also ask. This is _not_ an endorsement of any sort for SAM, or Anti-pan. Joseph Poutre (The Mad Mathematician) jap2_ss@uhura.cc.rochester.edu ------------------------------ Date: Thu, 05 Oct 89 22:41:25 +0700 From: Bertil Jonell Subject: New Mac Virus Appears in Sweden (Mac) Here on Chalmers, we've found an STR id 801 in the game MORIA (Recently posted on comp.binaries.mac), I havent gotten time to check it yet byt it *might* have come with moria. (Altough some signs seam to indicate that it has been around for a long time) Any information on the virus, It's effects and possible techniques to combat it will be geatly appriciated. - -- Bertil K K Jonell @ Chalmers University of Technology, Gothenburg NET: d9bertil@dtek.chalmers.se VOICE: +46 31 723971 / +46 300 61004 "Don`t worry,I've got Pilot-7" SNAILMAIL: Box 154,S-43900 Onsala,SWEDEN (Famous last words) "So for more than a decade, Tiamat had been observing Lucifer with every possible kind of instrumentation" A.C.Clarke '2061' ------------------------------ Date: Thu, 05 Oct 89 19:26:00 -0400 From: MAS-Polecat Subject: Viruses that inhabit "bad" blocks (PC) I was just reading about the OGRE virus when I noticed a pattern. Since a lot (is it a lot?) of viruses mark the sectors they are using as bad, why not just write a utility that will look up the bad sectors on a disk and erase them. There are utilities available now that will analyze EACH sector on a disk to see if it is bad or not. If it is marked bad, but seems ok they will put that sector back into the available sector list. I think SpinRight (sp?) and perhaps PCTools do this. Even if not all of the virus is eradicated, it seems that it would at least be fatally crippled. Has anyone tried this? Erik Bryant Student Assistant Programmer University at Buffalo ------------------------------ Date: Thu, 05 Oct 89 21:35:04 -0400 From: ficc!peter@uunet.uu.net Subject: Re: Why not change OS? time@oxtrap.aa.ox.com (Tim Endres) writes: > Better than changing OS to get better virus "resistance", why not > encourage the systems designers at Apple and IBM to implement > protection in their respective operating systems? I don't know about the Mac... its system software is a lot cleaner than Messy-DOS, albeit rather unconventional. But this is pretty much impossible with MS-DOS. I suspect you would have to write a complete new operating system with an MS-DOS emulator. The reason for this is that the original MS-DOS was so incompetant (for example, the serial driver code never worked right for anything better than dumping to a printer, and it's never been fixed) that any decent program was forced to go direct to the hardware. And of course if you're going to go to a new O/S, why not use an off-the-shelf one that's already achieved wide acceptance? I once sat down and tried to write a terminal emulator that was entirely well-behaved. I was able to keep up with 1200 baud using the XT bios to put stuff on the screen, by heavy use of curses-style heuristics, but I broke down and went straight to the serial port. Of course, OS/2 is supposed to fix all this. For some bizzarre reason, though, it's still got no security features. Anyway, the reason Apple and IBM aren't doing anything is because there's no great call from the user community to do anything, and nobody's willing to consider a better alternative if it means risking their cherished soft- ware investment. Which is only reasonable, but there's no reason new installations can't be based on something like UNIX. - --- Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation. Biz: peter@ficc.uu.net, +1 713 274 5180. Fun:peter@sugar.hackercorp.com. `-_-' ``I feel that any [environment] with users in it is "adverse".'' ------------------------------ Date: Fri, 06 Oct 89 08:18:43 -0400 From: "Andy Wing" Subject: Tiger Teams (General) Hi, I think that your average non-sophisticated user would be offended by computer support personnel checking their personal machine for "infection". An alternative would be to have the Tiger Teams simply state that they are doing "regular preventative maintenance". People shouldn't have problems with that. The end user doesn't need to know the gruesome details of a PM call. Actually Tiger Team duties should be assigned to a companys regular maintenance people (with a software expert supervising them of course). I guess the best anti-virus protection is one that is both transparent to the end user and in the hands of a well trained support staff. The original Tiger Team idea would work best if slightly modified. Every football team has both an offence and a defense. Right now the anti-viral defense really has no one to practice against. I think what we need is a group of developers that will try to "bust" Gatekeeper/Flushot/etc. These people would be in close contact with the anti-viral developers. The Tiger Team would document their methods and only use benign infections. I guess my real concern is that anti-virus developers take a reactive stance instead of an active one. If I were a anti-virus developer, I would want to encounter a new infection method under controlled, documented conditions. This way anti-viral SW would be guarded against bypass methods already thought up by the Tiger Teams. Also, do any anti-viral programs use the 'bad block' method to protect themselves? I think that idea holds some promise. Andy Wing V2002A@TEMPLEVM.BITNET ------------------------------ Date: 06 Oct 89 15:22:42 +0000 From: jmc@PacBell.COM (Jerry Carlin) Subject: Re: UNIX virus proof?! (UNIX) ficc!peter@uunet.uu.net writes: >I wouldn't say UNIX is virus-proof (I posted a hoax article about a >UNIX virus over a year ago, just before the Internet Worm incident), >but it's sure a hell of a lot more virus-resistant than DOS. See "Experience with Viruses on UNIX Systems" by Tom Duff in Computing Systems, Vol 2 No 2, Sprint 89 pp: 155-181. He discusses building a true UNIX virus and the consequences thereof. - -- Jerry Carlin (415) 823-2441 {bellcore,sun,ames,pyramid}!pacbell!jmc To dream the impossible dream. To fight the unbeatable foe. ------------------------------ Date: Fri, 06 Oct 89 14:51:08 +0700 From: Bertil Jonell Subject: New Mac Virus Not In 'Moria' But in SuperClock3.5! Today when I had time to check the various downloads that had been occuring during the last few days I found that the recource STR ID 801 appeared in the document Clock Doc (a word document). I double checked this by extracting it from the .sit archive again and examinig it directly (On Cue from StuffIt to ResEdit). Since Stuffit and Resedit seems to be clean from this and othe known viruses I can only assume that the virus was there when Clock Doc was packaged! What I'm wondering now is: Is it confirmed that the STR ID 801 really *is* a sign of a virus? Is there any chance that it is a legitimate resource? (I've tested making new MacWrite documents with a locked copy, They have resources this 'International Resource' and a STR resource ID 701, None of them have had a STR ID 801) Clock Doc comes with the SuperClock! 3.5 INIT Recently posted to the comp.binaries.mac newsgroup. I'm sorry for causing constenation by proclaming Moria as a possible source, (Frankly, That .sit archive had been deleted so I couldn't check it, But since the known infected machines both had Superclock 3.5 installed within the last few days, Moria hav dropped off the list of prime suspects) - -bertil- Bertil K K Jonell @ Chalmers University of Technology, Gothenburg NET: d9bertil@dtek.chalmers.se VOICE: +46 31 723971 / +46 300 61004 "Don`t worry,I`ve got Pilot-7" SNAILMAIL: Box 154,S-43900 Onsala,SWEDEN (Famous last words) "GOOD DEEL ON SLIGHTLY USED CRANE" - Orson Scott Card 'The Abyss' ------------------------------ Date: Fri, 06 Oct 00 19:89:36 +0000 From: clout!kericks!ken@gargoyle.uchicago.edu Subject: Re: OGRE virus in Arizona (PC) > A new, extremely nasty virus has been discovered on some IBM PCs in > the state of Arizona. This virus, known as OGRE, has been found on > some disks in Flagstaff and nearby areas. This is the first > recognition of said virus that has come to my attention. This memo > gives a description of the virus and possible ways of recognizing and > removing it. This is a very interesting virus. However, I would like to know if anyone knows how it originally infects a disk. It would seem that it would have to be in an executable program at least initially (to infect the first disk). Any ideas? ------------------------------ Date: Fri, 06 Oct 89 16:00:00 EDT From: "Kenneth R. van Wyk" Subject: Now I'm *REALLY* going... Really, this is the *last* digest until I get back! I stopped in the office on the way to the airport and was overwhelmed by the amount of email, so I decided to send out *one* more digest (especially since some of it pertained to DataCrime - which should be history by the time I return). So now I'm on my way out the door. REALLY! :-) Ken ------------------------------ End of VIRUS-L Digest ********************* 24-Oct-89 11:51:51-GMT,17287;000000000001 Received: from RUTVM1.RUTGERS.EDU by topaz.rutgers.edu (5.59/SMI4.0/RU1.1/3.04) id AA25292; Tue, 24 Oct 89 07:51:22 EDT Message-Id: <8910241151.AA25292@topaz.rutgers.edu> Received: from RUTVM1.RUTGERS.EDU by RutVM1.Rutgers.Edu (IBM VM SMTP R1.2.1MX) with BSMTP id 2779; Tue, 24 Oct 89 07:49:47 EDT Received: from RUTVM1 by RUTVM1.RUTGERS.EDU (Mailer R2.04RU) with BSMTP id 2776; Tue, 24 Oct 89 07:49:40 EDT Date: Tue, 24 Oct 89 07:38:54 EDT Sender: Virus Discussion List From: "The Moderator Kenneth R. van Wyk" Subject: VIRUS-L Digest V2 #220 Comments: To: VIRUS-L@ibm1.cc.lehigh.edu To: Multiple recipients of list VIRUS-L VIRUS-L Digest Tuesday, 24 Oct 1989 Volume 2 : Issue 220 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: The Power to Look Your Stupidest... (Mac) Not-equals VIR Resource (Mac) RE: IBM-PC virus scanning program from IBM (PC) Dark Avenger and scanners (PC) Re: 0 bytes in 1 hidden file, virus?? (PC) Viruses in archives (PC) init29: data->application?(Mac) Viral susceptivity of UNIX vrs MS-DOS Ohio Virus (no system given) Creating a virus free boot disk (PC) Re: /VIR ([not-equal-to-sign]VIR) App Signature (Mac) Re: The DataCrime viruses (PC) It can happen to anyone :-( (PC) --------------------------------------------------------------------------- Date: Mon, 23 Oct 89 11:17:31 -0400 From: Joe McMahon Subject: The Power to Look Your Stupidest... (Mac) Some significant facts: 1) Careful testing of SuperClock 3.5 (including dissection via ResEdit) turns up no - repeat, NO - viruses of any kind from any source I can get it from. 2) STR 801 in a MacWrite file is OK and is in fact normal. 3) No further developments have been heard. Can you please tell us more, if anything? 4) Has anyone actually gotten to see this supposed virus? If you have a copy, will you PLEASE send it to John Norstad, or your favorite author of anti-virals? I apologize abjectly to those who may have been misled by *my* contributions. Networking means having to say you're sorry to LOTS of people :-(. --- Joe M. ------------------------------ Date: Mon, 23 Oct 89 11:24:14 -0400 From: Joe McMahon Subject: Not-equals VIR Resource (Mac) A Not-equals-VIR resource on your disk or in your Desktop file just means that you ran the Interferon program at some point and haven't removed it or rebuilt your Desktop file lately. Nothing to worry about. --- Joe M. ------------------------------ Date: 23 Oct 89 00:00:00 +0000 From: CHESS@YKTVMV.BITNET Subject: RE: IBM-PC virus scanning program from IBM (PC) Thomas Lapp writes: > Since it reports the number of files searched and number of > disks checked, I suspect that this program would not be able to find > those viruses which reside on sectors which are then marked bad. All the viruses that I've heard of that live even partially in bad sectors are boot-sector viruses; the "initial hook" of the virus is written to the boot sector, and that hook then reads the rest of the virus off of some sector elsewhere on the disk (which was marked bad in the FAT at initial infection). The IBM virus scanner (and the McAfee one, and probably others) scans boot records to detect this type of virus. In general, a virus has to arrange to get executed; the viruses we've seen so far do this either by modifying executable files, or by modifying the boot record of a disk or diskette. So scanners for known viruses that scan executable files and boot records are looking in the right places! A "virus" that just marked a sector as bad and wrote itself there, without altering the boot sector or any other executable object, would never get executed... DC ------------------------------ Date: 23 Oct 89 00:00:00 +0000 From: CHESS@YKTVMV.BITNET Subject: Dark Avenger and scanners (PC) (This is in reply to Alan Roberts' warning about the Dark Avenger and scanners in VALERT-L.) The recommended procedure for using the IBM Virus Scanning Program includes, I'm pretty sure, cold-booting the machine from a trusted boot diskette before running the scanner. This will keep the "spreads to all files on the disk" from happening, since it will mean that the virus isn't in control when the scanner runs. It's also a bit of a pain, but it may be worth it. If another virus like the Dark Avenger appears, and you run a scanner that doesn't know about it, without cold-booting first, you could end up with an entire disk full of infected files, and not even know it! This isn't really a bug in the scanners that needs to be "fixed". Any program that opens many many files can have the same effect when an infect-on-open virus is active. This includes virus scanners, anti-virus programs that compute check-values for your executables to let you know what's changed, backup programs, GREP-like programs, and so on. It would certainly be a nice enhancement if the scanners also scanned RAM before going to the disk, but even that won't solve the general problem (since an infect-on-open virus not known to the scanner can still be spread to the entire disk, unless you cold-boot before scanning). DC ------------------------------ Date: Mon, 23 Oct 89 11:09:00 -0500 From: Subject: Re: 0 bytes in 1 hidden file, virus?? (PC) In reference to CHKDSK's message about 0 bytes in 1 hidden file, if I remember correctly, CHKDSK is probably registering the volume label, in which case PCTOOLS does show it (at the top of the screen, instead of in the file listing). Try installing the system onto the disk (i.e. SYS A:), and then run a CHKDSK. It should register xxxxxx bytes in 3 hidden files, where xxxxxx depends on the version of the system that you are using. Respectively, the hidden files should be: IBMBIO.COM -- Contains the BIOS routines IBMDOS.COM -- Contains the DOS routines (volume label) IBMBIO.COM and IBMDOS.COM will appear in the PCTOOLS window. They will probably have the HIDDEN, SYSTEM, and READ-ONLY bits on. It may also have the ARCHIVE bit on. Joel N. Fischoff Software Support/Technician DePaul University, Chicago, IL ------------------------------ Date: Mon, 23 Oct 89 14:25:00 -0600 From: CHRISTOPHER%GACVAX1.BITNET@VMA.CC.CMU.EDU Subject: Viruses in archives (PC) Are there any programs currently available that will check for viruses within an archive file? I am familiar with the SHEZ program and how it can be used with VIRUSCAN to scan archives, but SHEZ un-arcs the archive file before running VIRUSCAN. My question is, does a program exist or could one be developed that searched for signs of an archived and infected program? I can see two big problems with this immediately. First, each different archiving algorithm will archive a virus (call it X) differently. An ARCed X will be different from a ZIPed X will be different from a ZOOed X, etc. Secondly, say that virus X attaches itself to the end of COM files. Will the output (archived file) of an archiving algorithm translate virus X into the same byte sequence every time? For example, program A is infected and becomes AX. Is arc(AX) (archived AX) the same as arc(A) + arc(X) and is arc(BX) the same as arc(B) + arc(X)? I inquire because I have archived programs/software, and I would like to know if programs in archives are infected without de-archiving them (at last count I had over 100 .ARC files) and then SCANing them as SHEZ does. Christopher Kane ------------------------------ Date: Mon, 23 Oct 89 10:55:45 -0700 From: jim@insect.Berkeley.Edu Subject: init29: data->application?(Mac) INIT29 is a "popular" :-) new Macintosh virus that has the unusual property of being able to infect data files, as well as applications. QUESTION: If a diskette that CONTAINS ONLY DATA FILES, which are infected by INIT29, is accessed by an uninfected application residing on a clean diskette, can the virus spread to the clean disk? (Prior to INIT29, I had been advising my users that if they go to Kinko's they would be safe if they took only their data diskette. But if a data infection can spread to their application disks, this would not be good advice.) Anyone got the REAL answer? Jim Bradley, CNR Computer Facility, UC Berkeley ------------------------------ Date: Mon, 23 Oct 89 16:15:00 -0800 From: Steve Albrecht Subject: Viral susceptivity of UNIX vrs MS-DOS in: VIRUS-L Digest V2 #217 Subject: Operating System virus protection (DOS & UNIX) Re: UNIX virus proof?! (UNIX) jlg@lanl.gov (Jim Giles) writes: >>I wouldn't say UNIX is virus-proof (I posted a hoax article about a >>UNIX virus over a year ago, just before the Internet Worm incident), >>but it's sure a hell of a lot more virus-resistant than DOS. > >How do you know? The only machines DOS runs on are PCs and compatibles. >UNIX implemented on these machines would be just as vulnerable as DOS. >The most obvious weaknesses of DOS are unimportant compared to the fact >that the hardware itself has no protection mechanisms. Assuming everyone means "MS-DOS" when using the common acronym "DOS"... Every UNIX implementation on 80286/386 processors that I've seen uses the Intel Protected Mode. If used properly, this provides process isolation. This alone is a great security improvement over MS-DOS. File system security can be provided similarly by using memory-mapped rather than i/o mapped devices. Their are a few UNIX implementations which run on 8088-based PCs. It is true that hardware support for process isolation and file security are lacking in off-the shelf IBM PC and PC/XT-type machines. The rarity of such machines running UNIX is a wonderful defense against viruses, however. The fact remains that most users of PC/AT and 386-based machines use MS-DOS which, now in its 4th major version, is still incapable of using Intel Protected Mode. Thus, Peter's original statement is fully justified. MS-DOS is (also) an easier target than UNIX because of its simplicity and easy access to technical information. While UNIX internals are also widely available, they are written for more sophisticated readers. The multitudinous flavors of UNIX also inhibits low level attacks. MS-DOS is is a sitting duck (such being the price of standardization). As an aside, I abhor the idea of anyone promulating "virus hoaxes" or other forms of terrorism. As I lack complete understanding of Peter's claim to have "posted a hoax article about a UNIX virus over a year ago", I will resist further comment on this distasteful subject. (::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::) ) Steve Albrecht - IntelliCorp, Inc. - Knowledge Systems Product Development ( ( "Opinions expressed here are my own, if anyone's, and not my employer's." ) ) DDS albrecht@intellicorp.com : COMPUSERVE 73657,1342 ( ( UUCP ...!sun!intellicorp.com!albrecht : public bbs (415)969-5643 ) ) or ...!sun!icmv!albrecht : "c"omment to sysop ( (::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::) ------------------------------ Date: 23 Oct 89 14:13:01 +0000 From: wsinrn@urc.tue.nl (Rob J. Nauta) Subject: Ohio Virus (no system given) Hello everybody I'm back on a new usercode. If you still have my old one (RCSTRN@HEITUE51.BITNET) please replace it by this one, as my bitnet account expired sept. 1st. I have a question. I recently found the Ohio Virus on a disk. I've never heard of it, who knows more about it? Thanks in advance Rob J. Nauta wsinrn@eutrc3.UUCP wsinrn@urc.tue.nl ------------------------------ Date: Mon, 23 Oct 89 22:24:09 -0400 From: Dave Subject: Creating a virus free boot disk (PC) In regards to the already-resident-virus problem(disinfecting), I follow a fairly easy procedure... Do a low-level format of a new disk.. Take your original(Write-protected, of course) dos and sys the disk.. add command.com and your favorite virus scanner.. This is something that you should do BEFORE you are infected... You have to be sure that your scanner is clean.. Now write protect the disk and tuck it away somewhere.. If you think you're infected, shut down and boot from your floppy.. Now you have no resident virus's.. I don't trust mem-res scanners, myself.. Dave Hoelzer @sunyB.. CONSP12@bingvaxa ------------------------------ Date: Tue, 24 Oct 00 19:89:02 +0000 From: biar!trebor@uunet.UU.NET (Robert J Woodhead) Subject: Re: /VIR ([not-equal-to-sign]VIR) App Signature (Mac) In: VIRUS-L Digest Monday, 23 Oct 1989 Volume 2 : Issue 216 prieto@gem.mps.ohio-state.edu (Juan Pablo Prieto-Cox) writes: >I also found a resource of type =/VIR (for >typographical reasons by =/ I mean the symbol for not equal). Remember >that I had already ran Disinfectant. Does anyone have a clue? or a >similar problem? You may have a new nVIR strain (I would appreciate copies of infected files), but =/VIR is the application signature of my Interferon program. This is not the first time this has come up, and in retrospect it may have been a bad choice. Just FYI: =/VIR Interferon VIRx Virex (early versions) VIRy Virex (more recent versions) Robert J Woodhead, Biar Games, Inc. !uunet!biar!trebor | trebor@biar.UUCP Announcing TEMPORAL EXPRESS. For only $999,999.95 (per page), your message will be carefully stored, then sent back in time as soon as technologically possible. TEMEX - when it absolutely, postively has to be there yesterday! ------------------------------ Date: 24 Oct 89 09:13:11 +0000 From: jr@ncrsecp.Copenhagen.NCR.dk (Jakob Riis) Subject: Re: The DataCrime viruses (PC) In article <0002.8910062006.AA22699@ge.sei.cmu.edu> David.M..Chess.CHESS@YKTVMV writes: >> DC-2 does it on any day >> between Jan 1 and Oct 12, except on Sundays! >That's not true for the sample that I've seen. I suspect someone's >just misreading the code (it's easy to do; that area is rather >convoluted). It could be a new variant, of course, but if it really >*did* do its damage between Jan 1 and Oct 12, wouldn't it have >basically Gone Off by now? I think your source is just misinformed. You might both be right ! The de-assembled code I've seen shows that its fairly easy to trim DCII to go off anytime you would like it - in fact you can de-arm it yourself by setting the day check equal 8 ! (but I guess I would rather re-install the original programs). If I don't remember wrong the newly dreaded Columbus day Virus was such a re-programming of DCII. Just my 2 cents worth, _____________________________________________________________________________ Jakob Riis | Jakob.Riis@Copenhagen.NCR.dk NCR Corporation | or Systems Engineering Copenhagen | ..!uunet!mcvax!dkuug!ncrsecp!jakob.riis - --------------------------------------------------------------------------- ! A plucked goose doesn't lay golden eggs ! - --------------------------------------------------------------------------- ------------------------------ Date: Tue, 24 Oct 89 11:18:37 GMT From: frisk@rhi.hi.is (Fridrik Skulason) Subject: It can happen to anyone :-( (PC) Well - now I know of one victim of the Datacrime-II virus ..... myself. :-( Last Tuesday I was demonstrating how any known virus could be stopped with my anti-virus program. Unfortunately I had forgotten that it was not installed at the time :-( So, when I ran a program infected with DataCrime-II, I just got the message DATACRIME II Bye bye hard disk...... I turned the computer off, but when I turned it on again the computer would of course not boot from the hard disk, but instead jumped into BASIC. When I booted from a diskette, the computer would not even admit that drive C: existed. It sounds bad, but this took only a few minutes to fix, simply by... ... formatting track 0 with correct parameters ... running NDD and everything was back to normal again. phew ! -- frisk [Ed. NDD = Norton Disk Doctor, right?] ------------------------------ End of VIRUS-L Digest ********************* 24-Oct-89 22:46:33-GMT,23248;000000000001 Received: from RUTVM1.RUTGERS.EDU by topaz.rutgers.edu (5.59/SMI4.0/RU1.1/3.04) id AA21674; Tue, 24 Oct 89 18:42:47 EDT Message-Id: <8910242242.AA21674@topaz.rutgers.edu> Received: from RUTVM1.RUTGERS.EDU by RutVM1.Rutgers.Edu (IBM VM SMTP R1.2.1MX) with BSMTP id 5114; Tue, 24 Oct 89 18:37:21 EDT Received: from RUTVM1 by RUTVM1.RUTGERS.EDU (Mailer R2.04RU) with BSMTP id 5111; Tue, 24 Oct 89 17:57:35 EDT Date: Tue, 24 Oct 89 15:15:20 EDT Reply-To: VIRUS-L@ibm1.cc.lehigh.edu Sender: Virus Discussion List From: "The Moderator Kenneth R. van Wyk" Subject: VIRUS-L Digest V2 #221 Comments: To: VIRUS-L@ibm1.cc.lehigh.edu To: Multiple recipients of list VIRUS-L Status: O 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 ********************* 25-Oct-89 12:14:59-GMT,23026;000000000001 Received: from RUTVM1.RUTGERS.EDU by topaz.rutgers.edu (5.59/SMI4.0/RU1.1/3.04) id AA22938; Wed, 25 Oct 89 08:14:45 EDT Message-Id: <8910251214.AA22938@topaz.rutgers.edu> Received: from RUTVM1.RUTGERS.EDU by RutVM1.Rutgers.Edu (IBM VM SMTP R1.2.1MX) with BSMTP id 6685; Wed, 25 Oct 89 08:12:23 EDT Received: from RUTVM1 by RUTVM1.RUTGERS.EDU (Mailer R2.04RU) with BSMTP id 6682; Wed, 25 Oct 89 08:11:08 EDT Date: Wed, 25 Oct 89 07:54:52 EDT Reply-To: VIRUS-L@ibm1.cc.lehigh.edu Sender: Virus Discussion List From: "The Moderator Kenneth R. van Wyk" Subject: VIRUS-L Digest V2 #222 Comments: To: VIRUS-L@ibm1.cc.lehigh.edu To: Multiple recipients of list VIRUS-L Status: O VIRUS-L Digest Wednesday, 25 Oct 1989 Volume 2 : Issue 222 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: VIRUSCAN/VIRSCAN Issues (PC) Free Catalog Disk Infected (PC) Protecting Your User's Disks (Mac) New virus in Israel (PC) You're not alone; DataCrime infection report (PC) possible virus infection (PC) Re: 0 bytes in 1 hidden file, virus? (PC) The not-so-new virus (Mac) Re: VIRUSCAN test (IBM PC) Jerusalem Virus Version B detected (PC) --------------------------------------------------------------------------- Date: Tue, 24 Oct 89 11:12:03 -0700 From: portal!cup.portal.com!Alan_J_Roberts@Sun.COM Subject: VIRUSCAN/VIRSCAN Issues (PC) The following is a forwarded message from John McAfee: ============================================================================= A number of people have commented on the "closed" architecture of VIRUSCAN and the encryption of the individual search strings used for virus identification. Some users feel that this is done in order to maintain a "monopoly" in the scanning industry and to keep competitors from using the same strings. I would like to put that concern to rest, if possible. First, as many users will have noticed, the earlier versions of SCAN had all strings available for anyone who cared to look at them. The users who wished merely to scan for viruses merely noticed them, shrugged (really - what value is it to the average user?), and went on. The folks who seemed to take notice of the strings were those few crackers who used the strings to change the virus segments referenced by the strings. This has happened seven times in three months, the most recent being the New Jerusalem virus discovered by Jan Terpstra and Ernst Baedecker in the Netherlands. The virus is identical to the Jerusalem-B, with the exception of the string changes that SCAN originally referenced. What this does is invalidate all of the work done to date on identification of the Jerusalem-B. To make it more difficult for crackers to get around the scanning process, I've done two things: 1. encrypt the strings (I know that this merely slows down the determined cracker, but it does deter the casual cracker - of which there are many). and 2. I use multiple strings for the more mutable viruses. In addition, I have taken to randomly changing strings for different versions of scan. None of this was done to deter competition. In fact, as Art Gilbert and Bill Vance at IBM should agree, I co-operate fully with competitors in providing virus samples, infection trends, market information and (possibly unwelcome) suggestions for improvements and points to watch out for in the more troublesome viruses. I even provide my string lists to any legitimate competitor who asks for them. I just don't provide them to the public, and I'm not sure the public really would be served by knowing the binary string sequences I use to identify a given virus. I response to the comments that IBM's open string list will make it easier for users to update the files themselves - I absolutely agree. There's a lot to be said for the flexibility and control that such an approach brings. But, ignoring the problem crackers for the moment, we will have to ask - who is going to update the string files? Is it each user? If so then chaos will ensue. I can categorically say that the average user is incapable of taking a live virus sample and creating a valid search string for that virus. The problems are immense. First, many viruses are written in C, PASCAL or other higher level language. Unless you are familiar with the actual code generated by the compiler runtime library and the canned compiler output sequences, you will have dificulty separating the origin virus code from the same code that you will find in hundreds or maybe thousands of other similarly compiled programs. Second, the string segments must have a unique "style" that will avoid false alarms with similar styled programs. For example, choosing a long string of register saves as an identifier will guarantee false alarms with other programs. The user will also have to know something about the infective characteristics of the virus as well. Does it only infect the partition record, or the boot sector? Does it infect overly files? Which ones? etc. All in all it is a task that most user shouldn't have to face. So we can agree, I think, that the strings will havee to be done by competent programmers with a fair amount of virus experience if it is to work. The question then is - which programmers? Who will set the standard. If there is no standard, then again, chaos results and which version of the strings swhould we use? My feeling is that the IBM approach works well for researchers, but that the general public should use only the strings that IBM produces (or someone that IBM should designate). So much for my soap-box for the day. We survived the earthquake out here. We were 6 miles from the epicenter, but we must have been on a standing wave since we suffered only moderate damage. My cat slept through the entire event (though, admittedly, he only normally wakes for 15 minutes at breakfast and 20 minutes at dinnertime). Have a good day. John McAfee ------------------------------ Date: Mon, 23 Oct 89 19:21:00 -0500 From: IA96000 Subject: Free Catalog Disk Infected (PC) My friend just received, and I now have in my posession a free disk from a Shareware copying company, which he received after he sent in a "bingo" card from a popular computer magazine. The disk has three infected files on it: 1) GETKEY.COM 3074 bytes 01-01-80 12:35a 2) CL.COM 3457 bytes 08-01-86 02:39p 3) LIST.COM 7871 bytes 06-17-86 02:37p SCAN version 0.7V42 reports as follows: GETKEY.COM - 3066/2930 TRACEBACK VIRUS CL.COM - 3066/2930 TRACEBACK VIRUS LIST.COM - FU MANCHU VERSION A GETKEY.COM and CL.COM are in the disks ROOT directory. CL.COM appears to a hidden file, as it is not seen when you do a DIR from the DOS prompt. LIST.COM is in the subdirectory \ORD. To be fair to the company which sent the disk, I will mention their name here, as in all probability, they do not know the disk is infected. No sense creating another major problem... The disk label is designed as follows: 1989 COMPANY NAME CATALOG *************************** P.O. xxxx HESPERIA, CA 92345 MAY VIEW OR PRINT CATALOG & ORDERFORM TO START CATALOG . . . A>START The disk has one subdirectory on it named \ORD which contains 8 files. The ROOT directory contains 25 files. My friend spotted the fact that LIST.COM is in both the ROOT and the sub-directory and the file sizes differ. Also, since he did not know the company, he ran SCAN as a precaution. If Dave Chess at IBM or Mr. McAfee wants a copy of this disk, please let me know...by EMAIL. I have gone to great lengths to not identify the company to avoid any problems. Also..please note this disk WAS NOT sent to the university, nor was any damage done to any of the university equipment. I hope I have given you all enough information to identify the disk, if you happen to receive one. The disk was not unsolicited, in other words, the disk was requested by my friend and the magazine has nothing to do with this issue, at this point in time. ------------------------------ Date: Tue, 24 Oct 89 15:32:00 -0500 From: "Thomas R. Blake" Subject: Protecting Your User's Disks (Mac) >(Prior to INIT29, I had been advising my users that if they go >to Kinko's they would be safe if they took only their data diskette. >But if a data infection can spread to their application disks, >this would not be good advice.) > >Anyone got the REAL answer? Well, I assume they're going to Kinko's to print. (Yes/No?) I'd say if they write-protect their diskettes they have no need to worry. Macintosh viruses will not spread to write-protected diskettes. Thomas R. Blake SUNY-Binghamton ------------------------------ Date: Tue, 24 Oct 89 19:32:37 +0200 From: "Yuval Tal (972)-8-474592" Subject: New virus in Israel (PC) A new virus was found here in Israel. I didn't know whether to call it: The Do Nothing Virus or The Stupid Virus. The author (which is as usually known) put an infected program on one of the BBSs in Israel. The program was an infected program which my friend wrote BUT it claimed to be a new version (eg. my friend's latest version was 3.4 and the one on the BBS was 4.0). He quickly downloaded this file and he found out that it is infected with a virus. After checking this virus he and I got to one big conclusion. The author of this virus probably doesn't know assembly so good. You can see this quite clear: -The virus tries to push only one byte into the stack. -The virus is copied always to location 9800:100h this means that it will work only on computers 640KB. The virus doesn't reduce the amount of memory (like other viruses such as Denzuk, Ping-Pong etc'). The virus is copied and that's it! Turbo Pascal, for instance, may use this location as heap and the virus may be erased from memory. Another thing, this virus infects only the first .COM file on the directory. It doesn't check if the file is already infected or not, it just infects it. This virus does nothing besides infecting the file, no damage at all! This is why I called it The Do Nothing Virus. Here is a report I made. I may change it a bit here and there.. - -------------------------------------------------------------------------- Entry................: The Do Nothing Virus Alias(es)............: The Stupid Virus Virus detection when.: 22-October-1989 where.: Israel Classifications......:.COM file infecting virus/extending. Length of virus......: 583 bytes add to file. Operating system(s)..: MS-DOS Version/release......: 2.0 or higher Computer model(s)....: IBM PC,XT,AT and compatibles Identification.......: .COM files: The first 3 bytes of the infected files are changed. System: The virus copies itself to 9800h:100h. Type of infection....: Extends .COM files. Adds 583 bytes to the end of the file. The virus copies itself to 9800:100h. This means that only computers with 640KB may be infected, hooks int 21 and infects other programs by scanning the directory until it finds a .COM file. It is infected upon function Fh and 3Dh. .EXE files are not infected. Infection trigger....: The first .COM file of the current directory is infected whether the file is infected or not. Interrupts hooked....: Int 21 Damage...............: None. Damage trigger.......: Whenever a file is opened. Standard means.......: Lots of programs such as Turbo Pascal use this area And the virus may be erased... Acknowledgment: Location.............: The Weizmann Institute Of Science, Rehovot, Israel Documented by........: Yuval Tal (NYYUVAL@WEIZMANN.BITNET). Date.................: 25-October-1989 - ------------------------------------------------------------------------------- - -Yvual Tal ------------------------------ Date: Tue, 24 Oct 89 17:45:48 -0400 From: Arthur Gutowski Subject: You're not alone; DataCrime infection report (PC) >From Virus-L Digest v2.220, frisk writes: > Well - now I know of one victim of the Datacrime-II virus ..... > myself. :-( Well, you shouldn't feel alone. A friend of mine who works for ERIM (Environmental Research Institute of Michigan) got hit too. His quotes sounded something like this (before being hit): "Oh, I'm not worried, I don't do much software trading, and what I do is straight from BBSs and buying from vendors." That was until he turned on a computer at work on Saturday 10/14. He had recently DLed a copy of PKZ102.EXE (PKZIP v1.02, self-extracting) from CompuServe and decided to try it out. Although I can't be sure that this was the source of the infection, eh told me it was the first time he had had a chance to run the program (hence, strong implication). Then it was showtime. Bye bye hard drive, low level format (F6) to cylinder 0. Effectively wiped out all access to the hard drive. Even a large chunk of the 2d copy of the FAT was duly destroyed because of this. He admitted to me that rebuilding a FAT, even with Mr. Norton's help, is not much fun. Needless to say, he has grudgingly accepted from me a disk containing several acrhives of antiviral tools to help him along in the battle. This disk is soon to be out in our Consulting center and student labs. Hopefully we can make enough people aware of things like this before more have to pay the awful price. Thankfully, it's already happening... One final note, I'm not POSITIVE it was DC that hit him, it may have been some variant. He is currently trying to see if he can get the infected program to me so I can look at it using info I've gained from watching here. Two strane things that made me question my assumption: 1) No "DATACRIME" message was thrown up on the screen that he remembers; 2) A name, Siegmar Schmidt, was written to the partition record. Now again, it DID format cyl0 and only cyl0...can anyone say for sure? Please e-mail me to the bitnet address above, 'twould be much appreciated. It CAN happen to anyone! Art +------------------------------------------------------------------+ | Arthur J. Gutowski, Student Assistant | | Antiviral Group / Tech Support / WSU University Computing Center | | 5925 Woodward; Detroit MI 48202; PH#: (313) 577-0718 | | Bitnet: AGUTOWS@WAYNEST1 Internet: AGUTOWS@WAYNEST1.BITNET | +==================================================================+ | "OOPS, what OOPS?!?...No, I diSTINCTly heard you say 'OOPS'!" | +------------------------------------------------------------------+ ------------------------------ Date: Tue, 24 Oct 89 19:34:21 -0400 From: flanders@grebyn.com (Dennis Flanders) Subject: possible virus infection (PC) I am a new user on VIRUS-L. I am a communication engineer on the FTS2000 project at Boeing Computer Services and we run a large client/server data network. It now serves over 800 PC's, Sun Workstations and is served by several host machines from mainframes to micros. I said all that to say this: In the process of "de lousing" our network for Columbus day and Friday the 13th, using a program called VScan, we discovered seven programs that showed as possible infected programs or carrier programs. In disassembling them only one proved to be dangerous. The others contained code sequences to totally lock the keyboard and triggered warnings. It may have had the infection passed on by another virus as the first three bytes in the .com file were 909090h. The following bytes (I believe 19) simply blitzed track 0. The infected file was a brief program (217 bytes) called KEYLOCK.COM which comes with a set of utilities distributed by PC Magazine. We could find no infected distribution disks. Only versions found on two PCs were found to contain this bomb. Curiously enough a couple of programs (ie NORTON.COM) popped a warning due to 1Fh found in the Seconds field of the directory. We also found several programs with a value >60 (ie 62) in the same location. All but one turned out to be harmless, we are still looking at the one. +-------------------------------------------------+----------------------+ |Dennis M. Flanders | | |AT&T Mail: !DFLANDERS | If at first you | |MCI Mail: DFLANDERS | don't succeed get | |INTERNET: flanders@grebyn.com | a bigger hammer! | |CompuServe: 73507,1771 | | +-------------------------------------------------+----------------------+ ------------------------------ Date: Tue, 24 Oct 89 14:56:02 -0400 From: rjs@moss.ATT.COM (Robert Snyder) Subject: Re: 0 bytes in 1 hidden file, virus? (PC) In volume 2 issue 217 of the virus list, Tasos notes that CHKDSK report "0 bytes in 1 hidden files" and wonders if he has a virus. This seems to come up fairly often when new people join the list so maybe an automatic answer is needed. In any case, Tasos probably ran CHKDSK on a disk with a volume label as that will exhibit his symptoms. I.e. it's not likely that Tasos has a virus. Robert Snyder {att|clyde}!moss!rjs rjs@moss.ATT.COM (201) 386-4467 The above statements are my own thoughts and observations and are not intended to represent my employer's position on the subject(s). ------------------------------ Date: 25 Oct 89 03:02:34 +0000 From: jap2_ss@uhura.cc.rochester.edu (The Mad Mathematician) Subject: The not-so-new virus (Mac) I am the one who first posted about the possibly new virus. I will give all the information I have here. I believe I hae finally gotten some infected software. There was a great deal of confusion at first as what exactly was happening. I was a consultant once, and as such am called upon to assist the present consultants with tasks they are new at. We had been having a problem with disks crashing at an alarming rate, all showing identical symptoms. They are these: The Chooser becomes unable to find any printer resources. The System and most system software gets writeen to, in an as yet unknown manner. Their sizes may or may not change. Other applications are written to, and documents created with them become unreadable. The Desktop gets damaged, causing the message "This disk needs minor repairs. Do you want to fix it?" to come up on bootup. By this stage the only recourse is to copy documents off with something like Deskzap and reformat the disk, replacing all the software. If the disk is repaired, it actually may seem that way, but ususally is ruined, even to the point of unusability. No virus detection programs identify a virus, except perhaps SAM Anti Virus Clinic, and even that doesn't always work. It _may_ be a NVIR variant that is self-modifying, but it does not create the nVIR resource. It does go through Vaccine, but Gatekeeper stops it cold. The reported STR 801 resource was an error by me. Please ignore this. There appeared to be a second virus also running around for a while. The sysmptoms were: Macwrite had its name changed to Macwite or Macwight. The ICN resource for the application was changed to show Macwite instead of the parallel lines. That's all we could find. We have found no other examples since the first three or four disks. I am of the opinion that someone modified one copy using something like Resedit, then shared it. That is all the information I can recall at this time. As I said, I believe I have found an infected disk, and will be sending copies of an infected application at the earliest opportunity, hopefully tommorrow. Thank you for your patience. Joseph Poutre (The Mad Mathematician) jap2_ss@uhura.cc.rochester.edu Understand the power of a single action. (R.E.M.) ------------------------------ Date: Tue, 24 Oct 89 23:28:15 -0400 From: dmg@lid.mitre.org (David Gursky) Subject: Re: VIRUSCAN test (IBM PC) In VIRUS-L Digest V2 #221, Charles Preston wrote a rather long message about virus scanners vs. more automated virus detection applications. I would like to point out to him that although there are some excellent scanning applications on the market, for Macs, PCs, etc., I prefer recommending that users do not rely on scanners simply because you must remember to periodically scan the disk. My experience has been that users simple do not remember to do this, hence a strategy that relied solely on a scanner application would not be a strong defense against electronic vandalism. David Gursky Member of the Technical Staff Special Projects Department, W-143 The MITRE Corporation ------------------------------ Date: Tue, 24 Oct 89 23:48:11 -0500 From: shaynes@lynx.northeastern.edu Subject: Jerusalem Virus Version B detected (PC) After running Scan 1.1V45 on my hard drive I detected the Jerusalem Virus Version B on one of my files. The file that I detected the virus on had not appeared in earlier runs of Scan. The infected file is UNVIRUS.EXE. The archive I got it out of was UNVIRUS.ARC. I downloaded this file from the SIMTEL20 PD archives. I immediately deleted the file. I have never had a reason to the program (and I would think that running the program on itself would have adverse affects). [Ed. Could someone at SIMTEL20 please check into this and confirm or deny it? Thanks!] +-----------------------------------------------------------------------------+ | PA_HAYNES@VAXE.COE.NORTHEASTERN.EDU | Sean A. Haynes |Student Northeastern | | SHAYNES@LYNX.NORTHEASTERN.EDU | 46 Udine St. |University, Boston | | PA_HAYNES@NUHUB.BITNET | Arlington, MA |MA 02115 | | | (617) 648-8390 |(617) 437-5422 | +-----------------------------------------------------------------------------+ ------------------------------ End of VIRUS-L Digest ********************* 30-Oct-89 12:33:28-GMT,22414;000000000001 Received: from RUTVM1.RUTGERS.EDU by topaz.rutgers.edu (5.59/SMI4.0/RU1.1/3.04) id AA29976; Mon, 30 Oct 89 07:33:19 EST Message-Id: <8910301233.AA29976@topaz.rutgers.edu> Received: from RUTVM1.RUTGERS.EDU by RutVM1.Rutgers.Edu (IBM VM SMTP R1.2.1MX) with BSMTP id 1842; Mon, 30 Oct 89 08:31:51 EDT Received: from RUTVM1 by RUTVM1.RUTGERS.EDU (Mailer R2.04RU) with BSMTP id 1839; Mon, 30 Oct 89 08:31:42 EDT Date: Mon, 30 Oct 89 07:24:02 EST Reply-To: VIRUS-L@ibm1.cc.lehigh.edu Sender: Virus Discussion List From: "The Moderator Kenneth R. van Wyk" Subject: VIRUS-L Digest V2 #226 Comments: To: VIRUS-L@ibm1.cc.lehigh.edu To: Multiple recipients of list VIRUS-L VIRUS-L Digest Monday, 30 Oct 1989 Volume 2 : Issue 226 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: Virus scanning on PCs? Re: Protection in Operating Systems How to Become a Virus Expert (Mac) Re: Lode [sic] Runner Virus (Apple) Where are the Sophisticated Viruses? 2608- possible virus? (AMIGA) BOOTCHEK (possible virus) (PC) Defensive computing... Re: Obj - anti-virus (PC) MacDraw II 1.1/GateKeeper 1.1 problems (Mac) Self-checking programs (PC anti-virus protection) --------------------------------------------------------------------------- Date: 26 Oct 89 16:07:15 +0000 From: davidsen@crdos1.crd.ge.com (Wm E Davidsen Jr) Subject: Virus scanning on PCs? Do scanning programs (in particular scanv45) check video memory for a virus? I once developed a program which installed itself in the 2nd page of video memory because there was nowhere else for it. Not a virus, just a fix for some BIOS bugs, but someone else could hide a virus there if they were so inclined. Very little software ever uses any page but the first. Oh, if the video pages were swapped and then output to the serial port was done, the display was really pretty! - -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "The world is filled with fools. They blindly follow their so-called 'reason' in the face of the church and common sense. Any fool can see that the world is flat!" - anon ------------------------------ Date: 26 Oct 89 16:03:14 +0000 From: davidsen@crdos1.crd.ge.com (Wm E Davidsen Jr) Subject: Re: Protection in Operating Systems In article <0001.8910231129.AA06880@ge.sei.cmu.edu>, WHMurray@DOCKMASTER.ARPA w rites: | However, as it relates to viruses, the big difference between them | today is the number and nature of uses and users. If UNIX were being | used for the same things and by the same number of users as DOS, it | would be just as vulnerable. I don't see how that relates to the technical issues. DOS allows any program to write anywhere in memory, including over the o/s. UNIX does not. DOS allows any program to write directly on the hard disk. UNIX does not. DOS allows any program to write to a floppy disk. UNIX may or may not, but in general UNIX seldom uses floppies at all, and when it does the formats are usually not susceptable to changing one file without changing others (ie. tar, cpio). DOS allows any program to modify any file on any disk. UNIX does not. This is not a case of one being "better" than another, just a case of inherent characteristics of the systems. Yes, if someone is running UNIX on an 8088 machine many of the protections are bypassed. - -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "The world is filled with fools. They blindly follow their so-called 'reason' in the face of the church and common sense. Any fool can see that the world is flat!" - anon ------------------------------ Date: Fri, 27 Oct 89 15:48:39 -0500 From: Joe McMahon Subject: How to Become a Virus Expert (Mac) 1) Read this digest. There are probably more contributors here than in any other spot around. 2) Study Inside Macintosh, particularly the sections on ROM patches, INITs, and VBL tasks. These are the principle attack vectors for Mac viruses. 3) Become adept at using TMON, Macsbug, or some other disassembler/ debugger. This will help you track down what is happening during a given infection. I don't know of anything equivalent to the "microscope and tweezers" report on the Internet worm for any Mac virus, so I can't refer you to any articles which talk about the mechanics of any virus in great detail. The only one which might be of use to you is an article in MacTutor magazine (last year? check the MacTutor anthologies) which has a description of an nVIR infection and a primitive but useful removal program. --- Joe M. ------------------------------ Date: Fri, 27 Oct 89 14:59:56 -0700 From: nparker@cie.uoregon.edu Subject: Re: Lode [sic] Runner Virus (Apple) In article <0010.8910231129.AA06880@ge.sei.cmu.edu>, davidbrierley@lynx.northeastern.edu posted an article about the Apple IIGS LOAD RUNNER virus, and asked the following questions: > [...] (1) Does any reader of VIRUS-L >know if the French expression "non-destructeur" means >"non-destructive" or "indestructible?" (2)Could anyone post a >version of VIRUS.KILLER (source code follows the report) written >in BASIC? (It could be posted here or to Info-apple@brl.mil) >(3) Because the university does not import VIRUS ALERT I >have not posted this report to it, for fear of replication. Could >someone post this message to VIRUS ALERT if it has not appeared there >already? Way back in July, I found this beasty lurking on some of my disks, and did a fairly thorough analysis of it, which culminated in the writing of the program which appeared at the end of the original article (copies of the program are available from me at the addresses below). I think I can provide some answers and information. I speak no French, but I think I can say after looking at the virus code that whatever "non-destructeur" really means, it OUGHT to mean "non-destructive." The damage done by this virus is minimal--it destroys only the boot blocks of a 3.5" disk (5.25" disks and hard disks seem to be immune), leaving all the files and directories intact (it can, however, render some copy-protected games unusable). My impression is that the author of the virus was thinking something like "I'm going to release this virus, which is a really bad thing to do, but it will be all right if it doesn't do any real damage." This impression seems to be reinforced by the fact that LOAD RUNNER has a finite life-span built in-- at the same time it starts damaging, it also stops propagating, and being a boot block virus, it destroys copies of itself when it destroys the boot blocks. Posting a BASIC version of VIRUS.KILLER isn't really practical--the steps that it takes to eliminate LOAD RUNNER are pretty much beyond the capabilities of poor old Applesoft BASIC. Any BASIC program would probably be just a short menu routine wrapped around a machine-language core which would be essentially the same as the current program. It's probably a bit late for a VIRUS ALERT message. I first saw LOAD RUNNER back in July (at which point it had probably already been around for a while), and if memory serves, the article quoted in the original posting was first posted sometime around August or September. Besides, LOAD RUNNER's trigger dates are any time between Oct. 1 and Dec. 31 inclusive, so any infected users have probably aready seen it run its course, and an alert now would be somewhat akin to locking the proverbial barn door after the horse has escaped. - ------------------------- A summary of LOAD RUNNER: Entry................: LOAD RUNNER Alias(es)............: (none) Virus detection when.: July, 1989 where.: Various places in the US and Canada Classifications......: Boot block virus Length of virus......: 1024 bytes (all of blocks 0 and 1) Operating system(s)..: ProDOS 8, ProDOS 16, GS/OS Version/release......: all Computer model(s)....: Apple IIGS Identification.......: Boot blocks are changed. System: Virus copies itself to $E1/BC00 thru $E1/BFFF. Type of infection....: Virus resides in the boot blocks of a 3.5" disk. Copies itself to $E1/BC00 when disk is booted. Copies itself to disk in slot 5, drive 1 when CONTROL-APPLE-RESET is pressed. Propagation routine gains control by patching undocumented system vector in Memory Manager. Original boot blocks are not saved--virus contains code to emulate standard boot process. Infection trigger....: Infects disks in slot 5, drive 1 only. Infection of disks occurs when CONTROL-APPLE-RESET is pressed. Infection of host machine occurs when an infected disk is booted. Interrupts hooked....: n/a Damage...............: Erases boot blocks of disk in slot 5, drive 1. No files are damaged. Damage trigger.......: Any date between Oct. 1 and Dec. 31 inclusive, of any year. Damage occurs when an infected disk is booted. If damage occurs, further infection will not occur. (Note that the damage process wipes the virus off of the infected disk.) Acknowledgment: Location.............: University of Oregon Documented by........: Neil Parker (nparker@cie.uoregon.edu) Date.................: 27-October-1989 Personal opinion: A rather wimpy virus. Damage is minimal and easily repaired. The virus code uses no special tricks, except for the method used to survive and gain control after RESET. All in all, it's not worth making much of a fuss about (except to the extent that ALL viruses are worth making a fuss about). (This is my first posting to comp.virus/VIRUS-L. Did I get the report format right?) Neil Parker nparker@cie.uoregon.edu parker@astro.uoregon.edu DISCLAIMER: Opinions are mine alone. ------------------------------ Date: Sat, 28 Oct 89 01:46:00 -0400 From: TMPLee@DOCKMASTER.ARPA Subject: Where are the Sophisticated Viruses? For various reasons I have been behind in my reading of Virus-L, and so I found myself skimming something like the last dozen issues of the digest all at once. I was struck by something: are we lucky and there are no competent, sophisticated writers of viruses out there, or are we just fooling ourselves? Although the details of most of the virus prevention programs (e.g., Gatekeeper for the Mac) haven't been discussed at all or recently enough that I remember them, it seems to me that any virus writer willing to get his hands dirty and write code that directly uses the I/O hardware (rather than rely on the operating system) should be able to write a virus that could not be detected by any of the preventative defenses that are supposed to be watching for suspicious writes and that would only be detected after-the-fact by reactive defenses that did a lot of robust integrity checksumming. (Looking for file modification dates would be useless since the virus would of course not be polite enough to update any directories; scanning programs would be useless on the assumption that the virus remains undetected until it goes off so no-one would have included a signature to scan for.) Suppose some suitably motivated person wrote such a virus and set the trigger for a year or two away (provided the virus had been executed and/or propagated some number of times) -- how far within the IBM-PC or Mac community would it likely spread before the trigger fired? How do we know one or more such beasts isn't already out there, just biding its time? ------------------------------ Date: 29 Oct 89 00:16:58 +0000 From: n8735053@unicorn.wwu.edu (Iain Davidson) Subject: 2608- possible virus? (AMIGA) In article <0007.8910261143.AA02119@ge.sei.cmu.edu> okay@tafs.mitre.org (Okay S J) writes: >I received this from Amiga-relay this morning....From all reports, it >appears that Xeno, if it is a virus, is the 1st non-boot infector virus >in the Amiga community. All the others I've seen so far live in the boot >sector and most Amiga anti-virals seem to only worry about the boot sector >and in RAM at the time. >I'll cross-post anything I hear from either side to their respective >lists. > >Stephen Okay Technical Aide, The MITRE Corporation >x6737 OKAY@TAFS.MITRE.ORG/m20836@mwvm.mitre.org [Text deleted] Well, while up in Vancouver, BC at an Amiga Users Group meeting, a interesting thing was demostrated..... I call it the "2608" virus. (don't know the offical name). It worked like the IRQ virus attaching itself to the first executable in the startup-sequence. But with a slight twist. It would copy the found executable to devs:" " and copy itself into the old name in the "C" directory (size 2608 bytes). The way that it was noticed was that the person had typed "echo blah blah" in his startup-sequence, but in "C" directory he had "echo" called "Echo" . One day he had noticed that the command was in all lowercase and 2608 bytes long (not the usual 653? bytes long). He also noticed that he had a extra file " " in the devs: directory the same size as the echo command. Evidently, the virus copyed itself to the command location, then copied the command to the devs: directory. Everytime the command was executed it would call the virus-program which in turn would call the REAL command. Appearing as though all worked fine. Another interesting thing.... about every 5 times he warm-boot, a message would come up saying something like "Virus Exterminator.. blah blah.... Virus by Blah Blah (i don't remember the specifics)" this only appeared for a brief second ... not long enough to read the whole thing. Anybody else have any info on this ? - -Iain Davidson IAIN@wwu.edu n8735053@unicorn.wwu.edu uw-beaver!wwu.edu!IAIN ------------------------------ Date: Sun, 29 Oct 89 00:19:00 -0500 From: PERRY@northeastern.edu Subject: BOOTCHEK (possible virus) (PC) HI! This list provides a service of great benefit to many many computer users! Congratulations. I recently downloaded BootChek 1.0 from Simtel20. With increasing frequency it has been saying my boot sector has been modified. I have allowed it to replace the "corrupt" boot sector on each of these occaisions. The complaint only happens on cold boots and not everytime the machine is cold booted. BootCHek lists the offset at which the sector starts to be different as 11 (on other occaisions 17, and most recently as 6.) The most recent time this symptom occured was after three reboots (each of which set off bootchek) Viruscanv42 shows no viruses on my 10 meg hard disk. I also run flushot plus ver 1.5 and UNVIRUS6 from Simtel20. These are running on my 4.77mhz IBM PC Clone with a DTK BIOS. I am concerned that BootChek has a bug, a virus, or both. Would someone please respond ASAP with any thoughts or info on my concerns! Jeffrey Perry Northeastern University PC Users Group PS. I have the corrupt.hex file produced by each of the five times bootchek claimed my boot sector had been changed. If anyone wants to analyze them I would be glad to send them along. PSS. I have backed up my Hard Disk so I am ready for just about anything BUT I hope it is merely a bug in bootchek!!! ------------------------------ Date: Sun, 29 Oct 89 09:33:05 -0500 From: dmg@lid.mitre.org (David Gursky) Subject: Defensive computing... Just a "friendly reminder" to the readers of Virus-L (and apologies to those who get both RISKS and Virus-L, and saw this note in RISKS some weeks ago). There are several key dates that electronic vandals like to strike on: Any Friday the 13th, April Fool's Day, and Halloween. The latter is Tuesday, and it would be exceedingly prudent (not to mention cheap insurance) for people to back up their disks in the event they are infected with a virus, or are unwittingly using a Trojan Horse, equipped with a time-bomb set for Halloween. A backup will not prevent the time-bomb from going off, nor will it remove the virus or Trojan Horse from your system, but it will be invaluable in recovering any data you may loose. ------------------------------ Date: 29 Oct 89 19:56:08 +0000 From: kerchen@iris.ucdavis.edu (Paul Kerchen) Subject: Re: Obj - anti-virus (PC) In article <0003.8910271112.AA11335@ge.sei.cmu.edu> s0703pdb@semassu.bitnet (Pa ul Bienvenue) writes: > [stuff about distributing OBJ files as anti-viral technique] > > It's a nice idea, but it wouldn't really stop virus writers, just >make life a little more difficult for them. That's the whole point: to make life more difficult for virus writers. The whole virus problem is NP complete, meaning that there is no way to ever completely solve it. For every protection scheme, there is a way to break it; just look at the copy protection war that has been going on for years now. Anyone who's in the virus business (either attacking or defending) had better know that they can never hope to create a virus/vaccine which is completely bulletproof. There will always be someone on the other side who will figure out a scheme to counter that virus/vaccine. Therefore, no solution should ever be ruled out simply on the basis that it cannot stop virus writers (I know that this isn`t the only reason Paul gave, but I just wanted to make this point). Stopping virus writers isn`t going to happen in software or hardware, but in societal pressure. (Perhaps some future first lady will make that her project: viruses--just say no. :-) ) Paul Kerchen | kerchen@iris.ucdavis.edu ------------------------------ Date: Sun, 29 Oct 89 15:14:00 -0500 From: HONORS@kuhub.cc.ukans.edu Subject: MacDraw II 1.1/GateKeeper 1.1 problems (Mac) Question: Does GateKeeper 1.1 have problems with MacDraw 1.1? Our installation has version 1.1 running on a machine protected with GateKeeper. Whenever we try to save a previously opened document, we get a dialog box saying "File not Found". SOMETHING is saved, because the changes are there when we open the document; but MacDraw does not recognize this. I've pretty much narrowed the trouble down to either GateKeeper or a virus in MacDraw II, because when I use the override feature on GateKeeper, MacDraw works fine. But even when I give MacDraw II 1.1 full privliges, (Res/File on Other, System, and Self) it still gives the File Not Found dialog box. Has anyone else had this problem? Travis Butler at HONORS@kuhub.cc.ukans.edu ------------------------------ Date: Sun, 29 Oct 89 21:13:00 -0500 From: JHSangster@DOCKMASTER.ARPA Subject: Self-checking programs (PC anti-virus protection) Bob McCabe of the University of Guelph wrote (27 Oct) "it struck me that it should be possible to work out a scheme by which any program could check itself at load time for infection..." This is quite true, and in fact there is at least one commercial anti-virus product out there which implements this idea. (There may well be others.) The one I have noticed is VACCINATE PLUS, by Computer Integrity Corp. of Boulder Colorado. Along with several other anti-viral tools, this product includes an "INSTALL" utility which "vaccinates" the boot track and all executables on the disk. "Vaccination" consists of appending a cryptographic "seal" checking module (smaller than a typical virus!) and patching the load module header so that this module executes first, then passes control to the original application program if the program is "clean", otherwise halting and issuing a warning message. According to Larry Martin of Computer Integrity Corp., the resulting protection is entirely transparent to the end user, i.e. no keystrokes are required, you just run a program in the normal way, and it runs normally unless the file has been infected, in which case it issues the warning and returns control to DOS. Computer Integrity Corp. can be reached by phone at (303) 449-7377 (FAX number is 449-7477). Their address is PO Box 17721, Boulder CO 80308. (I have no commercial connection with this company.) Regarding the specific scheme Bob McCabe described, i.e. computing a CRC on a program and then encrypting it, it is fairly well known that since the CRC process is linear over the binary field (commonly called "GF(2)" by algebraists), it is little more than a high school algebra exercise to make your desired changes to the program, then make a few more bits' worth of additional changes (determined by simple linear algebra over GF(2)) which restore the CRC bits to their former value so that they will still perfectly match the bits recovered from the encrypted CRC -- thus defeating the protection scheme. The only trick, in an executable program, is to set up the code so that the additional bits you have to diddle to restore the CRC do not adversely affect execution, e.g. include a branch around them or whatever suits your fancy. The basic idea is OK, but you need to use a "one-way" hash function, rather than something readily invertible like a linear CRC. See Dorothy Denning's book or any of a number of recent articles for ideas on better hash functions, or use one of the "chained" modes of the DES which have been proposed for detecting data alterations. The key (so to speak) property that is needed is that it must be difficult to construct a second message or in this case computer program with the same value for the hashing function's output. - -John Sangster SPHINX Technologies, Incorporated (617) 235-8801 P.O. Box 81287 Wellesley Hills, MA 02181 ------------------------------ End of VIRUS-L Digest ********************* 31-Oct-89 12:54:04-GMT,13321;000000000001 Received: from RUTVM1.RUTGERS.EDU by topaz.rutgers.edu (5.59/SMI4.0/RU1.1/3.04) id AA18653; Tue, 31 Oct 89 07:52:17 EST Message-Id: <8910311252.AA18653@topaz.rutgers.edu> Received: from RUTVM1.RUTGERS.EDU by RutVM1.Rutgers.Edu (IBM VM SMTP R1.2.1MX) with BSMTP id 6144; Tue, 31 Oct 89 07:43:14 EDT Received: from RUTVM1 by RUTVM1.RUTGERS.EDU (Mailer R2.04RU) with BSMTP id 6139; Tue, 31 Oct 89 07:24:07 EDT Date: Tue, 31 Oct 89 07:17:18 EST Reply-To: VIRUS-L@ibm1.cc.lehigh.edu Sender: Virus Discussion List From: "The Moderator Kenneth R. van Wyk" Subject: VIRUS-L Digest V2 #227 Comments: To: VIRUS-L@ibm1.cc.lehigh.edu To: Multiple recipients of list VIRUS-L VIRUS-L Digest Tuesday, 31 Oct 1989 Volume 2 : Issue 227 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: Virus scanners Re: Virus source available in Toronto RE: BootChek (possible virus) (PC) Re: MacDraw II 1.1/GateKeeper 1.1 problems (Mac) Re: Another suggestion for preventing viral spread (PC) stoned removal? (PC) Re: Macintoch MacWrite, STR 801 (Mac) Free catalog disk update Yale/Alameda & Stoned Viruses (PC) --------------------------------------------------------------------------- Date: Mon, 30 Oct 89 16:32:39 +0000 From: yale!slb-sdr!sdr.slb!shulman@uunet.UU.NET (Jeff Shulman) Subject: Re: Virus scanners portal!cup.portal.com!cpreston@Sun.COM writes: >My point about "How good are scanning programs" is mainly that if the >program uses well-chosen search strings it can be more effective than >I, at least, initially expected. Several scanning programs for the >Macintosh relied only on resource names (resources include program >code on the Mac). These resource names, such as nVIR, are very easily >and quickly changed to hPat or anything else, completely defeating the >scanning program. >Charles M. Preston MCI Mail 214-1369 >Information Integrity BIX cpreston >Box 240027 907-344-5164 >Anchorage, AK 99524 Very true. Which is why the scanning strings in VirusDetective(TM) are (1) resource type/ID independent (for all the Mac viruses) and (2) *user* configurable [but the GIGO rule applies: Use invalid search strings and you will get invalid results]. Plug: VirusBlockade(TM) II Ltd. has just been released by me (along with VD 3.1) which, among other things, allows you to scan floppies in background (when used with VD 3.1) when they are inserted WITHOUT having to have VD open. [VB II Ltd. is a DEMO of VB II which does everything except save any configuration changes to disk] Jeff Shulman VirusDetective & VirusBlockade author - -- uucp: ...rutgers!yale!slb-sdr!shulman CSNet: SHULMAN@SDR.SLB.COM Delphi: JEFFS GEnie: KILROY CIS: 76136,667 AppleLink: KILROY ------------------------------ Date: 30 Oct 89 17:04:03 +0000 From: kelly@uts.amdahl.com (Kelly Goen) Subject: Re: Virus source available in Toronto Yes it is indeed true that viral sources are published in several areas... however "Viruses , A high Tech disease" published only overwriting viruses!! more similar to a logic bomb as when they infect the target executable the file is immediately destroyed(VERY EASY to detect) by the overwriting process. However any COMPETANT Assembly coder can manufacture far more unobtrusive viruses if he just thinks about it!! the published sources working or non working are really not that much of a threat... cheers from the front lines!! kelly/silly CON Valley!! ------------------------------ Date: Mon, 30 Oct 89 10:15:39 -0500 From: Arthur Gutowski Subject: RE: BootChek (possible virus) (PC) In Virus-L Digest v2, i226, Jeffrey Perry expressed some concern about his copy of BootChek that he is running. I sent him a note asking him to send me the copy of the program he is running now, the corrupt.hex files, and the copy of the boot sector generated by BootChek. Since ViruScan and other products have failed to find anything, I doubt it is a virus that infected him (although it is possible a new nasty has surfaced :-( ... Thus my interest in the corrupted boot sector files). I can only make the assumption for the time being that the program is bugged. I am looking into the matter, and if in fact there is a bug in the program, a version update will be released with the fix and posted via Jim Wright's antiviral archives. I also asked him to take some measures in re-running the program in a (relatively) guaranteed clean environment. Hopefully, these tests will show that there isn't yet another new virus out there. I will post an update when more info is available. Arthur Gutowski, Co-author of BootChek +--------------------------------------------------------------------+ | Arthur J. Gutowski, Student Assistant | | Antiviral Group / Tech Support / WSU University Computing Center | | 5925 Woodward; Detroit MI 48202; PH#: (313) 577-0718 | | Bitnet: AGUTOWS@WAYNEST1 Internet: AGUTOWS@WAYNEST1.BITNET | +====================================================================+ | Rules to live by, #153: | | Never get caught on the wrong side of a Doppler shift. | +--------------------------------------------------------------------+ ------------------------------ Date: 30 Oct 89 17:04:46 +0000 From: ut-emx!chrisj@cs.utexas.edu (Chris Johnson) Subject: Re: MacDraw II 1.1/GateKeeper 1.1 problems (Mac) In article <0010.8910301224.AA05511@ge.sei.cmu.edu> HONORS@kuhub.cc.ukans.edu w rites: >Question: Does GateKeeper 1.1 have problems with MacDraw 1.1? Our (stuff deleted) > Travis Butler at HONORS@kuhub.cc.ukans.edu The answer is that GateKeeper 1.1 is making the problem apparent - it's not at all clear whether the problem is a very obscure bug in GateKeeper (and it would have to be obscure since so few pieces of software demonstrate this problem) or a bug in MacDraw. I've been working with Ken Walters at Claris for some time now, and we haven't reached any useful conclusions as yet. There are other packages that demonstrate related problems. They include MacWrite 1.x and Claris CAD, and a few programs from other vendors, as well. The solution (after a fashion) is to use version 1.1.1 of GateKeeper. Although the problem remains, 1.1.1 can be warned about programs that suffer from the problem. Thus warned, GateKeeper avoids the situations that give rise to the problem. There are a number of other good reasons to upgrade to 1.1.1, so consider the upgrade *highly* recommended. - ----Chris (Johnson) - ----chrisj@emx.utexas.edu - ----Author of Gatekeeper ------------------------------ Date: 30 Oct 89 17:37:56 +0000 From: kelly@uts.amdahl.com (Kelly Goen) Subject: Re: Another suggestion for preventing viral spread (PC) Sorry close but no cigar... OBJ files are even easier for a viral writer to manipulate... the format is EXTREMELY well document... how do I know??? simply I have written a few linkers!! its quite trivial to cause a OBJ type virus to repropagate!! I suggest if you are interested further check out the MS-DOS encyclopedia!! from microsoft press!! cheers kelly ------------------------------ Date: Mon, 30 Oct 89 13:18:15 -0500 From: howard@maccs.dcss.mcmaster.ca (Howard Betel) Subject: stoned removal? (PC) I have a friend that has recently been hit by the stoned virus. His question quite simply is whether there is anyway to eradicate the virus without having to do a low level format. After the low level, is there anything else he should be worried about? If no files are involved in your answer could you please mail him at: 39CJORDAN@SHERCOL1.BITNET or if there are files involved please respond to me so I can grab them for him. Thanks for any help you can give, I think he's almost around the bend. :-0 - -- Howard Betel Howard@maccs.dcss.McMaster.CA Dept of Computer Science ...!unet!utai!utgpu!maccs!howard McMaster University ------------------------------ Date: 30 Oct 89 22:29:42 +0000 From: ut-emx!chrisj@cs.utexas.edu (Chris Johnson) Subject: Re: Macintoch MacWrite, STR 801 (Mac) In article <0002.8910271112.AA11335@ge.sei.cmu.edu> JS05STAF%MIAMIU.BITNET@VMA. CC.CMU.EDU (Joe Simpson) writes: >I'm unclear about the STR 801 discussion. Let me tell a little story >to see if I can further confuse things. > >About 4 months ago a client reported that MacWrite was growing in file >size on a public Mac. I checked to see that VACCINE was turned on. >I ran Disinfectant 1.2. A clean machine. > >I then ran ResEdit to look at the MacWrite file. There were a large >number of STR 801 resources. The program was adding STR 801 resources >at some unknown interval. > >I replacedthe file with a fresh copy of MacWrite and the problem disappeared. > >I put it down to normal computer miseries and not a computer virus. You were right to assume that it was just normal "miseries". Ken Walters at Claris recently mentioned that they've received reports of this problem in the past with version 5.x of MacWrite (possibly earlier versions, too - I didn't get all the details on which versions). They don't worry about it, though, because they now put out MacWrite II which doesn't have this problem, so, as far as they're concerned, the bug is "fixed". :-) And, when you consider it, it would be a pretty simple mistake to make... all that's required is for someone to forget to do a UseResFile() at the right time (just before the AddResource() call is made), and the STR 801 could go into any of the currently open resource files, including MacWrite's own file. So, it doesn't sound like there's anything to be concerned about. - ----Chris (Johnson) - ----chrisj@emx.utexas.edu - ----Author of Gatekeeper ------------------------------ Date: Mon, 30 Oct 89 18:30:00 -0500 From: IA96000 Subject: Free catalog disk update Regarding the xxx catalog disk mentioned last week. here is an update. the three infected files were uploaded to homebase for evaluation by the experts there. one of the files cl.com was a hidden file and would not be seen just by doing a dir command. the company was contacted, (the phone was answered by a kid who yelled out, "hey daddy it's for you"),and the responsible party was informed that the disk received had three viruses on it. his reply, and i quote was "that is impossible, i wrote the all of the programs on the free catalog disk." he then proceeded to ask why he would include a virus. an attempt was made to explain that the infected programs were shareware used by batch files on the catalog disk. he was not at aLL INTERESTED IN HEARING ABOUT THE PROBLEM AND RATHER RUDELY SLAMMED THE PHONE DOWN, AFTER UTTERING A FEW CHOICE WORDS. TO REITERATE, THIS DISK WAS received in response to a "bingo card" request from the back of one of the major computer magazines. the ad offered a free disk containing a catalog of shareware and other software sold by the xxx company in hesperia, california. the disk label appears as follows: 1989 xxx catalog ********************** p.o. xxxx hesperia, ca 92345 may view or print catalog & orderform to start catalog . . . a>start the company name and post office box number have been replaced by x's to avoid any legal problems. on the disk there is the root directory and a subdirectory named \ord. in the root directory two files are infected. cl.com is the hidden file in the root which is infected. in the \ord directory a file is also infected. other than that i am at a loss. attempts to speak to the company have failed, so i guess it will take a complaint to the editor of the magazine where the ad appeared. ------------------------------ Date: Mon, 30 Oct 89 18:45:54 -0500 From: Tom Luthman Subject: Yale/Alameda & Stoned Viruses (PC) Here in the PC labs at UGA we've been having outbreaks of what Scanv45 calls the Yale/Alameda virus in the boot sector. What does this virus do and how dangerous is it? Also, one user found a "stoned" virus on his hard drive. Are there removal programs available for either or both of these? And how can we get 'em? Thanks... --- Tom Luthman (st9 @ uga) ------------------------------ End of VIRUS-L Digest ********************* 31-Oct-89 17:18:51-GMT,14415;000000000001 Received: from RUTVM1.RUTGERS.EDU by topaz.rutgers.edu (5.59/SMI4.0/RU1.1/3.04) id AA26426; Tue, 31 Oct 89 12:17:29 EST Message-Id: <8910311717.AA26426@topaz.rutgers.edu> Received: from RUTVM1.RUTGERS.EDU by RutVM1.Rutgers.Edu (IBM VM SMTP R1.2.1MX) with BSMTP id 7262; Tue, 31 Oct 89 12:11:24 EDT Received: from RUTVM1 by RUTVM1.RUTGERS.EDU (Mailer R2.04RU) with BSMTP id 7259; Tue, 31 Oct 89 12:04:49 EDT Date: Tue, 31 Oct 89 09:31:08 EST Reply-To: VIRUS-L@ibm1.cc.lehigh.edu Sender: Virus Discussion List From: "The Moderator Kenneth R. van Wyk" Subject: VIRUS-L Digest V2 #228 Comments: To: VIRUS-L@ibm1.cc.lehigh.edu To: Multiple recipients of list VIRUS-L VIRUS-L Digest Tuesday, 31 Oct 1989 Volume 2 : Issue 228 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: Fri 13 virus in Taiwan Checksum programs New Variant of WANK Worm (VAX/DECnet) [Ed. This VIRUS-L issue is going out early to get the WANK notice out in a reasonably timely manner.] --------------------------------------------------------------------------- Date: Tue, 31 Oct 89 08:02:54 -0500 From: Elliott Parker <3ZLUFUR%CMUVM.BITNET@VMA.CC.CMU.EDU> Subject: Fri 13 virus in Taiwan The following is from "The Free China Journal" (19 Oct 89): Head: Phantom Virus Unseen In ROC The "Friday the 13th" computer virus that was supposed to wipe out the world's IBM-compatible computer systems failed to materialize in Taiwan. Mitac, Inc., one of Taiwan's leading computer companies reportedly discovered some of its personal computers were infected by the virus, but a spokesman said the virus not the one called "Friday the 13th." No attack was reported in other computer companies, including Acer Inc., Eten Technology, Kuo Chiao, HP or Digital. Computer systems in local banks and securities firms worked well on Oct. 13. The post office in Taipei was thrown into panic when it was discovered none of its computers worked. But it was determined the breakdown was caused by the motor of a disk drive. - ------------------------------------------------------------------------ Elliott Parker BITNET: 3ZLUFUR@CMUVM Journalism Dept. Internet: eparker@well.sf.ca.us Central Michigan University Compuserve: 70701,520 Mt. Pleasant, MI 48859 BIX: eparker USA UUCP: {psuvax1}!cmuvm.bitnet!3zlufur ------------------------------ Date: Tue, 31 Oct 89 14:47:32 +0200 From: Y. Radai Subject: Checksum programs Bob McCabe writes: > While working out the algorithm for this check it struck me >that it should be possible to work out a scheme by which any >program could check itself at load time for infection. .... >Presently, I am working on a system of prime number coding in >which the CRC check of the EXE file is compared with a encoded >CRC. The coding of the CRC would be done with a large prime >number, chosen at random from a table. Fine, just be aware that dozens of people have done it before you. (There must be at least 30 such programs for the PC alone.) But I don't mean to discourage you; some such programs are much better than others. And if you can think of a better way of doing it, more power to you. In my opinion, the most important requirements on a checksum program are: (1) For any given file it must yield a different checksum on each com- puter. (2) Even if the checksum algorithm and checksum length are known, without knowledge of the key (the generating polynomial in the case of a CRC algorithm), it should be impossible to modify a file in such a way that the checksum remains unchanged. (3) It must be able to checksum the boot sector and partition record (in PC terminology) in addition to arbitrary files. (4) It should check file sizes as well as checksums. (5) It must be convenient to specify and update the list of files to be checksummed. (6) A naively written checksum program (and most of them are, unfortu- nately, of this type) will contain loopholes which a clever virus creator can exploit to introduce a virus despite the checksumming. The author of the checksum program must therefore try to think of every such loophole and plug it. (7) It must be reasonably fast. While almost every author concerns himself with (7), there are lots of programs (e.g. FSP) which do not satisfy most (or even any) of the other requirements. Btw, I'm curious to know what importance you attach to making the number prime. John Sangster comments on Bob's posting as follows: > it is fairly well known that >since the CRC process is linear over the binary field (commonly called >"GF(2)" by algebraists), it is little more than a high school algebra >exercise to make your desired changes to the program, then make a few >more bits' worth of additional changes (determined by simple linear >algebra over GF(2)) which restore the CRC bits to their former value so >that they will still perfectly match the bits recovered from the >encrypted CRC -- thus defeating the protection scheme. This is a common opinion, but is incorrect in the current context. You can restore the CRC to its former value *only if you know the ge- nerating polynomial*. But condition (1) above, when implemented with a CRC algorithm, is usually fulfilled by either selecting the genera- tor randomly when the checksum base is initially set up, or by letting the user select it personally. In this situation, the above tech- nique is useless. In the majority of cases, this technique would not work even if the generator were known, since the viral code will increase the size of the file (unless the virus is restricted to infecting particular files having unused space, as in the case of the Lehigh virus). Since a checksum program should also compare the *sizes* of the files (re- quirement (4) above), the change would be detected. Y. Radai Hebrew Univ. of Jerusalem, Israel RADAI1@HBUNOS.BITNET ------------------------------ Date: Tue, 31 Oct 89 08:56:00 -0500 From: TENCATI@NSSDCA.GSFC.NASA.GOV (SPAN SECURITY MGR. (301)286-5223) Subject: New Variant of WANK Worm (VAX/DECnet) ============================================================================ INTER-NETWORK MEMORANDUM SPAN MANAGEMENT OFFICE ============================================================================= 30-OCT-1989 TO: ALL SPAN SYSTEM MANAGERS FROM: SPAN MANAGEMENT OFFICE GODDARD SPACE FLIGHT CENTER CODE 630.2 GREENBELT, MD. 20771 (301)286-7251 SUBJ: SECURITY GUIDELINES TO BE FOLLOWED IN LATEST WORM ATTACK ---------- A variant of the 16-Oct worm has been restarted on the DECnet internet. This worm is a slightly modified copy of the original worm that infected the networks last week. The method of attack is identical to the last except that this version calls itself OILZ_nnnn instead of NETW_nnnn. This variant of the worm changes the password of the account it penetrates unlike its predecessor which only changed passwords if it penetrated a privileged account. The effect of this modification is that if the DECNET account is breached (Userid DECNET, Password DECNET), changing of the password will disable further *INBOUND* network connections to the node, effectively removing it from the network. THIS IS THE PRIMARY WAY IN WHICH THE CURRENT WORM IS ACHIEVING SUCCESS. The previous precautions and guidelines issued by this office are still applicable and valid. The following 5 procedures should be implemented on all DECnet nodes to ensure that the worm cannot gain access to your node. ---------- 1) The current worm has been modified to attack the default DECNET account first. It attempts to enter the default DECNET account with user=DECNET and password=DECNET. This is the default set up. IT MUST BE CHANGED. To change it, two things have to be done: $MCR AUTHORIZE UAF> mod DECNET /pass= !anything BUT "DECNET" UAF> mod DECNET /flag=lockpwd/nobatch/prclm=0 UAF> exit Then, to match default access control information in the executor (so MAIL and NML will still work): $MCR NCP NCP> set executor nonpriv pass !NOTE this MUST match what you set in AUTHORIZE! The above changes will not effect operation of your system, but will prevent the worm from entering via your default DECNET account. 2) DISABLE THE TASK OBJECT The TASK Object MUST be removed from your DECnet database. There are two methods by which you can accomplish this: 1. In SYSTARTUP.COM/SYSTARTUP_V5.COM, after the call to @SYS$MANAGER:STARTNET, insert the following line: $ MCR NCP CLEAR OBJECT TASK ALL THIS COMMAND MUST BE EXECUTED *EACH TIME* THE NETWORK IS STARTED OR RESTARTED. DOING IT AT BOOT-TIME ALONE IS NOT SUFFICIENT. 2. Instead of option 1, the following commands can be issued ONCE from a privileged account to permanently change the information in the DECnet database for the TASK object: $ MCR NCP SET OBJECT TASK PASSWORD $ MCR NCP DEF OBJECT TASK PASSWORD If for some reason you MUST have a TASK object, please call the SPAN network office at (301)286-7251. 3a) Protect SYS$SYSTEM:RIGHTSLIST.DAT so that it is has no protection bits set for the WORLD category of users. This is how the attacking worm determines who your valid users are. There is some discussion about this approach, it apparently works on 4.7 thru 5.1-1 systems, reports from systems testing this approach say it breaks under V5.2. So there are 2 other approaches, set an ACL on RIGHTSLIST.DAT disabling NETWORK access, or using a logical name to point to RIGHTSLIST. **NOTE** THE ACL APPROACH MAY REQUIRE A REBOOT TO PURGE THE OLD RIGHTSLIST.DAT ON V4.7 SYSTEMS. b) Place an ACL on RIGHTSLIST.DAT to prevent network access of your user names . For V5.X: SET ACL SYS$SYSTEM:RIGHTSLIST.DAT /ACL=(IDENTIFIER=NETWORK,ACCESS=NONE) Version 4.X systems have a more difficult time of it since the file locked by other images. The suggested way of protecting it is from the SYSTEM account to: SET DEFAULT SYS$SYSTEM: COPY RIGHTSLIST.DAT *.TEMP SET ACL RIGHTSLIST.TEMP /ACL=(IDENTIFIER=NETWORK, ACCESS=NONE) RENAME RIGHTSLIST.TEMP *.DAT On completion, make sure that the protection is correct (W:R). You should purge the file as soon as possible. However, you may not be able to purge until the system has either been rebooted or OPCOM has been stopped and restarted. c) The logical name approach relies on "hiding" RIGHTSLIST.DAT and defining a system wide logical name that points to it. Network access does not translate this logical name. $RENAME SYS$SYSTEM:RIGHTSLIST.DAT any_old_file_you_want.dat $DEFINE/SYSTEM/EXEC RIGHTSLIST any_old_file_you_want.dat As long as the logical symbol RIGHTSLIST points to the *real* file, it doesn't matter what you name it, or where it is. The worm EXPECTS it to be in SYS$SYSTEM:RIGHTSLIST.DAT. 4) If possible, verify that none of your users are using their username for their password. Chances are that if they were, you'd have a worm running on your node right now though. The SPAN office has a toolkit available which contains a program that can be used for this purpose. Contact NCF::NETMGR for details. 5) Place an ACL on the default BATCH QUEUE of Version 5.x systems. SET ACL SYS$BATCH/OBJECT=QUEUE /ACL=(IDENTIFIER=NETWORK, ACCESS=NONE) ACLS are not supported on batch queues in Version 4. It is suggested remote Batch be disable by inserting the following command as the first command in SYS$SYSTEM:NETSERVER.COM:, after the label LOOP: $ DEFINE SYS$BATCH NO_SUCH_QUEUE This will prevent the command from ever getting the correct queue. ---------- DEC also recommends that certain SYSGEN parameters be modified in order to thwart an attack technique the worm utilizes. The SPAN management supports these suggested modifications: $MCR SYSGEN USE CURRENT SET LGI_BRK_TERM 0 SET LGI_BRK_TMO 3600 SET LGI_HID_TIM 86400 WRITE ACTIVE WRITE CURRENT EXIT $ If you have been attacked by this worm, please send the node name/number that the attack came from and if possible, the username of the attacker. Send this information your local Routing Center Manager and to NCF::NETMGR on SPAN, 6277::NETMGR on HEPnet/Other nodes on the DECnet Internet. The SPAN Management office also has a new version of ANTI_WANK.COM which can be started in a node's batch queue to search-out and report/destroy worms which may be running on a node. For copies of this procedure, send mail to NCF::NETMGR. REMINDER - The NSI Networking Users Group (Formerly SPAN Data System Users Working Group - DSUWG) is meeting at Goddard Space Flight Center on NOV 13-15. All members of the SPAN community are invited to attend. For information, contact Valerie Thomas, SPAN Project Manager at (301) 286-4740, or send mail to NCF::THOMAS. ------------------------------ End of VIRUS-L Digest ********************* 1-Nov-89 13:15:56-GMT,14616;000000000001 Received: from RUTVM1.RUTGERS.EDU by topaz.rutgers.edu (5.59/SMI4.0/RU1.1/3.04) id AA08286; Wed, 1 Nov 89 08:14:22 EST Message-Id: <8911011314.AA08286@topaz.rutgers.edu> Received: from RUTVM1.RUTGERS.EDU by RutVM1.Rutgers.Edu (IBM VM SMTP R1.2.1MX) with BSMTP id 0175; Wed, 01 Nov 89 08:10:10 EDT Received: from RUTVM1 by RUTVM1.RUTGERS.EDU (Mailer R2.04RU) with BSMTP id 0172; Wed, 01 Nov 89 08:10:03 EDT Date: Wed, 1 Nov 89 07:55:53 EST Reply-To: VIRUS-L@ibm1.cc.lehigh.edu Sender: Virus Discussion List From: "The Moderator Kenneth R. van Wyk" Subject: VIRUS-L Digest V2 #229 Comments: To: VIRUS-L@ibm1.cc.lehigh.edu To: Multiple recipients of list VIRUS-L VIRUS-L Digest Wednesday, 1 Nov 1989 Volume 2 : Issue 229 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: Virus scanning on PCs? Re: Protection in Operating Systems re: Where are the Sophisticated Viruses? re: Self-checking programs (PC) Re: Virus source available in Toronto Re: Self-checking programs (PC) Supplemental Security Info on DECnet Worm (VAX/DECnet) Re: Checksum programs Re: Imbedded virus detection Re: Checksum programs --------------------------------------------------------------------------- Date: 31 Oct 89 00:00:00 +0000 From: "David.M..Chess" Subject: re: Virus scanning on PCs? > Do scanning programs (in particular scanv45) check video memory > for a virus? Once again, it's important to remember that a virus has to get itself -executed- somehow. That means altering some object that gets executed (typically EXE and COM files and boot sectors so far). Nothing that I know of will execute code found in video memory. So a virus, even if it did hide most of itself in the video memory, would have to change some executable object (COM or EXE file, boot record, etc) in order to get executed. So, if you can check your executable objects thoroughly enough, it's not necessary to check video memory as well. All the known viruses hide in EXE or COM files, or boot records, so those are the only things any scanner for known viruses has to check. (This is about the same answer I gave last week to the question about viruses "hiding" in sectors marked as bad.) DC ------------------------------ Date: 31 Oct 89 00:00:00 +0000 From: "David.M..Chess" Subject: Re: Protection in Operating Systems Bill Davidsen's point that DOS allows all sorts of things that UNIX(tm) doesn't is quite true. Remember, though, that viruses don't *have* to do any of those things (write over the o/s in memory, write directly to the hardware, etc) in order to spread. See Cohen's "Computer Viruses - Theory and Experiments" paper for some quite convincing numbers about viruses and UNIX. *Any* operating system that allows users to write programs and share information will be vulnerable to viruses. DC ------------------------------ Date: 31 Oct 89 00:00:00 +0000 From: "David.M..Chess" Subject: re: Where are the Sophisticated Viruses? You're forgetting one important kind of virus detector: a general modification-detector that does a check-code of some kind (CRC, MDC, or whatever), and alerts the user when a file's *contents* (not the date) change. There are enough people using such things (at least in the PC world; I don't know much about that Mac world) that I think even a virus that talked straight to the hardware to avoid "suspicious activity" detectors wouldn't get far before it was detected. DC ------------------------------ Date: 31 Oct 89 00:00:00 +0000 From: "David.M..Chess" Subject: re: Self-checking programs (PC anti-virus protection) > The basic idea is OK, but you need to use a "one-way" hash function, > rather than something readily invertible like a linear CRC. John Sangster is basically correct, but I'd like to suggest that it's possible to get the advantages of a CRC (faster and more exportable than the DES), and still avoid invertibility. The key (hehe) is that a CRC is easily invertible only if you know the polynomial used. If a modification-detector were to use a different CRC polynomial for each user (based, for instance, on a key phrase elicited from the user at each run), and the database of CRCs were kept from the virus (to avoid the virus being able to calculate the polynomial from file-CRC pairs), the theoretical invertibility of the CRC wouldn't matter, because a virus would not have all the information needed to make an undetected change. DC ------------------------------ Date: 31 Oct 89 00:00:00 +0000 From: "David.M..Chess" Subject: Re: Virus source available in Toronto > however "Viruses , A high Tech disease" published only > overwriting viruses!! Hm, maybe there are two versions of the book? The one I have contains an almost-complete disassembly of the 648 (aka Vienna, DOS-62, etc) virus on pages 156-164. This virus is a standard (very small) non-overwriting virus, that spreads between COM files, and leaves the function of the infected program intact. DC ------------------------------ Date: 31 Oct 89 12:54:19 +0000 From: leif@ambra.dk (Leif Andrew Rump) Subject: Re: Self-checking programs (PC anti-virus protection) JHSangster@DOCKMASTER.ARPA writes: > ... this product includes an "INSTALL" utility which >"vaccinates" the boot track and all executables on the disk. >"Vaccination" consists of appending a cryptographic "seal" checking >module (smaller than a typical virus!) and patching the load module ^^^^^^^^ >header so that this module executes first, then passes control to the >original application program if the program is "clean", otherwise >halting and issuing a warning message. If a virus killer can patch a program so can a virus! Exactly as virus detectors is able to find a virus by looking at the code so is the virus able to detect the virus killer and disable it! That's life!! Leif Andrew Rump, AmbraSoft A/S, Roejelskaer 15, DK-2840 Holte, Denmark UUCP: leif@ambra.dk, phone: +45 42424 111, touch phone: +45 42422 817+313 > > > Why are tall Irish girls with red hair so wonderful ? ? ? < < < ------------------------------ Date: Tue, 31 Oct 89 16:38:58 -0500 From: TENCATI@NSSDCA.GSFC.NASA.GOV (SPAN SECURITY MGR. (301)286-5223) Subject: Supplemental Security Info on DECnet Worm (VAX/DECnet) NETWORK SECURITY SUPPLEMENTAL INFORMATION - PROTECTING THE DECNET ACCOUNT The most important thing that needs to be done to protect a system against the current WORM attacks is to modify accounts where USERNAME=PASSWORD. This is the default configuration for the DECNET account. This can be changed easily, but there appears to be some confusion about the effect that this has on a network. Changing the DECnet default password DOES NOT IMPACT the normal operation of DECnet in any way. -------- The following section provides some background material to illustrate this point: On your system, issue the following commands from a priviliged (CMKRNL,BYPASS,SYSPRV) account: $MCR NCP (or $RUN SYS$SYSTEM:NCP) NCP> show executor characteristics This will produce a list that resembles the following: Node Volatile Characteristics as of 31-OCT-1989 11:02:23 Executor node = 6.133 (NSSDCA) Identification = DECnet-VAX V4.7, VMS V4.7 . . . Nonprivileged user id = DECNET Nonprivileged password = DECNET . . . This is your DECnet executor database. The information listed is the default configuration for your node. The information contained in this list includes "Nonprivileged user id" and "Nonpriviliged Password". This information is what DECnet uses for userid/password when the connecting process a)does not have a proxy, b)does not specify a username/password as part of the access string, and c)does not have a different userid/password defined for the network object being invoked. The access information contained in the executor database is used for reference only. The candidate userid and password (in this case DECNET and DECNET respectively) are then passed to LOGINOUT to validate them against the *REAL* information contained in SYSUAF.DAT. If the information matches, the access is allowed. If the information does not match, the connecting user gets the following error messages: Unable to connect to listner Login Information Invalid at Remote Node -------- In order to correctly change your default network password so that your system cannot be easily exploited by the current DECnet WORM, the following 2 steps must be followed: 1) Change the password for user DECNET in SYSUAF.DAT: UAF> modify DECNET/Password=NEW_DECNET_PASSWORD *NOTE* It is advisable at this time to check that certain other attributes of the DECNET user are properly set: The ONLY access method for this account should be NETWORK. The BATCH, REMOTE, INTERACTIVE, and DIALUP fields should all read "--no access--" The value of PRCLM should be set to ZERO. This is the number of (SPAWNed) sub-processes allowed. The flag LOCKPWD should be set. This prevents anyone but a priviliged user from changing the password. The following command can be used: UAF> MOD DECNET/FLAGS=LOCKPWD/PRCLM=0/NOBATCH/NODIAL/NOINTER/NOREM/NETW 2) Change the password for DECNET in your network executor database: NCP> set exec nonpriviliged password NEW_DECNET_PASSWORD NCP> define exec nonpriviliged password NEW_DECNET_PASSWORD The important thing to remember is that the password must be changed in BOTH places, otherwise your network WILL break. The worm is breaking nodes by penetrating the DECNET account, and changing only the UAF password with the $SET PASSWORD command. By not changing the NCP password, the network no longer accepts INBOUND connections. For more information, consult the VAX/VMS manuals: VMS V4.X - Volume 6 "Networking Manual" VMS V5.x - Volume 5A&5B "Guide to DECnet-VAX Networking" - --------------------------------------------------------------------------- Ron Tencati | NCF::TENCATI /6277::TENCATI SPAN Security Manager | Tencati@Nssdca.gsfc.nasa.gov NASA/Goddard Space Flight Center | (301)286-5223 Greenbelt, MD. USA | - --------------------------------------------------------------------------- ------------------------------ Date: 31 Oct 89 20:54:37 +0000 From: kerchen@iris.ucdavis.edu (Paul Kerchen) Subject: Re: Checksum programs RADAI1@HBUNOS.BITNET (Y. Radai) writes: > In my opinion, the most important requirements on a checksum program >are: >(5) It must be convenient to specify and update the list of files to > be checksummed. This point brings up a problem which is common to most checksumming solutions: where does one store these checksums and their keys? If they are stored on disk, they are vulnerable to attack just like programs. That is, a virus could infect the program and then update its checksum, since the key must be somewhere on disk as well (unless the user enters it every time they compute a checksum--yecch!) and one must assume that the checksum algorithm is known. Or, more simply, a virus could simply wipe out all the checksums, leaving the user to decide which files were infected. Storing the 'sums off line would insure security, but at what cost? Checking and updating the 'sums with any frequency would become tedious at best. I don't mean to rain on this parade, but this issue is one which must be considered by anyone writing a checksum-based anti-viral program. Paul Kerchen | kerchen@iris.ucdavis.edu ------------------------------ Date: Wed, 01 Nov 89 09:32:37 -0500 From: ZLCBEOWEN@csvax.qut.oz Subject: Re: Imbedded virus detection Bob McCabe writes: > While working out the algorithm for this check it struck me >that it should be possible to work out a scheme by which any >program could check itself at load time for infection. Have a look at PC Magazine Aug. 1989, 8(14), p411. There is some code there which does exactly this. - -- Chris Owen | zlcbeowen@csvax.qut.edu.au Library | phone: +61 7 223 2406 Queensland University of Technology | fax: +61 7 229 0874 Brisbane, AUSTRALIA | ------------------------------ Date: 1 Nov 89 13:47:43 GMT From: comcon!roy@uunet.UU.NET (Roy M. Silvernail) Subject: Re: Checksum programs RADAI1@HBUNOS.BITNET (Y. Radai) writes: > In my opinion, the most important requirements on a checksum program > are: > (2) Even if the checksum algorithm and checksum length are known, > without knowledge of the key (the generating polynomial in the > case of a CRC algorithm), it should be impossible to modify a file > in such a way that the checksum remains unchanged. What about doing both an 8-bit and a 16-bit CRC on the file, along with a record of the file length? It seems to me that an altered file might be able to duplicate one of the checksum, but not both, and certainly not both sums *and* the length record. (This might also reduce the need for each machine generating a unique checksum... something I have no clue about. How would this be done?) Roy M. Silvernail | UUCP: uunet!comcon!roy | "No, I don't live in an igloo!" [ah, but it's my account... of course I opine!] -Sourdough's riposte SnailMail: P.O. Box 210856, Anchorage, Alaska, 99521-0856, U.S.A., Earth, etc. ------------------------------ End of VIRUS-L Digest ********************* 9-Nov-89 23:08:34-GMT,12040;000000000001 Received: from RUTVM1.RUTGERS.EDU by topaz.rutgers.edu (5.59/SMI4.0/RU1.1/3.04) id AA01053; Thu, 9 Nov 89 18:05:33 EST Message-Id: <8911092305.AA01053@topaz.rutgers.edu> Received: from RUTVM1.RUTGERS.EDU by RutVM1.Rutgers.Edu (IBM VM SMTP R1.2.1MX) with BSMTP id 6609; Thu, 09 Nov 89 18:59:24 EDT Received: from RUTVM1 by RUTVM1.RUTGERS.EDU (Mailer R2.04RU) with BSMTP id 6606; Thu, 09 Nov 89 13:56:17 EDT Date: Thu, 9 Nov 89 10:41:53 EST Reply-To: VIRUS-L@ibm1.cc.lehigh.edu Sender: Virus Discussion List From: "The Moderator Kenneth R. van Wyk" Subject: VIRUS-L Digest V2 #237 To: Multiple recipients of list VIRUS-L VIRUS-L Digest Thursday, 9 Nov 1989 Volume 2 : Issue 237 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: Where are the Sophisticated Viruses? Chinese Viruses Re: Macwight Virus (?) Jerusalem virus (PC) virus problem undecidability KillVirus INIT (Mac) Re: Macwight Virus (?) MacWight? (Mac) Dukakis Virus (Mac) RE: future viruses on a PC Pull plug before cleaning --------------------------------------------------------------------------- Date: Wed, 08 Nov 89 13:15:35 +0000 From: christer@cs.umu.se (Christer Ericson) Subject: Re: Where are the Sophisticated Viruses? In article <0002.8911062045.AA11747@ge.sei.cmu.edu> ctycal!ingoldsb@cpsc.ucalga ry.ca writes: >There are probably two reasons why the viruses you suggest do not >exist: > 1) If the system code is bypassed, then it must be rewritten. > Most hackers are not at that level. Those that are that > proficient are busy making money. > 2) Code to do all the stuff needed would be quite large, and > therefore noticeable. If you add 20 K to somebody's > programs they will likely notice. I don't agree with you on any of these points, Terry. Say, on the Macintosh all calls to ROM are done through trap vectors in RAM. These trap vectors are patched by the system file (to fix bugs), by some programs and by all anti-virus tools. However, it doesn't take a genius to figure out that one could restore the trap vector to it's original value and thereby bypassing the "safe" system. (Alright, we don't have the bug fixes installed, but it's easy to mimic what is done by the system file. (For instance by simply calling the very same routine.)). A patch like this wouldn't occupy much space and is quite simple to write. I'd guess I could write a virus using the above technique in a day or two, which would be undetectable by all existing anti-virus tools, and along with me so could lots of other people. However some of us are busy making money, as you said, and we who are just working (:-)) probably have some sense of moral, stopping us from bringing total chaos to the computer society. > Terry Ingoldsby /Christer | Christer Ericson Internet: christer@cs.umu.se | | Department of Computer Science, University of Umea, S-90187 UMEA, Sweden | | >>>>> "I bully sheep. I claim God doesn't exist..." <<<<< | ------------------------------ Date: Wed, 08 Nov 89 13:20:38 +0000 From: frisk@rhi.hi.is (Fridrik Skulason) Subject: Chinese Viruses I just saw a note on comp.risks about viruses in China. > Ministry of Public Safety of People's Republic of China found this >summer that one tenth of the computers in China had been contaminated by >three types of computer virus: "Small Ball", "Marijuana" and "Shell", China >Daily reported. The "Small Ball" is probably just a variant of Ping-Pong, "Marijuana" is the same virus as "Stoned" or "New Zealand", but what is "Shell" ?? Anybody got an idea ? - -frisk ------------------------------ Date: Wed, 08 Nov 89 12:08:20 -0500 From: dmg@lid.mitre.org (David Gursky) Subject: Re: Macwight Virus (?) In Virus-L V2 #235, "Gregory E. Gilbert" asks about the "Macwight" (sic) virus. Recently, there was a report of a virus that attacked MacWrite from the University of Rochester. Since the initial report however, nothing has been heard from them. ------------------------------ Date: Wed, 08 Nov 89 11:54:42 -0600 From: ST7751%SIUCVMB.BITNET@VMA.CC.CMU.EDU (Chris Beckenbach) Subject: Jerusalem virus (PC) The Jerusalem virus has turned up here at Southern Illinois University, also. From dissecting a copy of the virus, and an article in the February 15, 1989 edition of Datamation ("The Virus Cure", by John McAffe, Pp. 29-40), the Jerusalem virus (called the Israeli virus in the Datamation article) does the following: When an infected .EXE or .COM file is loaded and run, the Jerusalem virus checks to see if it is already resident in the computer. If not, it sets itself up to intercept DOS INT 21h, then proceeds to run the infected program normally. Whenever a call is made to INT 21h to execute a program (function 4Bh), the virus will append itself to the program file on the disk and set itself up as the entry point for that program. This adds 1808 bytes of length to the file, but does not change the time/date stamp. If the disk is write-protected, no error will be given, and the file will not be infected. The copy of the virus that I have been looking at infects .EXE files multiple times (the Datamation article says that this is a bug that has been "fixed" by hackers in other versions), so usually the major problem with this virus will be that it will waste memory and disk space. John McAfee's article also says that this multiple infection does not occur with .COM files, but I have not verified this. The most serious aspect of this virus is that when the system date is Friday the 13th (except when the year is 1987--this virus was first discovered in 1987, so this was probably written in to give it time to spread) any call to execute a .COM or .EXE file will result in the file's being deleted from the disk. I have been informed that Flushot will take the virus out of infected programs, so if you have the virus and Flushot, you might want to try this. Hope this has been of help. Chris Beckenbach ST7751@SIUCVMB Computer Science major Southern Illinois University Carbondale, Illinois "I think, therefore I think I am--I think." ------------------------------ Date: Wed, 08 Nov 89 16:32:00 -0500 From: Peter W. Day Subject: virus problem undecidability A note to the virus-l digest of 6-Nov-89 said that "the virus problem (at least detection anyway) is undecidable." Does anyone know if there are any papers where this result is proved? Or where the problem is shown to not be NP complete? Or even where the problem is stated precisely? Thanks, Peter Day Emory University ------------------------------ Date: Wed, 08 Nov 89 17:04:50 -0500 From: Joe McMahon Subject: KillVirus INIT (Mac) Yes, the KillVirus INIT contains a "dummy" nVIR resource which it will attempt to install into the System file. This resource will trigger most less-sophisticated virus detectors. In addition, KillVirus is supposed to be able to automatically uninfect files infected with the A strain of nVIR. I haven't tested this, but I wouldn't want to bet the farm on it. --- Joe M. ------------------------------ Date: 08 Nov 89 22:41:56 +0000 From: jap2_ss@uhura.cc.rochester.edu (The Mad Mathematician) Subject: Re: Macwight Virus (?) In article <0004.8911081210.AA26585@ge.sei.cmu.edu> C0195%UNIVSCVM.BITNET@VMA.C C.CMU.EDU (Gregory E. Gilbert) writes: >Is there such a beast? Macwight is a name someone here at the U of R gave to an error we found in a few copies of Macwrite. Something or someone changed the icon of Macwrite to show the word Macwite instead of the lines, and the name of the the application to Macwite or Macwight. After the first few reports, I got a copy to play with for a while, but it was taken and given to someone else. Since then I haven't seen another, nor have any of the student consultants. I don't know if this was a true virus, but it a copy of Macwrite changed before the consultant's boss' eyes, ie the name changed from Macwrite to Macwite, and upon inspection via Resedit the icon was found to have changed. >Gregory E. Gilbert The Mad Mathematician jap2_ss@uhura.cc.rochester.edu Mad, adj. Affected with a high degree of intellectual independence. Ambrose Bierce, _The_Devil's_Dictionary_ ------------------------------ Date: Wed, 08 Nov 89 18:17:21 -0500 From: Joe McMahon Subject: MacWight? (Mac) You may (or may not :-) remember the discussions we had here on the list about this. As far as I remember, there was never a specific demonstration that there was a virus involved. That doesn't mean that there wasn't; it just means that there were never quite enough facts presented to make a case either way. I'd leave it off for now, or mention it as a "rumored sighting" or whetever. Safest not to mention it, especially since it was never pinned down and analyzed. --- Joe M. ------------------------------ Date: Wed, 08 Nov 89 18:20:42 -0500 From: Joe McMahon Subject: Dukakis Virus (Mac) The "Dukakis Virus" was a self-perpetuating HyperCard script. When the stack containing it was opened, it would first try to install itself into the Home stack. The version in the Home stack would then spread to other stacks. Editing it out of the Home stack and installing an "ON SET" script was sufficient to block it. It was released on CompuServe and apparently was not set up to have a long enough incubation time before it first went off. I believe it was stamped out pretty quickly, but it did exist. Worst, the actual script was published in the InfoMac digest... --- Joe M. ------------------------------ Date: Wed, 08 Nov 89 22:40:00 -0600 From: "David Richardson, UTA" Subject: RE: future viruses on a PC Pull plug before cleaning frisk@rhi.hi.is writes >jim frost writes: >>Limiting Propagation Rates. [edited out list of viruses that limit propogation rates] [frost goes on to point out how some of todays viruses meet some criteria of the "ultimate virus", and mentions the threat of AIDS and other anti-disinfecting viruses] >>By now you should get the idea that almost every virus we've seen is >>primitive, although several showed some of the survival traits which I >>outline above. Given the limited resources of PC environments, it's >>unlikely that you'll get a very sophisticated virus. > >I must disagree. In the PC environment it is not a question of limited >resources, but rather the fact that any user process has full access to >ALL resources and can even directly manipulate the hardware if required. >So, my opinion is that it is even easier to write a sophisticated virus on >the PC than in most other environments. The PC user has one weapon that is impactical on a mainframe: THE PC USER CAN TURN OFF HIS MACHINE AT ANY TIME AND DISINFECT HIS SYSTEM VERY EASILY. NO VIRUS (THAT I KNOW OF) CAN LIVE THROUGH A COLD BOOT. As long as PCs retain an OFF switch, then we have the ultimate power over our compters, viruses or not. - -David Richardson b645zax@utarlg.bitnet, @utarlg.arl.utexas.edu UTSPAN::UTADNX::UTARLG::B645ZAX phone +1 817 273 2231 ------------------------------ End of VIRUS-L Digest ********************* 10-Nov-89 2:00:57-GMT,22612;000000000001 Received: from RUTVM1.RUTGERS.EDU by topaz.rutgers.edu (5.59/SMI4.0/RU1.1/3.04) id AA07604; Thu, 9 Nov 89 20:59:47 EST Message-Id: <8911100159.AA07604@topaz.rutgers.edu> Received: from RUTVM1.RUTGERS.EDU by RutVM1.Rutgers.Edu (IBM VM SMTP R1.2.1MX) with BSMTP id 0228; Thu, 09 Nov 89 21:59:24 EDT Received: from RUTVM1 by RUTVM1.RUTGERS.EDU (Mailer R2.04RU) with BSMTP id 0225; Wed, 08 Nov 89 09:49:38 EDT Date: Wed, 8 Nov 89 08:27:38 EST Reply-To: VIRUS-L@ibm1.cc.lehigh.edu Sender: Virus Discussion List From: "The Moderator Kenneth R. van Wyk" Subject: VIRUS-L Digest V2 #236 Comments: To: VIRUS-L@ibm1.cc.lehigh.edu To: Multiple recipients of list VIRUS-L VIRUS-L Digest Wednesday, 8 Nov 1989 Volume 2 : Issue 236 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: Introduction to the anti-viral archives UNIX anti-viral archive sites Apple II anti-viral archive sites Atari ST anti-viral archive sites Amiga anti-viral archive sites IBMPC anti-viral archive sites Documentation anti-viral archive sites Macintosh anti-viral archive sites New anti-virus files uploaded to SIMTEL20 (PC) Re: Where are the Sophisticated Viruses? (PC) --------------------------------------------------------------------------- Date: 08 Nov 89 05:19:49 +0000 From: jwright@atanasoff.cs.iastate.edu (Jim Wright) Subject: Introduction to the anti-viral archives # Introduction to the Anti-viral archives... # Listing of 07 November 1989 This posting is the introduction to the "official" anti-viral archives of virus-l/comp.virus. With the generous cooperation of many sites throughout the world, we are attempting to make available to all the most recent news and programs for dealing with the virus problem. Currently we have sites for Amiga, Apple II, Atari ST, IBMPC, Macintosh and Unix computers, as well as sites carrying research papers and reports of general interest. If you have general questions regarding the archives, you can send them to this list or to me. I'll do my best to help. If you have a submission for the archives, you can send it to me or to one of the persons in charge of the relevant sites. If you have any corrections to the lists, please let me know. Jim ==== cruft for the lawyers ==== The files contained on the participating archive sites are provided freely on an as-is basis. To the best of our knowledge, all files contained in the archives are either Public Domain, Freely Redistributable, or Shareware. If you know of one that is not, please drop us a line and let us know. PLEASE NOTE The Managers of these systems, and the Maintainers of the archives, CAN NOT and DO NOT guarantee any of these applications for any purpose. All possible precautions have been taken to assure you of a safe repository of useful tools. Unfortunately, in this day and age nothing is certain. It is awful that these people have to worry about legalities when they are only trying to provide a free and useful service. But facts are facts. Your use of the archives relieves the sites from any liability. Sigh. ------------------------------ Date: 08 Nov 89 05:20:49 +0000 From: jwright@atanasoff.cs.iastate.edu (Jim Wright) Subject: UNIX anti-viral archive sites # Anti-viral and security archive sites for Unix # Listing last changed 30 September 1989 attctc Charles Boykin Accessible through UUCP. cs.hw.ac.uk Dave Ferbrache NIFTP from JANET sites, login as "guest". Electronic mail to . Main access is through mail server. The master index for the virus archives can be retrieved as request: virus topic: index For further details send a message with the text help The administrative address is sauna.hut.fi Jyrki Kuoppala Accessible through anonymous ftp, IP number 128.214.3.119. (Note that this IP number is likely to change.) ucf1vm Lois Buwalda Accessible through... wuarchive.wustl.edu Chris Myers Accessible through anonymous ftp, IP number 128.252.135.4. A number of directories can be found in ~ftp/usenet/comp.virus/*. ------------------------------ Date: 08 Nov 89 05:18:15 +0000 From: jwright@atanasoff.cs.iastate.edu (Jim Wright) Subject: Apple II anti-viral archive sites # Anti-viral archive sites for the Apple II # Listing last changed 30 September 1989 brownvm.bitnet Chris Chung Access is through LISTSERV, using SEND, TELL and MAIL commands. Files are stored as apple2-l xx-xxxxx where the x's are the file number. cs.hw.ac.uk Dave Ferbrache NIFTP from JANET sites, login as "guest". Electronic mail to . Main access is through mail server. The master index for the virus archives can be retrieved as request: virus topic: index The Apple II index for the virus archives can be retrieved as request: apple topic: index For further details send a message with the text help The administrative address is uk.ac.lancs.pdsoft Steve Jenkins Service for UK only; no access from BITNET/Internet/UUCP Terminals : call lancs.pdsoft, login as "pdsoft", pwd "pdsoft" FTP : call lancs.pdsoft, user "pdsoft", pwd "pdsoft". Pull the file "help/basics" for starter info, "micros/index" for index. Anti-Viral stuff is held as part of larger micro software collection and is not collected into a distinct area. ------------------------------ Date: 08 Nov 89 05:18:37 +0000 From: jwright@atanasoff.cs.iastate.edu (Jim Wright) Subject: Atari ST anti-viral archive sites # Anti-viral archive sites for the Atari ST # Listing last changed 30 September 1989 cs.hw.ac.uk Dave Ferbrache NIFTP from JANET sites, login as "guest". Electronic mail to . Main access is through mail server. The master index for the virus archives can be retrieved as request: virus topic: index The Atari ST index for the virus archives can be retrieved as request: atari topic: index For further details send a message with the text help The administrative address is . panarthea.ebay Steve Grimm Access to the archives is through mail server. For instructions on the archiver server, send help to . uk.ac.lancs.pdsoft Steve Jenkins Service for UK only; no access from BITNET/Internet/UUCP Terminals : call lancs.pdsoft, login as "pdsoft", pwd "pdsoft" FTP : call lancs.pdsoft, user "pdsoft", pwd "pdsoft". Pull the file "help/basics" for starter info, "micros/index" for index. Anti-Viral stuff is held as part of larger micro software collection and is not collected into a distinct area. ------------------------------ Date: 08 Nov 89 05:17:51 +0000 From: jwright@atanasoff.cs.iastate.edu (Jim Wright) Subject: Amiga anti-viral archive sites # Anti-viral archive sites for the Amiga # Listing last changed 30 September 1989 cs.hw.ac.uk Dave Ferbrache NIFTP from JANET sites, login as "guest". Electronic mail to . Main access is through mail server. The master index for the virus archives can be retrieved as request: virus topic: index The Amiga index for the virus archives can be retrieved as request: amiga topic: index For further details send a message with the text help The administrative address is ms.uky.edu Sean Casey Access is through anonymous ftp. The Amiga anti-viral archives can be found in /pub/amiga/Antivirus. The IP address is 128.163.128.6. uk.ac.lancs.pdsoft Steve Jenkins Service for UK only; no access from BITNET/Internet/UUCP Terminals : call lancs.pdsoft, login as "pdsoft", pwd "pdsoft" FTP : call lancs.pdsoft, user "pdsoft", pwd "pdsoft". Pull the file "help/basics" for starter info, "micros/index" for index. Anti-Viral stuff is held as part of larger micro software collection and is not collected into a distinct area. uxe.cso.uiuc.edu Mark Zinzow Lionel Hummel The archives are in /amiga/virus. There is also a lot of stuff to be found in the Fish collection. The IP address is 128.174.5.54. Another possible source is uihub.cs.uiuc.edu at 128.174.252.27. Check there in /pub/amiga/virus. ------------------------------ Date: 08 Nov 89 05:19:26 +0000 From: jwright@atanasoff.cs.iastate.edu (Jim Wright) Subject: IBMPC anti-viral archive sites # Anti-viral archive for the IBMPC # Listing last changed 30 September 1989 cs.hw.ac.uk Dave Ferbrache NIFTP from JANET sites, login as "guest". Electronic mail to . Main access is through mail server. The master index for the virus archives can be retrieved as request: virus topic: index The IBMPC index for the virus archives can be retrieved as request: ibmpc topic: index For further details send a message with the text help The administrative address is ms.uky.edu Daniel Chaney This site can be reached through anonymous ftp. The IBMPC anti-viral archives can be found in /pub/msdos/AntiVirus. The IP address is 128.163.128.6. uk.ac.lancs.pdsoft Steve Jenkins Service for UK only; no access from BITNET/Internet/UUCP Terminals : call lancs.pdsoft, login as "pdsoft", pwd "pdsoft" FTP : call lancs.pdsoft, user "pdsoft", pwd "pdsoft". Pull the file "help/basics" for starter info, "micros/index" for index. Anti-Viral stuff is held as part of larger micro software collection and is not collected into a distinct area. uxe.cso.uiuc.edu Mark Zinzow This site can be reached through anonymous ftp. The IBMPC anti-viral archives are in /pc/virus. The IP address is 128.174.5.54. vega.hut.fi Timo Kiravuo This site (in Finland) can be reached through anonymous ftp. The IBMPC anti-viral archives are in /pub/pc/virus. The IP address is 128.214.3.82. wsmr-simtel20.army.mil Keith Peterson Direct access is through anonymous ftp, IP 26.2.0.74. The anti-viral archives are in PD1:. Simtel is a TOPS-20 machine, and as such you should use "tenex" mode and not "binary" mode to retreive archives. Please get the file 00-INDEX.TXT using "ascii" mode and review it offline. NOTE: There are also a number of servers which provide access to the archives at simtel. WSMR-SIMTEL20.Army.Mil can be accessed using LISTSERV commands from BITNET via LISTSERV@NDSUVM1, LISTSERV@RPIECS and in Europe from EARN TRICKLE servers. Send commands to TRICKLE@ (for example: TRICKLE@AWIWUW11). The following TRICKLE servers are presently available: AWIWUW11 (Austria), BANUFS11 (Belgium), DKTC11 (Denmark), DB0FUB11 (Germany), IMIPOLI (Italy), EB0UB011 (Spain) and TREARN (Turkey). ------------------------------ Date: 08 Nov 89 05:18:59 +0000 From: jwright@atanasoff.cs.iastate.edu (Jim Wright) Subject: Documentation anti-viral archive sites # Anti-viral archive sites for documentation # Listing last changed 30 September 1989 cs.hw.ac.uk Dave Ferbrache NIFTP from JANET sites, login as "guest". Electronic mail to . Main access is through mail server. The master index for the virus archives can be retrieved as request: virus topic: index The index for the **GENERAL** virus archives can be retrieved as request: general topic: index The index for the **MISC.** virus archives can be retrieved as request: misc topic: index **VIRUS-L** entries are stored in monthly and weekly digest form from May 1988 to December 1988. These are accessed as log.8804 where the topic substring is comprised of the year, month and a week letter. The topics are: 8804, 8805, 8806 - monthly digests up to June 1988 8806a, 8806b, 8806c, 8806d, 8807a .. 8812d - weekly digests The following daily digest format started on Wed 9 Nov 1988. Digests are stored by volume number, e.g. request: virus topic: v1.2 would retrieve issue 2 of volume 1, in addition v1.index, v2.index and v1.contents, v2.contents will retrieve an index of available digests and a extracted list of the the contents of each volume respectively. **COMP.RISKS** archives from v7.96 are available on line as: request: comp.risks topic: v7.96 where topic is the issue number, as above v7.index, v8.index and v7.contents and v8.contents will retrieve indexes and contents lists. For further details send a message with the text help The administrative address is lehiibm1.bitnet Ken van Wyk new: This site has archives of VIRUS-L, and many papers of general interest. Access is through ftp, IP address 128.180.2.1. The directories of interest are VIRUS-L and VIRUS-P. uk.ac.lancs.pdsoft Steve Jenkins Service for UK only; no access from BITNET/Internet/UUCP Terminals : call lancs.pdsoft, login as "pdsoft", pwd "pdsoft" FTP : call lancs.pdsoft, user "pdsoft", pwd "pdsoft". Pull the file "help/basics" for starter info, "micros/index" for index. Anti-Viral stuff is held as part of larger micro software collection and is not collected into a distinct area. unma.unm.edu Dave Grisham This site has a collection of ethics documents. Included are legislation from several states and policies from many institutions. Access is through ftp, IP address 129.24.8.1. Look in the directory /ethics. ------------------------------ Date: 08 Nov 89 05:20:23 +0000 From: jwright@atanasoff.cs.iastate.edu (Jim Wright) Subject: Macintosh anti-viral archive sites # Anti-viral archive sites for the Macintosh # Listing last changed 07 November 1989 cs.hw.ac.uk Dave Ferbrache NIFTP from JANET sites, login as "guest". Electronic mail to . Main access is through mail server. The master index for the virus archives can be retrieved as request: virus topic: index The Mac index for the virus archives can be retrieved as request: mac topic: index For further details send a message with the text help The administrative address is ifi.ethz.ch Danny Schwendener Interactive access through DECnet (SPAN/HEPnet): $SET HOST 57434 or $SET HOST AEOLUS Username: MAC Interactive access through X.25 (022847911065) or Modem 2400 bps (+41-1-251-6271): # CALL B050 Username: MAC Files may also be copied via DECnet (SPAN/HEPnet) from 57434::DISK8:[MAC.TOP.LIBRARY.VIRUS] rascal.ics.utexas.edu Werner Uhrig Access is through anonymous ftp, IP number is 128.83.144.1. Archives can be found in the directory mac/virus-tools. Please retrieve the file 00.INDEX and review it offline. Due to the size of the archive, online browsing is discouraged. scfvm.bitnet Joe McMahon Access is via LISTSERV. SCFVM offers an "automatic update" service. Send the message AFD ADD VIRUSREM PACKAGE and you will receive updates as the archive is updated. You can also subscribe to automatic file update information with FUI ADD VIRUSREM PACKAGE sumex-aim.stanford.edu Bill Lipa Access is through anonymous ftp, IP number is 36.44.0.6. Archives can be found in /info-mac/virus. Administrative queries to . Submissions to . There are a number of sites which maintain shadow archives of the info-mac archives at sumex: * MACSERV@PUCC services the Bitnet community * LISTSERV@RICE for e-mail users * FILESERV@IRLEARN for folks in Europe uk.ac.lancs.pdsoft Steve Jenkins Service for UK only; no access from BITNET/Internet/UUCP Terminals : call lancs.pdsoft, login as "pdsoft", pwd "pdsoft" FTP : call lancs.pdsoft, user "pdsoft", pwd "pdsoft". Pull the file "help/basics" for starter info, "micros/index" for index. Anti-Viral stuff is held as part of larger micro software collection and is not collected into a distinct area. wsmr-simtel20.army.mil Robert Thum Access is through anonymous ftp, IP number 26.2.0.74. Archives can be found in PD3:. Please get the file 00README.TXT and review it offline. ------------------------------ Date: Wed, 08 Nov 89 01:15:00 -0700 From: Keith Petersen Subject: New anti-virus files uploaded to SIMTEL20 (PC) I have uploaded the following files to SIMTEL20: pd1: SCANRS48.ARC Resident program to scan for many viruses SCANV48.ARC VirusScan, scans disk files for 48 viruses SCANRS48 and SCANV48 were downloaded from the Homebase BBS. - --Keith Petersen Maintainer of SIMTEL20's CP/M, MSDOS, & MISC archives [IP address 26.2.0.74] Internet: w8sdz@WSMR-SIMTEL20.Army.Mil, w8sdz@brl.arpa BITNET: w8sdz@NDSUVM1 Uucp: {ames,decwrl,harvard,rutgers,ucbvax,uunet}!wsmr-simtel20.army.mil!w8sdz ------------------------------ Date: 08 Nov 89 11:23:12 +0000 From: frisk@rhi.hi.is (Fridrik Skulason) Subject: Re: Where are the Sophisticated Viruses? (PC) jim frost writes: >Limiting Propagation Rates. Some viruses do this. SysLock, Icelandic and Typo-COM will only infect some of the programs they have a chance to infect. They use different methods, like "only every other day" or "only every tenth program run". >Limiting Re-Infections. Most simple viruses don't detect systems >which have already been infected and will re-infect them. Actually very few viruses infect the same "victim" over and over. Some boot sector viruses do, but the only program virus which does so is the original version of the Israeli (Jerusalem) virus. > >Detecting and Avoiding "Virus-Protected" Hosts. I have yet to see a >virus which looked at the state of a system to detect virus detection >mechanisms to nullify them and/or avoid infecting them. One virus - the "Icelandic" virus - makes an attempt at this. It will not infect a system if it determines that any program has hooked INT 13. Since all virus monitoring programs do that, it will not be detected by them. (In practice this does not work too well, because of a bug in the code..) >Staying Within Normal System Activity Boundaries. Most resident viruses do this. >Hiding From Standard System Utilities. This is the difficult part. Very few existing viruses are able to do this properly. Most boot sector viruses will decrease the amount of memory available - for example turning a 640K machine into a 639K one. Program viruses can in many cases be detected by using a ordinary memory mapping utility. Still, quite a few manage to hide even from that, but there is room for much improvement in this area :-( >Modifying Hosts To Make Them More Susceptible To Re-Infection. This brings up the topic of "virus types we have not seen yet". I have written a document describing a few types of viruses that could theoretically be written, but are currently unknown. Description of one of the types follows. 7) The "AIDS" type. This type of virus is very dangerous. Not because it destroys programs or data, but because it attacks the protection mechanism in the computer. These viruses can be divided in two subgroups. Specific: These viruses will search for known anti-virus programs and disable or destroy them. They might to that by patching the code in memory and then overwriting parts of the protection programs on the disk. General: These viruses must be much more complicated, but they could for example try to determine what programs had hooked a specific interrupt. Then they might modify a few memory locations in order to bypass those programs. A virus of this type might not do any further damage, but it would leave the system vulnerable to attacks by other viruses, which might then have a devastating effect. >By now you should get the idea that almost every virus we've seen is >primitive, although several showed some of the survival traits which I >outline above. Given the limited resources of PC environments, it's >unlikely that you'll get a very sophisticated virus. I must disagree. In the PC environment it is not a question of limited resources, but rather the fact that any user process has full access to ALL resources and can even directly manipulate the hardware if required. So, my opinion is that it is even easier to write a sophisticated virus on the PC than in most other environments. Finally, I want to add one "feature" to the description of a sophisticated virus: "Bypass protection programs and jump directly to the hardware, DOS or BIOS routines." There are quite a few "filter" programs available that will monitor every INT 13, INT 21, INT 40.... call and alert the user if an attempt is made to do an illegal operation. They are, however, almost useless against viruses that can access the system directly in the way described above. Only two or three viruses do this now, but I am certain that more virus writers will figure out how to do this in the future. :-( - -frisk Fridrik Skulason University of Iceland frisk@rhi.hi.is Computing Sevices Guvf yvar vagragvbanyyl yrsg oynax ................. ------------------------------ End of VIRUS-L Digest ********************* 10-Nov-89 2:03:36-GMT,21708;000000000001 Received: from RUTVM1.RUTGERS.EDU by topaz.rutgers.edu (5.59/SMI4.0/RU1.1/3.04) id AA07681; Thu, 9 Nov 89 21:02:18 EST Message-Id: <8911100202.AA07681@topaz.rutgers.edu> Received: from RUTVM1.RUTGERS.EDU by RutVM1.Rutgers.Edu (IBM VM SMTP R1.2.1MX) with BSMTP id 0065; Thu, 09 Nov 89 22:01:54 EDT Received: from RUTVM1 by RUTVM1.RUTGERS.EDU (Mailer R2.04RU) with BSMTP id 0062; Wed, 08 Nov 89 08:24:20 EDT Date: Wed, 8 Nov 89 07:10:51 EST Reply-To: VIRUS-L@ibm1.cc.lehigh.edu Sender: Virus Discussion List From: "The Moderator Kenneth R. van Wyk" Subject: VIRUS-L Digest V2 #235 Comments: To: VIRUS-L@ibm1.cc.lehigh.edu To: Multiple recipients of list VIRUS-L VIRUS-L Digest Wednesday, 8 Nov 1989 Volume 2 : Issue 235 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: SCANV42 and ASHAR Virus (Mac...really PC) Re: Use of the term "SNEAK" Re: Where are the Sophisticated Viruses? Macwight Virus (?) Reviewing a Virus Article Virus List (MAC) TROJAN Horse by the name of NORTSTOP (PC) Previously reported BootChek problems (PC) Re: Virus source available in Toronto Re: Where are the Sophisticated Viruses? need disinfection info for BRAIN virus (PC) WARNING: Brain virus infection (PC) Re: Virus List - Notes (Mac) excerpts from risks-l digest --------------------------------------------------------------------------- Date: Tue, 07 Nov 89 07:38:30 -0500 From: dmg@lid.mitre.org (David Gursky) Subject: Re: SCANV42 and ASHAR Virus (Mac...really PC) SCANV42 and the Ashar virus have nothing to do with the Mac :) [Ed. An embarassed moderator stands corrected. :-)] ------------------------------ Date: Tue, 07 Nov 89 07:44:31 -0500 From: dmg@lid.mitre.org (David Gursky) Subject: Re: Use of the term "SNEAK" In Virus-L V2 #234, , robert@polari.UUCP (robert) [Robert Riebman] speculates that Robert Woodhead's Virex application takes a more conservative approach than Interferon, and does not worry about identifying new viruses, under the generic term "Sneak". While I do no use Virex, it is my understanding that it does try the same trick as Interferon, and identify suspicious code as a "sneak" virus. As also stated previously, there is no virus known as "sneak" per se. This is a term Woodhead alone uses to discuess new viruses that his applications are not familiar with. ------------------------------ Date: 07 Nov 89 00:00:00 +0000 From: "David.M..Chess" Subject: Re: Where are the Sophisticated Viruses? In reply to a posting of mine, madd@world.std.com (jim frost) writes > Sigh. We're lucky that no very competent programmer has tried to > write a virus, all right. and goes on to give examples of some nasty things that future viruses/worms might do. His item is interesting and welcome; I'm not clear, though, in what sense it's a reply to mine, or what the "sigh" means. In the posting that Mr. Frost is quoting from, I was just replying to the original assertion that current tools would not be able to detect a virus that bypassed the operating system to talk directly to the hardware, by pointing out that one class of tool that's common today would not be fooled by that approach. I certainly didn't mean to suggest that there aren't *other* clever things that viruses could do, but haven't yet done. DC ------------------------------ Date: Tue, 07 Nov 89 10:06:33 -0500 From: "Gregory E. Gilbert" Subject: Macwight Virus (?) Is there such a beast? Shuld I add it to the current list I have of KNOWN viruses? There is plenty of room now that I have deleted "SNEAK" and "San Jose" from the list. Thanks for the clarification. P. S. If anyone has a history of Macwight, if it exists, please forward me a copy. Thanks again. Gregory E. Gilbert Computer Services Division University of South Carolina Columbia, South Carolina USA 29208 (803) 777-6015 Acknowledge-To: ------------------------------ Date: Tue, 07 Nov 89 10:13:28 -0500 From: "Gregory E. Gilbert" Subject: Reviewing a Virus Article I apologize for posting this request again. I am writing an article for our computing newsletter and if anyone would care to review it (if OK with Ken I can post it when finished) I would welcome the critiques. The only catch is that I must have the reviews back NO LATER THAN 13 November. If interested please send me your address. Gregory E. Gilbert Computer Services Division University of South Carolina Columbia, South Carolina USA 29208 (803) 777-6015 FAX: (803) 777-4760 Acknowledge-To: ------------------------------ Date: Tue, 07 Nov 89 11:45:17 -0500 From: Jason Subject: Virus List (MAC) I try to keep up with the Macintosh virus arena, but I've never heard of the Dukakis virus. Could someone please summerize some information on what it is, where it started, and what it does? Thank you, =From the desk of: *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= * Jason D. Blue = User Services * = User Support Center Specialist * The MITRE Corporation = * jblue@mwunix.mitre.org = 703-883-7999 * =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Disclaimer: The views expressed above are my own and do not reflect the position of my employer. ------------------------------ Date: Tue, 07 Nov 89 12:33:07 -0500 From: SDSV@MELPAR-EMH1.ARMY.MIL Subject: TROJAN Horse by the name of NORTSTOP (PC) From: Mr. J. Vavrina, Intel & Sec Div, Automation Branch Subject: TROJAN Horse by the name of NORTSTOP (PC) I received this message via Ham Radio. Path: K4NGC!W3IWI!WA4ONG!WB0TAX!WA2PVV Date: 05 Nov 89 03:06:20 Z From: WA2PVV@WA2PVV To: KA4USE Subject: Found This On My System There is a file going around called either NORTSTOP.ZIP or NORTSHOT.ZIP which, by it's (sparse) documentation and the copyright inside the EXE file, claims to be from Norton Computing. Because of the sparse and unprofessionally presented docs, I looked within the EXE file and found: The Norton Public Domain Virus Utility, PD Edition 5.50, (C)1989 Peter Norton Your System has been infected with a Christmas virus! Selected files were just eliminated! Without these files, you might as well use your computer as a damn, boat anchor! If you do NOT own a boat, you may want to replace the files which were just erased. Try to determine which files they were. HARDY HA! HA! HA! HOW DO YOU FEEL NOW; YOU IDIOT? MERRY CHRISTMAS AND HAPPY NEW YEAR! =================== PKUNZIP reports: 1065 Implode 650 39% 10-04-89 12:26 9778978d --w READ-ME.NOW 38907 Implode 30156 23% 10-02-89 11:57 c333dec0 --w NORTSHOT.EXE - ----- ------ --- ------- 39972 30806 23% 2 I spoke with Craig and Tony from Norton Computing and it sure ain't their's. I DID run McAfee's SCANV on it, and it came up empty, so either SCANV simply can't recognize it, or it's a prank, but either way, it has no business being in circulation. Be on the look out! To: ALL From: TONY MCNAMARA Subj: Trojan Horse We at Peter Norton Computing would like to bring to your attention an unauthorized trojan horse named NortStop.ZIP or NortShot.ZIP (these files are the same). This file was NOT produced with the knowledge or permission of PNCI. This file is not a virus (it does not infect files). Instead, it is a trojan horse (it must be run explicitly to cause any damage). When run, it lists the directory and claims the system is virus-free. Between December 24th and December 31st, however, it will erase files in several directories based on their extensions. These files can be recognized by their sizes (NortStop.ZIP is 31744 bytes, NortStop.EXE is 38907 bytes), or by doing a text search for the strings "NORTSHOT.EXE" in the ZIP, "Norton Public" in the EXE. If you find or hear of these files, please contact us immediately through Tony McNamara, 213/319-2076 (voice), TMCNAMARA 381-9188 (MCI), or CompuServe (72477,2504). Again, these files are in no way associated with PNCI. Please help us track down and eliminate these files. Thank you, Peter Norton ************** From the Desk of Mr. James M. Vavrina ************** * Comm 703-355-0010/0011 AV 345-0010-0011 * * DDN SDSV@MELPAR-EMH1.ARMY.MIL * ******************************************************************* ------------------------------ Date: Mon, 06 Nov 89 13:19:08 -0500 From: Arthur Gutowski Subject: Previously reported BootChek problems (PC) Regarding a previous couple of postings about problems with BootChek, it appears that the problem is not a bug. Evidently, Jeff has indeed been hit by a virus or system problem of some kind. After re-SYSing the hard drive (from a clean system), and reinstalling BootChek, Jeff says things are back to normal. Since from the information I've obtained, it doesn't seem to be bug-related, we (McConachie Associates--sorry John, but it does have a ring to it) are looking at the other possibilities (maybe a virus? or a system quirk?). More info to come later. I perhaps jumped the gun crying "bug", but hey, my experience as a programmer has taught me to there is only one valid assumption about computing: It's my fault. Murphy's Law works in strange ways... Arthur J. Gutowski, Co-Author of BootChek and +--------------------------------------------------------------------+ | Antiviral Group / Tech Support / WSU University Computing Center | | 5925 Woodward; Detroit MI 48202; PH#: (313) 577-0718 | | Bitnet: AGUTOWS@WAYNEST1 Internet: AGUTOWS@WAYNEST1.BITNET | +====================================================================+ | Rules to live by, #153: | | Never get caught on the wrong side of a Doppler shift. | +--------------------------------------------------------------------+ - ------- End of Forwarded Message ------------------------------ Date: 07 Nov 89 20:01:02 +0000 From: kelly@uts.amdahl.com (Kelly Goen) Subject: Re: Virus source available in Toronto Sorry about the fact you got hurt personally out there in the hinterlands... I should have classified my statement even further... the published "CURRENT" sources are not really that much of a threat to a person experienced in counter- measures against viruses(READ Safe Computing Practices...) and like it or not until more effective protection is put into the silicon itself.. the watchword of the future is be prepared carry computer condoms!!While any virus can be deadly to the unprepared every one of the current day viruses that the CVIA and other organizations and individuals has had the chance to analysize... has been of the short fuse variety... this makes them relatively easy to detect... much greater damage can be done to the security of an organization or a country by using viral techniques to put covert data channels into place... these and other tricks will be the next generation of virii...as far as the present day ... we will always see relatively primitive virii being produced from published \sources... as the publication usually lags the industry by as much as several months it gives vendors who are in tune to this problem several man months of r+d Time for new nostrums... I agree that while some damage is done by sources but robert morrises type doesnt work from published sources... they usually have the skills necessary to bypass that!!About the only sophisticated technique i have seen was in traceback....all else was just standard dos/bios System programming skills needed to implement...the biggest leg up to a budding virii developer are the tsr programming packs with source and various articles and tools on reverse code engineering...so sorry to poke holes in your favorite theorys but we havent seen or detected any more than annoyance viruses from published sources ghost viruses not withstanding...(again I will reiterate for the computer \user unwilling to make the commitment in time and energy to become knowledgeable about safe computer practices these viruses can indeed be deadly but enough sources have been released at this point that the genie really cant be put back in the bottle(I too wish it hadnt happened... but it did and now we have to learn to live with and treat the problem... just like aids in the bay area... one is either knowledgeable or one will be eventually dead!!) same for computers one will either be knowledgeable or... some idiot there will release a virus and throw ones data in the bit bucket... As far as the unsophisticated user who wants to protect well thats what CVIA is there for... cheers kelly p.s. sorry guy but I dont take a hand wringing approach to the problem of published sources...mostly every thing I have seen so far is on a relatively primitive level... i.e. no 1-way decryption... no shadow allocation systems... no memory residence being done by techniques which totally bypass dos and any existing antiviral products...no PSP backtracing and use of obsolete ways into dos!!in other words nothing much more than present day leading edge tools can protect against!!it could easily be a far far worse situation if various government "black" organiztions and/or terrorists and/or Corporate IE (Industrial Espionage) types were to fund underground virus developement for unknown neferious goals .... ------------------------------ Date: 07 Nov 89 20:26:46 +0000 From: kelly@uts.amdahl.com (Kelly Goen) Subject: Re: Where are the Sophisticated Viruses? Jesus you mean someone else out there can think for himself...as far as what you said 100% concurrence...it would turn most even tech types pale to see what a "guru" could put together... fortunately most to date have been of the relatively non-malicious variety...(gurus that is) I work locally here in Silly-Con valley as a Network nerd and various wizard on\ a extremely broad swath of tech areas... anti-viral lab work is a VERY large part of that... I am running 386/pcdos only in protected mode with several layers of antiviral products... my write lines on my drive interfaces have to be explicitly and manually enabled...VM/8086 partitions are used to block direct access to REAL Memory or IO PORTS (And I even feel nervous telling the entire readership of this newsgroup that much) I also encrypt my disks... I cant endorse any products publicly but certain products are a definite step above others...also incrementally backup in the background at extremely frequent intervals AND even I can be HIT Sucessfully..........!!! my net seems to be 99% sucessful so far but knock on wood!!! cheers kelly ------------------------------ Date: Tue, 07 Nov 89 17:09:00 -0600 From: LMCOUNTS%UALR.BITNET@IBM1.CC.Lehigh.Edu Subject: need disinfection info for BRAIN virus (PC) In using Viruscan (version 4.8) the scan found PAKISTANI/BRAIN/ASHAR virus on a number of student diskettes. I check the Homebase BBS and didn't find a disinfection program for these strains. Can anyone suggest a disinfection program and if there's one on the network that I can get? Is running a disinfection program the solution to this/these viri?? Thanks.... Neta Counts ------------------------------ Date: Tue, 07 Nov 89 19:06:28 -0600 From: CA6692%SIUCVMB.BITNET@VMA.CC.CMU.EDU (Vince Laurent - work id) Subject: WARNING: Brain virus infection (PC) Our Computer Centers have been blessed with the return of (c)Brain. We also have recorded cases of the Jerusalem B virus. Both of these have been found by the VIRUSCAN program that was given to our Computing Information Center. I have a VACCINE program for (c)Brain but is there one for the other virus and if so where do I get it or can someone send it to me? Thanks in advance... --------------------------------------------- | Vincent J. Laurent | | Computing Information Center & | | Computer Learning Center 1 | | Southern Illinois University - Carbondale | | CA6692@SIUCVMB | --------------------------------------------- ------------------------------ Date: Tue, 07 Nov 89 16:31:22 +0000 From: biar!trebor@uunet.uu.net (Robert J Woodhead), trebor@biar.UUCP (Robert J Woodhead) Subject: Re: Virus List - Notes (Mac) XRJDM%SCFVM.BITNET@VMA.CC.CMU.EDU (Joe McMahon) writes: >This was simply a convenient name for a particular virus-like code >pattern that Bob Woodhead's "Interferon" program looked for - for >those who are interested, an immediate branch out of CODE 0 to some >other CODE segment. There is no specific virus called SNEAK, and >there never has been. No, what you are describing is the infamous Interferon Anomaly 104. The infection strategy I described as ``sneak'' was changing the type of a common System folder file to INIT. This check was too rigorous and gave false positives when System 6.0 came out because in 6.0 some of the file types changed. You are right : there is no such thing as SNEAK. And Interferon is obsolete now; use Disinfectant or (plug, plug) Virex. - -- Robert J Woodhead, Biar Games, Inc. !uunet!biar!trebor | trebor@biar.UUCP Announcing TEMPORAL EXPRESS. For only $999,999.95 (per page), your message will be carefully stored, then sent back in time as soon as technologically possible. TEMEX - when it absolutely, postively has to be there yesterday! ------------------------------ Date: Tue, 07 Nov 89 22:58:00 -0500 From: HAYES%URVAX.BITNET@VMA.CC.CMU.EDU Subject: excerpts from risks-l digest Following are two excerpts from RISKS-L digest. Enjoy, Cl. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Claude Bersano-Hayes HAYES @ URVAX (Vanilla BITNET) University of Richmond hayes@urvax.urich.edu (Bitnet or Internet) Richmond, VA 23173 ...!psuvax1!urvax.bitnet!hayes (UUCP) --- begin forwarded message --- RISKS-LIST: RISKS-FORUM Digest Tuesday 7 November 1989 Volume 9 : Issue 39 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: * Computer Viruses Attack China (Yoshio Oyanagi) * First Virus Attack on Macs in Japan (Yoshio Oyanagi) Date: Mon, 6 Nov 89 12:15:25+0900 From: Yoshio Oyanagi Subject: Computer Viruses Attack China Ministry of Public Safety of People's Republic of China found this summer that one tenth of the computers in China had been contaminated by three types of computer virus: "Small Ball", "Marijuana" and "Shell", China Daily reported. The most serious damage was found in the National Statistical System, in which "Small Ball" spread in 21 provinces. In Wuhan University, viruses were found in *ALL* personal computers. In China, three hundred thousand computers (including PC's) are in operation. Due to premature law system the reproduction of software is not regulated, so that computer viruses can easily be propagated. Ministry of Public Safety now provides "vaccines" against them. Fortunately, those viruses did not give fatal damage to data. Yoshio Oyanagi, University of Tsukuba, JAPAN ------------------------------ Date: Tue, 7 Nov 89 17:07:09+0900 From: Yoshio Oyanagi Subject: First Virus Attack on Macs in Japan First Virus Attack on Macs in Japan Six Macs in University of Tokyo, Japan, were found to have caught viruses, newspapers and radio reported. Since this September, Prof. K. Tamaki, Ocean Research Institute, University of Tokyo, has noticed malfunctions on the screen. In October, he applied vaccines "Interferon" and "Virus Clinic" to find his four Mac's were contaminated by computer viruses, "N Virus" type A and type B. He then found ten softwares were also infected by viruses. A Mac of J. Kasahara, Earthquake Research Institute, University of Tokyo, was also found to be contaminated by N Virus and Score Virus. Those are the first reports of real viruses in Japan. Later it was reported that four Mac's in Geological Survey of Japan, in Tsukuba, were infected by N Virus Type A. This virus was sent from U. S. together with an editor. Yoshio Oyanagi, University of Tsukuba ------------------------------ End of VIRUS-L Digest ********************* 10-Nov-89 4:54:58-GMT,20511;000000000001 Received: from RUTVM1.RUTGERS.EDU by topaz.rutgers.edu (5.59/SMI4.0/RU1.1/3.04) id AA14214; Thu, 9 Nov 89 23:52:38 EST Message-Id: <8911100452.AA14214@topaz.rutgers.edu> Received: from RUTVM1.RUTGERS.EDU by RutVM1.Rutgers.Edu (IBM VM SMTP R1.2.1MX) with BSMTP id 6739; Fri, 10 Nov 89 00:50:08 EDT Received: from RUTVM1 by RUTVM1.RUTGERS.EDU (Mailer R2.04RU) with BSMTP id 6736; Tue, 07 Nov 89 08:53:09 EDT Date: Tue, 7 Nov 89 07:14:29 EST Reply-To: VIRUS-L@ibm1.cc.lehigh.edu Sender: Virus Discussion List From: "The Moderator Kenneth R. van Wyk" Subject: VIRUS-L Digest V2 #234 Comments: To: VIRUS-L@ibm1.cc.lehigh.edu To: Multiple recipients of list VIRUS-L VIRUS-L Digest Tuesday, 7 Nov 1989 Volume 2 : Issue 234 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: Datacrime report at ERIM followup (PC) Re: Where are the Sophisticated Viruses? Re: Imbeded virus detection Re: 2608- possible virus? (AMIGA) Re: Macintosh Virus List (Mac) dBase and Typo-COM viruses (PC) Re: CRC's SCANV42 and ASHAR Virus (Mac) --------------------------------------------------------------------------- Date: Mon, 06 Nov 89 13:46:07 -0500 From: Arthur Gutowski Subject: Datacrime report at ERIM followup (PC) A couple of weeks back, I posted an article concerning a Datacrime hit at the Environmental Research Institute of Michigan (ERIM). More recent info precludes any correlation of the hit with the discovery of the name Siegmar Schmidt in the partition table. I recieved a message from Leo Stephens (also a subscriber to Virus-L), in which he said that a friend of his had also discovered this name in the partition table. He also had found the name David Litton on some of his machines at work, and others had no name at all. A couple of people who know more about partition tables and editors than I do suggested that it was just the author of the editor taking credit for the program by placing his name there (there is enough unused space in the partition sector to do this harmlessly). All of the other occurences of names have come without any disk problems associated with a virus (McAfee's Scanv46 and IBM's Virscan was used on on the above disks). I guess the moral of the story is to just make sure pertinent data does not change. But, if anyone else can confirm that these names aren't anything too out of the ordinary, it would set my mind (and computer) at ease. Again, my friend at ERIM did get hit by a Datacrime version either by an bum copy of PKZ102.EXE or his FDISK program became infected...Siegmar is innocent. +--------------------------------------------------------------------+ | Arthur J. Gutowski | | Antiviral Group / Tech Support / WSU University Computing Center | | 5925 Woodward; Detroit MI 48202; PH#: (313) 577-0718 | | Bitnet: AGUTOWS@WAYNEST1 Internet: AGUTOWS@WAYNEST1.BITNET | +====================================================================+ | "To do is to be." -Socrates "To be is to do." -Plato | | "Do-bee do-bee do." -Sinatra "Yabba dabba doo." -Fred Flintstone| +--------------------------------------------------------------------+ ------------------------------ Date: Mon, 06 Nov 89 20:54:24 +0000 From: madd@world.std.com (jim frost) Subject: Re: Where are the Sophisticated Viruses? CHESS@YKTVMV.BITNET (David.M..Chess) writes: >You're forgetting one important kind of virus detector: a >general modification-detector that does a check-code of some >kind (CRC, MDC, or whatever), and alerts the user when >a file's *contents* (not the date) change. >I think even >a virus that talked straight to the hardware to avoid >"suspicious activity" detectors wouldn't get far before >it was detected. DC Sigh. We're lucky that no very competent programmer has tried to write a virus, all right. Consider that there are three phases to any virus, not including side-effects such as damaging data: 1) infection 2) propagation 3) survival A sophisticated virus spends almost all of its time surviving, so it's the most interesting stage. Survival traits include: * limiting propagation rates * limiting re-infections * detecting and avoiding "virus-protected" hosts * staying within normal system activity boundaries * hiding from standard system utilities * modifying hosts to make them more susceptible to re-infection There are a lot more things that a sophisticated virus can do, but these are food for thought. Let's examine them in more detail. Limiting Propagation Rates. Simple viruses, and often not-so-simple ones, will proliferate without bounds. Rampant proliferation will cause the virus to be noticed early in its lifetime and will probably lead to its early demise. The internet worm did not do this. Limiting Re-Infections. Most simple viruses don't detect systems which have already been infected and will re-infect them. Such viruses will incrementally eat system resources until they are noticed. The internet worm did not do this. Detecting and Avoiding "Virus-Protected" Hosts. I have yet to see a virus which looked at the state of a system to detect virus detection mechanisms to nullify them and/or avoid infecting them. There are a variety of simple ways which a virus could do this, especially on PC-based systems where hardware and software is extremely standard. A virus which did this might go undetected forever. Of course it's possible that such a beastie exists and is undetected. Even CRC detectors will not detect a properly written virus which avoids systems with CRC detection mechanisms! Staying Within Normal System Activity Boundaries. Some viruses will actively search devices which a user did not request activity from; this activity will often be noticed. A good many Apple II viruses had this trait, and so did the internet worm. It leads to early detection. Hiding From Standard System Utilities. A sophisticated virus would avoid showing anomalies when the system is perused with standard system utilities such as those which display currently active processes, memory or disk usage, etc. Given the primitive state of many PC operating systems, this capability is seldom needed, and it's easy to remain unnoticed on larger systems without any effort at all. The internet worm had some of these avoidance techniques which made it much harder to track down. Modifying Hosts To Make Them More Susceptible To Re-Infection. A very sophisticated virus could make subtle changes to an operating system or operating system environment to make it easier to re-infect. This capability is generally useless amongst PCs but it's extremely easy to make small modifications to many multiuser systems -- particularly UNIX -- to make re-infection trivial. I believe a recent VMS virus did this by adding a user, although I'm not certain of that. [Ed. The DECnet WANK worm did indeed add (or alter an existing) username, FIELD. It also modified .COM files (which are shell scripts on VMS, similar to MS-DOS .BAT files) to do the same if run from a privileged account. Making any such changes to MS-DOS PCs would seem redundant, IMHO.] By now you should get the idea that almost every virus we've seen is primitive, although several showed some of the survival traits which I outline above. Given the limited resources of PC environments, it's unlikely that you'll get a very sophisticated virus. The internet worm was itself only sophisticated at infection; propagation and survival techniques were woefully inadequate, although they need not have been because the infected hosts could have supported a much more sophisticated virus. This is food for thought, but should give you an idea of just how tough a virus could actually be. Count our blessings now because you won't believe how bad tomorrow's nightmares will be unless we start teaching ethics to tomorrow's programmers! jim frost madd@std.com ------------------------------ Date: Sat, 03 Nov 89 14:47:35 +0000 From: rwallace@vax1.tcd.ie Subject: Re: Imbeded virus detection PSYMCCAB@UOGUELPH.BITNET (Bob McCabe) writes: > As a consultant who writes software for the PC I am worried > about the possibility of my programs getting infected and > becoming vectors by which viri are spread. > In particular I am developing an application that will be hand > carried from site to site to gather data by a number of users. If > this program were to get infected it could cause wide spread loss > of data to an important research project, not to mention other > programs and data on affected systems. I am looking at including > a check to see if there has been any change in the EXE files. > Failure on such a check would cause the program to disable it's > self and report a possible infection. Easy enough to do: just have something like this (in C): main (argc,argv) { if (crc_check (argv[0])!=ORIGINAL_CRC_VALUE) { printf ("Virus infection - now committing suicide!\n"); unlink (argv[0]); exit (20); } ... } ok so you probably wouldn't want the program to actually commit suicide but it looks good. Only problem is entering the original CRC value as a constant because putting in the value into the program would change the executable file and thereby the value ... maybe have some unused static data you change the value of to compensate and make the total CRC unchanged. "To summarize the summary of the summary: people are a problem" Russell Wallace, Trinity College, Dublin rwallace@vax1.tcd.ie ------------------------------ Date: Mon, 06 Nov 89 12:05:32 +0000 From: rwallace@vax1.tcd.ie Subject: Re: 2608- possible virus? (AMIGA) n8735053@unicorn.wwu.edu (Iain Davidson) writes: > Well, while up in Vancouver, BC at an Amiga Users Group meeting, a > interesting thing was demostrated..... > > I call it the "2608" virus. (don't know the offical name). > > It worked like the IRQ virus attaching itself to the first executable in > the startup-sequence. But with a slight twist. It would copy the > found executable to devs:" " and copy itself into the old name in > the "C" directory (size 2608 bytes). Sounds like BGS-9. Make sure you don't leave any copies on any working disks because the version of BGS-9 I found trashes sectors of your floppies. "To summarize the summary of the summary: people are a problem" Russell Wallace, Trinity College, Dublin rwallace@vax1.tcd.ie ------------------------------ Date: Sun, 06 Nov 89 04:28:04 +0000 From: , robert@polari.UUCP (robert) Subject: Re: Macintosh Virus List (Mac) > Recently I have been writing an article on Macintosh infections. In > writing the article I tried to compile an exhaustive list of Macintosh > viruses. Below is the list. If anyone has anything to add to the list > I would appreciate them notifying me so I can update the list. Thanks > much! Your list includes "SNEAK" and "San Jose Flu". I've never heard of the "San Jose Flu". Could you furnish more information about this one? The "SNEAK" is not a Macintosh virus. This is apparently a generic term (like "Trojan Horse" or "Time Bomb") for a type of virus. All uses of the term "SNEAK" that I have seen trace back to Robert Woodhead, the author of the Macintosh anti-virus program Interferon, and I suspect that Robert coined the term himself. The documentation for Interferon defines a "SNEAK" as follows: 003 A SNEAK virus. This is a virus that adds it's code to a common System folder file and changes it's type to INIT so that it is run at boot time. Type 003 is a generic "Virus sniffer" that detects if common System folder files have been adulterated in this way. If you get a type 003 virus, please get in contact, you may have discovered a new strain. Interferon was one of the first Mac anti-virus programs and was, at the time, an excellent (and free) virus detection program (though it should NOT be used for virus removal!). The intent of the author was, apparently, to provide checks for possible future viruses. Unfortunately, some software that was released after Interferon tended to trigger this generic virus check. The result was that Interferon would report a "SNEAK virus" in cases where no virus actually existed. Early versions of Interferon found "SNEAK virus" in the LaserWriter and LaserPrep files that were part of later system software releases from Apple. Even Interferon 3.1, which is the latest version of Interferon I have seen (dated May 16, 1988), reported the "SNEAK virus" in TOPS version 2.1. These early attempts by Interferon to detect unknown viruses with generic checks bring out the dangers of such an approach. I get the impression that the author of Disinfectant, John Norstad, has taken a more conservative approach and checks only for KNOWN virus entities (resources and files). I imagine that Robert Woodhead has taken a similar approach with Virex, his newer commercial anti-virus program (replacing Interferon), though I haven't had an opportunity to see Virex. --------------------------------------- Robert Riebman robert@polari Northwest Information Technology P.O. Box 3156 Redmond, WA 98073 ======================================== ------------------------------ Date: 06 Nov 89 20:45:07 +0000 From: frisk@rhi.hi.is (Fridrik Skulason) Subject: dBase and Typo-COM viruses (PC) Alan J Roberts writes: > > A number of folks have looked at the DBASE virus (Ross >Greenberg's discovery), including Joe Hirst, Steffan Campbell and T.B. >Allen, and the general consensus is that the virus is very similar in >style to the TYPO virus (The COM version). If the author of these two >viruses is one and the same person, then perhaps the DBASE author has >not completely been "re-habilitated" as Ross Greenberg has suggested. I must disagree. The dBase and Typo-COM viruses are similar in some ways, but there are also quite a few differences. Similarities: 1) Both viruses use an identical, but very unusual, method to transfer control back to the original program: MOV AX,100 JMP AX 2) Both viruses infect files with names ending in .COM, instead of checking the first two bytes to determine the type of the file. They will not infect .EXE files. 3) The viruses use similar methods to determine if the system is alredy infected - defining new interrupt subfunctions. dBase: Typo-COM: MOV AX,FB0A XOR AL,AL INT 21 MOV AH,DD CMP AX,0AFB INT 16 JE infected CMP AL,AH JE not_infected Differences: 1) Typo-COM will search for programs to infect, looking for *.COM files in the current directory. The dBase virus will infect a program when it is executed. 2) Typo-COM will install itself in memory when the infected program terminates, (by using DOS functions 0 or 4C, or by a INT 20 call). dBase will install itself as soon as it has determined that it is not already present in memory. 3) The code used to hook INT 21 is very dissimilar, the dBase virus using DOS functions, but Typo-COM using direct manipulation. dBase: Typo-COM: MOV AX,3521 MOV AX,[84] INT 21 : : MOV [84],SI : SUB [84],98 MOV DS,DX : MOV DX,new_21 MOV AX,[86] MOV AX,2521 : INT 21 PUSH CS POP [86] 4) dBase hooks INT 21 when it is first executed. Typo-COM hooks INT 21, INT 20 and INT 16 at the same time, but when it installs itself in memory it restores INT 21 and INT 20. 5) The "install in memory" procedure is VERY different. The dBase virus manipulates the MCB directly, in a way similar to the method used by the Icelandic virus. It will then transfer itself upwards in memory. Typo-COM will transfer itself down, overwriting the original infected program, as soon as the program exits (see [2] above.) 6) Finally: The Typo-COM is a "harmless" virus, meaning that it does no direct, permanent damage, like destroying data or formatting the hard disk. It contains a generation counter, but it does not seem to be used (reserved for future expansion ?) All it does is to produce a "typing error" every now and then. It is therefore in the "joke" category, along with Cascade, Ping-Pong and a few other viruses. The dBase virus is quite different. It will garble data when it is written and restore it when it is read back. If the system is not infected at the time, the data will be useless. This also applies if the virus is removed. But, if the file has not been written to for three months when it is read, the virus will do serious damage, erasing the first 100H sectors on drive D: E: .... Z: - or at least it was designed to do so. The author forgot one small detail, which will make the destruction rather unpredictable. This is a clear difference in attitude, which does not support the theory that the viruses have the same author Comments, anyone ? - -frisk Fridrik Skulason University of Iceland frisk@rhi.hi.is Computing Sevices Guvf yvar vagragvbanyyl yrsg oynax ................. ------------------------------ Date: Mon, 06 Nov 89 22:48:39 +0000 From: kichler@harris.cis.ksu.edu (Charles Kichler) Subject: Re: CRC's > A CRC will work if you: > (1) Keep the polynomial secret and personal. > (2) Keep the comparison information secret and > personal. I don't think this is fool-proof. The problem is that the polynomial and the comparison information must be known to the program. Therefore, if you know where to look IN THE PROGRAM, then you could find the information. I believe the only iron-clad method might be a hardware device which could verify a programs "health". I imagine it to be device akin to those that attach to the serial port of a computer for copy protection. The advantage is hardware is difficult to modify via software. As of yet, I haven't seen a program that can beat a write protect tab. Charles "chuck" E. Kichler, Intro. to PC Instructor/Co-ordinator Computer & Info. Science Kansas State Univ. * Yesterday, Internet: kichler@harris.cis.ksu.edu | I knew the answers. BITNET: kichler@ksuvax1.bitnet * Today, UUCP: {rutgers,texbell}!harris!kichler | they changed the questions. ------------------------------ Date: Mon, 06 Nov 89 16:33:01 -0800 From: portal!cup.portal.com!Alan_J_Roberts@Sun.COM Subject: SCANV42 and ASHAR Virus (Mac) Tom Sheriff noted in a recent Virus-L listing that SCANV42 displays an unusual virus number and appears to show both the ASHAR and the BRAIN virus whenever the BRAIN virus is encountered. The duplicate virus messages were caused by new strings added to version 42, fixed in V44. The "1d viruses found" message has also been fixed in version 44. (The "d" was an extraneous character caused by the duplicate strings). Alan ------------------------------ End of VIRUS-L Digest ********************* 10-Nov-89 8:49:07-GMT,9729;000000000001 Received: from RUTVM1.RUTGERS.EDU by topaz.rutgers.edu (5.59/SMI4.0/RU1.1/3.04) id AA20418; Fri, 10 Nov 89 03:46:55 EST Message-Id: <8911100846.AA20418@topaz.rutgers.edu> Received: from RUTVM1.RUTGERS.EDU by RutVM1.Rutgers.Edu (IBM VM SMTP R1.2.1MX) with BSMTP id 1845; Fri, 10 Nov 89 04:41:12 EDT Received: from RUTVM1 by RUTVM1.RUTGERS.EDU (Mailer R2.04RU) with BSMTP id 7780; Mon, 06 Nov 89 15:42:38 EDT Date: Fri, 3 Nov 89 09:55:11 EST Reply-To: VIRUS-L@ibm1.cc.lehigh.edu Sender: Virus Discussion List From: "The Moderator Kenneth R. van Wyk" Subject: VIRUS-L Digest V2 #230 Comments: To: VIRUS-L@ibm1.cc.lehigh.edu To: Multiple recipients of list VIRUS-L VIRUS-L Digest Friday, 3 Nov 1989 Volume 2 : Issue 230 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: CRC checking Re: Checksum programs Re: Self-checking programs (PC) Re:Virus source available in Toronto DBASE Virus and SCANV47 (PC) decompiling a virus --------------------------------------------------------------------------- Date: Wed, 01 Nov 89 00:00:00 +0000 From: "Prof Arthur I. Larky" Subject: CRC checking A CRC will work if you: (1) Keep the polynomial secret and personal. (2) Keep the comparison information secret and personal. You can accomplish (1) by having the checker ask for the polynomial (or some portion of it) when you boot up and start the checking. The checker should NOT store the polynomial on disk anywhere. You can accomplish (2) by having the checker ask for the check file name and/or path when you boot up and start the checking. Both of these are a pain to do, but losing everything on your hard drive is much more of a pain. Of course, you should still do regular backups (I do lots of program development, so I back up everything on floppy as soon as I create it) and have someone's program watching your disk for you. The basic rule is: Be Different! MSDOS is vulnerable because it is so well-known how to write lethal things to disk. If you name your checksum file "Checksum.fil", you are looking for trouble! I know I can find a name and a sub-directory for it that I wouldn't recognize a month later. Art CSEE Dept Lehigh University Bethlehem, PA Disclaimer, disclaimer, disclaimer ------------------------------ Date: 01 Nov 89 20:53:10 +0000 From: len@csd4.csd.uwm.edu (Leonard P Levine) Subject: Re: Checksum programs kerchen@iris.ucdavis.edu (Paul Kerchen) writes: > This point brings up a problem which is common to most checksumming > solutions: where does one store these checksums and their keys? If > they are stored on disk, they are vulnerable to attack just like > programs. That is, a virus could infect the program and then update > its checksum, since the key must be somewhere on disk as well (unless > the user enters it every time they compute a checksum--yecch!) and one > must assume that the checksum algorithm is known. The checksum program and the checksum should be stored in a place that is different on each machine. Furthermore, there is no special "best" crc or testing algorithm, many will do with varying polynomials. A satisfactory system is one in which each user can use a polynomial of his/her choice and where the list of files and their crc's (for example) is stored in some arbitrary location. No virus writer will be looking for YOU, rather just a collection of systems that are alike enough to infect. When dutch elm disease comes around, you should look like an oak tree. Be different enough so that only a specific attack can defeat your defences, not just some attempt to infiltrate command.com. + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + | Leonard P. Levine e-mail len@evax.cs.uwm.edu | | Professor, Computer Science Office (414) 229-5170 | | University of Wisconsin-Milwaukee Home (414) 962-4719 | | Milwaukee, WI 53201 U.S.A. FAX (414) 229-6958 | + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + ------------------------------ Date: 02 Nov 89 02:02:35 +0000 From: berman-andrew@YALE.EDU (Andrew P. Berman) Subject: Re: Self-checking programs (PC anti-virus protection) In article <0006.8911011255.AA25780@ge.sei.cmu.edu> leif@ambra.dk (Leif Andrew Rump) writes: >If a virus killer can patch a program so can a virus! Exactly as virus >detectors is able to find a virus by looking at the code so is the >virus able to detect the virus killer and disable it! That's life!! I wonder if that's actually the case. Consider that most of the virus' created so far have been under 3 kilobytes. A virus must be somewhat small to avoid detection- a 40k patch to every program could be detected visually by the user with a 1 meg floppy disk. Perhaps a very complex virus killer could patch a program in such a way that only a very complex virus could unpatch it- a patching algorithm X with a proof on the order of "patch algorithm X cannot be unpatched by a program with less than 100k" or something like that might do some good. Or, perhaps we could design patches that might be unpatchable by a short virus, but would take a great deal of time. We're not really too concerned about length of time it takes to patch, since that only would occur once for each program. Thus, a patching algorithm X which can be proven to be computationally-hard to unpatch would be effective because the virus might be required to take up a great deal of computer time, again providing a means to alert the user. Frankly, I find the stuff fascinating... I think there's some theoretical computing issues involved here, but hey, what do I know, I'm only a grad student. Andrew P. Berman berman@yale.edu ------------------------------ Date: Thu, 02 Nov 89 18:47:07 +0100 From: fbihh!swimmer@uunet.UU.NET (Morton Swimmer) Subject: Re:Virus source available in Toronto kelly@uts.amdahl.com (Kelly Goen) writes: >Yes it is indeed true that viral sources are published in several >areas... however "Viruses , A high Tech disease" published only >overwriting viruses!! more similar to a logic bomb as when they infect >the target executable the file is immediately destroyed(VERY EASY to >detect) by the overwriting process. However any COMPETANT Assembly >coder can manufacture far more unobtrusive viruses if he just thinks >about it!! the published sources working or non working are really not >that much of a threat... Oh yes they are! It is very much easier to start from a working source than to start from scratch. Irrespective if you are "competant" or not. Just take the source, think of something and implement it. It will take you far less time, and the inhibition is far less. This is exactly what happened to one of the viruses published in R**** B*****'s book. Not long afterwards, presto! we had the Vienna (648) virus! Granted, its just a small chip off the block, but you must try everything to win this war. Cheers, Morton ------------------------------ Date: Thu, 02 Nov 89 15:09:50 -0800 From: portal!cup.portal.com!Alan_J_Roberts@Sun.COM Subject: DBASE Virus and SCANV47 (PC) A number of folks have looked at the DBASE virus (Ross Greenberg's discovery), including Joe Hirst, Steffan Campbell and T.B. Allen, and the general consensus is that the virus is very similar in style to the TYPO virus (The COM version). If the author of these two viruses is one and the same person, then perhaps the DBASE author has not completely been "re-habilitated" as Ross Greenberg has suggested. If this is the case, then the DBASE virus may have been placed into the public domain (and would indeed account for the inexplicable DBASE problem reports that have been received over many months by the CVIA). Accordingly, SCAN V47 has been updated to include a check for this virus. Better safe than sorry. Alan ------------------------------ Date: Thu, 02 Nov 89 22:30:19 -0800 From: ames!dhw68k.cts.com!stein@apple.com (Rick 'Transputer' Stein) Subject: decompiling a virus I just finished reading "With Microscope and Tweezers: An Analysis of the Internet Virus of Nov. 1988" by Eichin and Rochlis in the Proceedings of the 1989 IEEE Symposium on Security and Privacy. They discuss the decompilation process but only in a vague sense. What is decompilation? Do you actually have to take apart a core dump, find the opcodes, operands, and build a hi-level pseudocode from this? Is there an automated tool, or hunk of software which decompiles images for you? How do you detect a virus in core with a "process interagator" if something like this exists. - --rick ------------------------------ End of VIRUS-L Digest ********************* 10-Nov-89 9:20:47-GMT,13863;000000000001 Received: from RUTVM1.RUTGERS.EDU by topaz.rutgers.edu (5.59/SMI4.0/RU1.1/3.04) id AA20916; Fri, 10 Nov 89 04:18:45 EST Message-Id: <8911100918.AA20916@topaz.rutgers.edu> Received: from RUTVM1.RUTGERS.EDU by RutVM1.Rutgers.Edu (IBM VM SMTP R1.2.1MX) with BSMTP id 2252; Fri, 10 Nov 89 05:15:35 EDT Received: from RUTVM1 by RUTVM1.RUTGERS.EDU (Mailer R2.04RU) with BSMTP id 8095; Mon, 06 Nov 89 16:29:32 EDT Date: Fri, 3 Nov 89 15:30:27 EST Reply-To: VIRUS-L@ibm1.cc.lehigh.edu Sender: Virus Discussion List From: "The Moderator Kenneth R. van Wyk" Subject: VIRUS-L Digest V2 #231 Comments: To: VIRUS-L@ibm1.cc.lehigh.edu To: Multiple recipients of list VIRUS-L VIRUS-L Digest Friday, 3 Nov 1989 Volume 2 : Issue 231 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: Brain Virus info needed (PC) Jerusalem Virus (PC) Re: Checksum programs WANK Antidote (VAX/VMS/DECnet) Virus Invasion of Hardware? Macintosh Virus List (Mac) Identify Ashar Virus re: VGA2CGA infected with virus? (PC) --------------------------------------------------------------------------- Date: Fri, 03 Nov 89 10:01:04 -0600 From: Mitch Cottrell Subject: Brain Virus info needed (PC) Help Help Help We have been infected with two virus strains... Jeruslum-B and Pakastani Brain... I have gotten some information on Jeruslium... but have not been able to get any info on brain other than how it replicates itself.. I still dont know what system damage it can do other than eat up a couple sectors of disk space. Please let me know if you have any info on this virus or a source for info. ps. I have already tried McAfee Associates BBS. Thanks... Acknowledge-To: ------------------------------ Date: Fri, 03 Nov 89 24:41:00 -0500 From: "Chris_C.Conner" <13501CCC%MSU.BITNET@IBM1.CC.Lehigh.Edu> Subject: Jerusalem Virus (PC) The computers(PC) in many of the labs on campus(MSU) have been struck by the Jerusalem Virus. I used SCAN.EXE (I don't know what version) and identified it as the Jerusalem Virus. Irealize there have been quite a few articles about it in the recent digests, but thinking I was not susceptible, I didn't bother reading any of them. Could someone please send me any information on what the virus does, what I can do to get rid of it, and any other shareware that could help out. CCC ------------------------------ Date: 03 Nov 89 17:44:32 +0000 From: kerchen@iris.ucdavis.edu (Paul Kerchen) Subject: Re: Checksum programs In article <0002.8911031455.AA13850@ge.sei.cmu.edu> len@csd4.csd.uwm.edu (Leona rd P Levine) writes: >The checksum program and the checksum should be stored in a place that is >different on each machine. Furthermore, there is no special "best" >crc or testing algorithm, many will do with varying polynomials. True, but the checksum program must have some way of knowing what these algorithms are and where the checksums are stored. If the `sum program can find these things, so can a virus. If the `sum program must be told where these things are then there is no problem; the virus cannot find the info it needs because it isn't on the system. However, that could become tedious for administrators who oversee tens or hundreds of machines, detracting them from their real work. >A satisfactory system is one in which each user can use a polynomial >of his/her choice and where the list of files and their crc's >(for example) is stored in some arbitrary location. No virus writer >will be looking for YOU, rather just a collection of systems that >are alike enough to infect. Again, where are these polynomials stored? One must keep this fact in mind: a virus can do anything a legitimate program can do. A "good" virus will be able to adapt to minor changes in systems and find out where these things are hidden. I don't mean to play the devil's advocate here, but I think it's important to realize that no solution will be a 100% solution. There are a lot of people who read this newsgroup, some of whom may not realize this point, and it always pains me to hear about someone who invested all of their trust into some vaccine, only to get burned by the next virus to come down the pike; they didn't realize the complexity of the problem and jumped right on to someone's bandwagon. Folks have to realize that all of the vaccines, filters, shields, latest & greatest methods, etc., will only slow viruses down; they won't stop them. Of course, if the resposible computing community can make it so difficult for the degenerate virus writers to make a living, perhaps those degenerates will find something else to occupy their time, like making crank calls or torturing small woodland animals. Paul Kerchen | kerchen@iris.ucdavis.edu ------------------------------ Date: Fri, 03 Nov 89 13:10:39 -0500 From: TBUTLER@NSSDCA.GSFC.NASA.GOV Subject: WANK Antidote (VAX/VMS/DECnet) *********** WANK WORM VACCINE ************** A vaccine to combat the WANK worm has been developed by Bernard Perrot of the Institut de Physique Nucleaire, Orsay, France. The vaccine consists of creating a bogus file which you put in SYS$SYSTEM:RIGHTSLIST.DAT. When the worm tries to use the information in this file, the worm-code generates errors and blows up causing the attacking worm to die. The vaccine does NOT affect the remote system - it only kills the worm. This vaccine will stop attacks from any attacking nodes, it should therefore greatly reduce the "annoyance level" of attacks by reducing the volume of audit trails. ******************* IMPORTANT IMPORTANT IMPORTANT *********************** PLEASE READ!!! THIS VACCINE WILL ONLY WORK AGAINST **CURRENT** STRAINS OF THE WORM. WE BELIEVE HOWEVER THAT TO ELIMINATE THIS WORM FROM THE NETWORK, THIS TECHNIQUE WILL HAVE TO BE USED ON AS MANY SYSTEMS AS POSSIBLE. IT IS THE ONLY WAY TO ATTACK THE WORM AT IT'S SOURCE (short of system management action on the infected node...and a lot of system managers are either asleep, ignorant, lazy or??? and therefore the worm has been running on some systems for days). ****************************************************************************** This method has been tested on VMS 4.7 thru VMS 5.2 systems. In order to correctly implement this fix, the following steps must be performed: 1) If you have previously implemented any of our suggestions regarding file protection or ACL's on RIGHTSLIST.DAT, it is necessary to undo them restoring SYS$SYSTEM:RIGHTSLIST.DAT to its original configuration. 2) RENAME the file SYS$SYSTEM:RIGHTSLIST.DAT to some other name of your choosing. 3) To make VMS operate correctly with the rightslist file in a new location, issue the following command, and also add it to your system startup procedure: $DEFINE/SYSTEM/EXEC RIGHTSLIST The worm won't find the file because it can't translate the logical symbol. 4) Take the 4-line file listed below, protect it W:R and do not put an ACL on it. Name it SYS$SYSTEM:RIGHTSLIST.DAT. You *WANT* the worm to access this file! Users on your system will translate the system logical RIGHTSLIST and things will work correctly. When an infected system attacks your node, the first thing it does is copy your sys$system:rightslist.dat file and tries to get your local usernames. This dummy file will cause the attacking worm to abort with a fatal error when it tries to use the information it finds in the bogus file. If you have followed each of the above steps, VMS will run normally, and you will not be vulnerable to the CURRENT strains of the worm which are running aroung the network. The following file should be copied into SYS$SYSTEM:RIGHTSLIST.DAT exactly as it appears below: - -------------------------- CUT HERE - RIGHTSLIST.DAT ----------------- DUMMY MAINTENANCE RECORD 0123456789012345"'F$PID(ON) 0123456789012345'F$PID(ON) 0123456789012345BATCH - --------------------------- CUT HERE ---------------------------------- John McMahon of NASA/GSFC Advanced Data Flow Technology Office has created a command procedure that will have the same end-result as the above instructions. It is available by copying WANK_SHOT.COM from NSSDCA::WANK_SHOT.COM or 6277::WANK_SHOT.COM. This command procedure uses a modification of the above procedure using a SET FILE/ENTER command to set up an alias for RIGHTSLIST.DAT rather than the RENAME command above. Knowledgable system managers may want to decide for themselves which version they prefer. Todd Butler Ron Tencati SPAN/GSFC Routing Center Manager SPAN Security Manager (301)286-7251 (301)286-5223 6277::Tbutler or NSSDCA::tbutler 6277::Tencati or NSSDCA::Tencati ------------------------------ Date: Fri, 03 Nov 89 13:38:54 -0500 From: "Gregory E. Gilbert" Subject: Virus Invasion of Hardware? Is it possible to write a virus that will invade hardware? Has it been done? Just curious. Gregory E. Gilbert Computer Services Division University of South Carolina Columbia, South Carolina USA 29208 (803) 777-6015 Acknowledge-To: ------------------------------ Date: Fri, 03 Nov 89 13:50:53 -0500 From: "Gregory E. Gilbert" Subject: Macintosh Virus List (Mac) Recently I have been writing an article on Macintosh infections. In writing the article I tried to compile an exhaustive list of Macintosh viruses. Below is the list. If anyone has anything to add to the list I would appreciate them notifying me so I can update the list. Thanks much! ================================= CUT HERE ================================== Macintosh Infections - ---------------------- There are about eight Macintosh infections that are known at present (a list of infections and the years in which they first appeared can be seen in the following table). - ------------------------------------------------------------ Infection Strains Clones - ---------- ------- ------ Scores(Spring 1988)* nVir(Early 1988) nVir A(?) nVir B(?) Hpat(Late 1988) AIDS(Late 1988) MEV#(March 1989)) nFLU(August 1989) INIT 29(Late 1988) ANTI(Early 1989) MacMag(December 1987)** Dukakis(Early 1988?) SNEAK(?) San Jose Flu(?) - ------------------------------------------------------------ * - also known as the NASA virus ** - also known as the Drew Virus, Brandow Virus, and the Peace Virus ================================== AND HERE ================================= Gregory E. Gilbert Computer Services Division University of South Carolina Columbia, South Carolina USA 29208 (803) 777-6015 Acknowledge-To: ------------------------------ Date: Fri, 03 Nov 89 14:41:00 -0500 From: SHERIFF@steffi.acc.uncg.edu Subject: Identify Ashar Virus We encountered a boot sector virus yesterday that we have not seen, can anyone help with identification and explanation? The virus has only been identified on disks that also contain the Pakistani Brain Virus. Further, we have only seen it on three diskettes, thus far. When we run Viruscan 0.7V42 on an infected disk, here is what we see: " Found Pakistani Brain Virus in boot sector. Found Ashar Virus in boot sector. Disk B: contains 1 directories and 5 files. ld viruses found. " Please also observe that the number of viruses found is oddly noted. I have only noticed that phenomenon when the Ashar virus has been identified. Light shed by anyone concerning this virus would be greatly appreciated. Tom Sheriff Microcompuer Support Manager UNC Greensboro - Greensboro, NC SHERIFF@UNCG.BITNET SHERIFF@STEFFI.ACC.UNCG.EDU ------------------------------ Date: 01 Nov 89 15:16:07 -0500 From: "David Chess" Subject: re: VGA2CGA infected with virus? (PC) I have a sample of this thing (or what I assume is the same thing) now; it seems to be a rather silly overwriting-virus (that is, rather than arranging to execute more or less silently before the victim, it simply arranges to execute *instead of* the victim; the victim code, at least much of it, no longer exists). It also seems to be written in a Borland language, perhaps Turbo Pascal. It's very possible that it's based on the Turbo Pascal overwriting-virus "Number One", source for which was published in the Burger book "Computer Viruses, a high-tech disease". I haven't taken it apart enough to know, for instance, what damage if any it does, or when it prints its message; it's hard to reverse-compile compiler output, and this virus isn't likely to spread very far (since an infected file is obviously infected, in that it doesn't do what it used to...). DC ------------------------------ End of VIRUS-L Digest ********************* 10-Nov-89 12:47:35-GMT,13787;000000000001 Received: from RUTVM1.RUTGERS.EDU by topaz.rutgers.edu (5.59/SMI4.0/RU1.1/3.04) id AA23483; Fri, 10 Nov 89 07:47:25 EST Message-Id: <8911101247.AA23483@topaz.rutgers.edu> Received: from RUTVM1.RUTGERS.EDU by RutVM1.Rutgers.Edu (IBM VM SMTP R1.2.1MX) with BSMTP id 3977; Fri, 10 Nov 89 08:47:10 EDT Received: from RUTVM1 by RUTVM1.RUTGERS.EDU (Mailer R2.04RU) with BSMTP id 0887; Mon, 06 Nov 89 18:56:02 EDT Date: Mon, 6 Nov 89 07:11:12 EST Reply-To: VIRUS-L@ibm1.cc.lehigh.edu Sender: Virus Discussion List From: "The Moderator Kenneth R. van Wyk" Subject: VIRUS-L Digest V2 #232 Comments: To: VIRUS-L@ibm1.cc.lehigh.edu To: Multiple recipients of list VIRUS-L VIRUS-L Digest Monday, 6 Nov 1989 Volume 2 : Issue 232 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: Missing 200K Trojan Horse? (PC) The Brain Virus (PC) Virus List - Notes (Mac) Digital signatures for virus protection Re: Greg Gilbert's virus list (Mac) Re: Identify Ashar Virus Re: Identify Ashar Virus Morris to be tried --------------------------------------------------------------------------- Date: Fri, 03 Nov 89 14:03:35 -0500 From: Peter Jaspers-Fayer Subject: Missing 200K Trojan Horse? (PC) I know this is probably not a virus (SCANV45 does not see anything), but it DID seem to migrate from one PC to another. What happened was that someone called me saying that they were missing about 200K of RAM, even after disabling CONFIG.SYS & AUTOEXEC.BAT. He reported that re-SYS-ing the HD fixed the problem, and we closed it... But then someone (who had been trading CD-ROM software with the 1st guy) complained about exactly the same symptoms. I managed to grab a copy of the DOS startup files, and found only ONE difference between the IBMDOS.COM on their HD and the one on the original DOS 3.1 diskette. 3 bytes were changed. DEBUG output follows: - -N IBMDOS.HD * This is the hidden file Ibmdos.com on the hard disk. - -L - -D 6AC0 303F:6AC0 03 8B 37 43 43 26 88 56-00 26 88 76 01 53 51 52 ..7CC&.V.&.v.SQR 303F:6AD0 E8 41 B0 26 B8 00 20 36-3B 06 36 00 76 04 36 A3 .A.&.. 6;.6.v.6. 303F:6AE0 36 00 5A 59 5B 8C D8 5E-1F 26 89 76 12 26 8C 5E 6.ZY[..^.&.v.&.^ 303F:6AF0 14 1E 56 FE C6 FE C2 8E-D8 83 C5 20 E2 C3 5E 1F ..V........ ..^. - -U 6AD0 303F:6AD0 E841B0 CALL 1B14 303F:6AD3 26 ES: 303F:6AD4 B80020 MOV AX,2000 <----------- Huh? 303F:6AD7 36 SS: 303F:6AD8 3B063600 CMP AX,[0036] 303F:6ADC 7604 JBE 6AE2 - -Q - -N IBMDOS.FPY * This is the hidden file Ibmdos.com on the original floppy - -L - -D 6AC0 303F:6AC0 03 8B 37 43 43 26 88 56-00 26 88 76 01 53 51 52 ..7CC&.V.&.v.SQR 303F:6AD0 E8 41 B0 26 8B 46 02 36-3B 06 36 00 76 04 36 A3 .A.&.F.6;.6.v.6. 303F:6AE0 36 00 5A 59 5B 8C D8 5E-1F 26 89 76 12 26 8C 5E 6.ZY[..^.&.v.&.^ 303F:6AF0 14 1E 56 FE C6 FE C2 8E-D8 83 C5 20 E2 C3 5E 1F ..V........ ..^. - -U 6AD0 303F:6AD0 E841B0 CALL 1B14 303F:6AD3 26 ES: 303F:6AD4 8B4602 MOV AX,[BP+02] <----------- Huh ? 303F:6AD7 36 SS: 303F:6AD8 3B063600 CMP AX,[0036] 303F:6ADC 7604 JBE 6AE2 - -Q - ------------------------------------------------------------------------- I do not have any idea how the file got changed. The date-stamps were changed (in both cases). The attribute flags (Sys, R/O, Hidden, Arch all set) were not changed. SOMETHING re-wrote 3 bytes of IBMDOS.COM, even though it was R/O, and the write was such that the date-stamp was changed to the current date. As far as we can tell, the missing 200K was the only symptom. The CD-ROM stuff they were working on was using the Microsoft-Extensions software, plus the usual .SYS files for CDs. Does anyone have any ideas what happened here? /PJ ------------------------------- Notices you don't want to find printed on the back of your computer: "NO USER SERVICEABLE PARTS INSIDE", "SOME ASSEMBLY MAY BE REQUIRED", and everyone's favorite "BATTERIES NOT INCLUDED". ------------------------------ Date: Fri, 03 Nov 89 14:52:43 -0600 From: HISLE@VAX1.UMKC.EDU Subject: The Brain Virus (PC) Can anyone refresh me on the damage that the "Brain" virus can do to a diskette. I have infected diskettes as identified by IBM's VIRSCAN. Any information is appreciated. HISLE@VAX1.UMKC.EDU ------------------------------ Date: Fri, 03 Nov 89 16:16:33 -0500 From: Joe McMahon Subject: Virus List - Notes (Mac) I believe that the Peace virus appeared first - at least it was the first discussed, with nVIR and Scores following, in that order. I keep repeating this, but no one ever seems to see it: ---- There is no such thing as a SNEAK virus !!! ---- This was simply a convenient name for a particular virus-like code pattern that Bob Woodhead's "Interferon" program looked for - for those who are interested, an immediate branch out of CODE 0 to some other CODE segment. There is no specific virus called SNEAK, and there never has been. Bob has mentioned before that he's sorry he used this unfortunate appelation. Me, too. Please, tell your friends, there's no such thing. If you read the Interferon documentation, this is all explained in it. As to the San Jose Flu, I've never heard of it, and I don't believe that it's ever been discussed here. If you have more details, I'd like to see them. Everything else looks OK. Thanks for taking the time, Greg. --- Joe M. ------------------------------ Date: Fri, 03 Nov 89 16:58:48 -0800 From: well!rsa@apple.com (RSA Data Security) Subject: Digital signatures for virus protection The most effective method available to detect *any* change to a program is through the use of digital signatures. A "message digest" (much more mathematically secure than a checksum) is encrypted with the private key of a public key cryptosystem (the private key may be yours or someone you trust). The verification process is then as follows: - - recompute the message digest - - decrypt the encrypted message digest with the public key of the "signer" - the public key need not be secret - - compare the two If they match, the file is unaltered. No one can recompute and attach a mailicious signature since only the signer holds the private key. One paper by Maria Pozzo & Terry Gray of UCLA in January 1987 describes in detail how an operating system can use digital signatures based on public key cryptosystems to execute only "trusted" programs. Since no one can "forge" a signature, it is possible that software developers can "sign" their programs, essentially taking responsibility for their contents. This would provide a strong incentive for the publisher to ensure a program was clean before signing it. Note: there are simple, effective ways to validate public keys before using them to verify signatures. There are inexpensive commercial products available now for DOS, Mac OS, UNIX and VMS that do exactly this. They use a *secure* message digest algorithm which is 60 times faster than DES on 32 bit machines. The digest size is 128 bits (anything less is *not* cryptographically secure - there are a number of papers on the subject). Simple uses of DES has even been shown to be unsafe for checksums; it is vulnerable to attacks based on the birthday paradox which says that as the number of *useful* message variants approaches the square root of the total number of possible checksums (2^64 with DES), the probability that an attacker can match a checksum with a useful modified message exceeds 50%. Since (at least in DOS) you can add any number of bits to the end of a program without affecting its execution, programs are particularly vulnerable. Disclaimer: RSA Data Security designs, develops and markets the above mentioned software. Jim Bidzos ------------------------------ Date: Sat, 04 Nov 89 09:17:38 -0500 From: dmg@lid.mitre.org (David Gursky) Subject: Re: Greg Gilbert's virus list (Mac) In Virus-L V2 #231, "Gregory E. Gilbert" writes about a list of Mac Viruses. Greg's list contains several noteworthy errors. 1 -- SNEAK is not a virus. SNEAK is a term Robert Woodhead uses to denote code that is suspicious, but is not part of any known virus. For example, if you run Interferon 3.1 on Tops 2.1, you will get a SNEAK warning because of the way Tops is written. 2 -- The "San Jose Flu" was an early name given to Scores. Scores was first detected by Dave Lavery over at NASA Headquarters here in Washington DC. Two weeks after being found at NASA (thus the name "NASA Virus"), it was found in the San Jose area (hence the name "San Jose Flu"). Both were found to be the same virus. Scores gets its name from a file it creates in the System Folder entitled "Scores" 3 -- While not a mistake per se, Greg should point out that the Dukakis Virus is a virus directed at applications built with Hypercard (in Apple paradigm: Hypercard Stacks). Dukakis presents no threat (in a strict interpretation of the term) to other applications. [In other words, Dukakis can only infect Hypercard Stacks, but not applications such as Excel, Versaterm, Canvas, and so on.] David Gursky Member of the Technical Staff Special Projects Department, W-143 The MITRE Corporation ------------------------------ Date: 06 Nov 89 03:38:42 +0000 From: munnari!stcns3.stc.oz.AU!dave@uunet.UU.NET (Dave Horsfall) Subject: Re: Identify Ashar Virus In article <0007.8911032030.AA16863@ge.sei.cmu.edu>, SHERIFF@steffi.acc.uncg.edu writes: | When we run Viruscan 0.7V42 on an infected disk, here is what we see: | | Disk B: contains 1 directories and 5 files. | ld viruses found. " | | Please also observe that the number of viruses found is oddly noted. Obviously the result of a `printf("... %ld viruses found.", ...)' without the `%'. Doesn't do much to inspire confidence in the program's author, does it? On another note, I'm curious to learn just how generic the virus problem is. We've seen the Internet worm, the DECNET worm, the Christmas Tree virus, many PC/Macintosh/Amiga viruses etc etc. Anyone seen a CP/M virus yet? My home system is a CP/M-80 box, and I need to know whether to worry or not :-) - -- Dave Horsfall (VK2KFU), Alcatel STC Australia, dave@stcns3.stc.oz.AU dave%stcns3.stc.oz.AU@uunet.UU.NET, ...munnari!stcns3.stc.oz.AU!dave ------------------------------ Date: 06 Nov 89 11:06:05 +0000 From: wsinrn@urc.tue.nl (Rob J. Nauta) Subject: Re: Identify Ashar Virus In article <0007.8911032030.AA16863@ge.sei.cmu.edu> SHERIFF@steffi.acc.uncg.edu writes: >When we run Viruscan 0.7V42 on an infected disk, here is what we see: > >" Found Pakistani Brain Virus in boot sector. > Found Ashar Virus in boot sector. > >Disk B: contains 1 directories and 5 files. > ld viruses found. " > >Please also observe that the number of viruses found is oddly noted. That's something I noticed too. On a disk with the pingpong virus, viruscan 0.7V42 says (and some earlier versions did too) Found pingpong virus in bootsector Found pingpong virus-Version B in bootsector Disk A: contains 1 directories and xx files. ld viruses found. The ld viruses found is an interesting bug... Also bootsector viruses seem ti be reported twice. Greetings Rob ------------------------------ Date: Mon, 06 Nov 89 07:03:15 -0500 From: Kenneth R. van Wyk Subject: Morris to be tried >From the Washington Post -- 5 November 1989: U.S. Judge Rules Computer `Worm' Case to Be Tried (Associated Press) SYRACUSE, N.Y. -- A federal judge ruled Friday that the case of a former graduate student accused of unleasing a "worm" program into thousands of computers nationwide can go to trial. U.S. District Judge Howard Munson rejected pleas from the lawyer for Robert T. Morris Jr. to dismiss a felony computer-fraud charge on the grounds that information leaked by the Justice Department would prevent him from receiving a fair trial. Munson set the trial to begin Nov. 29. Morris's lawyer, Thomas Guidoboni, contended the Justice Department improperly revealed to a reporter before Morris was indicted in July that Morris had given a statement to prosecutors and that the department was considering whether he should be allowed to plead guilty to a misdemeanor. In November 1988, a "worm" program that prosecutors said Morris created clogged a network of about 6,000 computer shared by colleges, research centers and the military. It took several days to cleanse the network of the program, which multiplies out of control. Morris, 24, of Arnold, Md., became the first person in the country to be charged criminally under the 1986 Computer Fraud and Abuse Act when he was indicted on a charge of gaining unauthorized access to computers and causing losses in excess of $1,000. He faces up to five years in prison and a $250,000 fine if convicted. ------------------------------ End of VIRUS-L Digest ********************* 10-Nov-89 13:12:34-GMT,15613;000000000001 Received: from RUTVM1.RUTGERS.EDU by topaz.rutgers.edu (5.59/SMI4.0/RU1.1/3.04) id AA23877; Fri, 10 Nov 89 08:12:24 EST Message-Id: <8911101312.AA23877@topaz.rutgers.edu> Received: from RUTVM1.RUTGERS.EDU by RutVM1.Rutgers.Edu (IBM VM SMTP R1.2.1MX) with BSMTP id 5011; Fri, 10 Nov 89 09:11:41 EDT Received: from RUTVM1 by RUTVM1.RUTGERS.EDU (Mailer R2.04RU) with BSMTP id 5008; Mon, 06 Nov 89 20:33:16 EDT Date: Mon, 6 Nov 89 15:45:44 EST Reply-To: VIRUS-L@ibm1.cc.lehigh.edu Sender: Virus Discussion List From: "The Moderator Kenneth R. van Wyk" Subject: VIRUS-L Digest V2 #233 Comments: To: VIRUS-L@ibm1.cc.lehigh.edu To: Multiple recipients of list VIRUS-L VIRUS-L Digest Monday, 6 Nov 1989 Volume 2 : Issue 233 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: Virus source available in Toronto Re: Where are the Sophisticated Viruses? virus protection strategy questions New anti-virus programs uploaded to SIMTEL20 (PC) More CRC suggestions Re: Brain and Ashar virus (PC) Re: Brain Virus Query (PC) KillVirus (Mac) CRC Checking. Typo vs. Typo (PC) NP completeness --------------------------------------------------------------------------- Date: 06 Nov 89 11:48:16 +0000 From: frisk@rhi.hi.is (Fridrik Skulason) Subject: Re: Virus source available in Toronto kelly@uts.amdahl.com (Kelly Goen) writes: >the published sources working or non working are really not >that much of a threat... Wrong ! One concrete example why: The "Ghost" virus recently found here in Iceland seems to have been based on the listing of the Vienna virus from the book "Computer Viruses: A High Tech Disease" This is clear becuse the virus contains the two patches added there to make the virus a little less harmful than the original Vienna virus. Since any assembly language programmer should be able to create a new working virus in a day given a listing or a good (commented) disassembly, this gives us a good reason to limit the availability of virus listings as much as possible. - -frisk Fridrik Skulason University of Iceland frisk@rhi.hi.is Computing Sevices Guvf yvar vagragvbanyyl yrsg oynax ................. ------------------------------ Date: Sun, 05 Nov 89 23:04:41 -0700 From: ctycal!ingoldsb@cpsc.ucalgary.ca Subject: Re: Where are the Sophisticated Viruses? There are probably two reasons why the viruses you suggest do not exist: 1) If the system code is bypassed, then it must be rewritten. Most hackers are not at that level. Those that are that proficient are busy making money. 2) Code to do all the stuff needed would be quite large, and therefore noticeable. If you add 20 K to somebody's programs they will likely notice. Anyway, viruses experience exponential growth. At the beginning the spread is very slow and only becomes rapid after a fair while (say 6 months). This allows the wary to catch most viruses. Terry Ingoldsby ctycal!ingoldsb@calgary.UUCP Land Information Systems or The City of Calgary ...{alberta,ubc-cs,utai}!calgary!ctycal!ingoldsb ------------------------------ Date: 06 Nov 89 16:14:57 +0000 From: n8243274@unicorn.wwu.edu (steven l. odegard) Subject: virus protection strategy questions For personal computers, I can imagine Mom giving me advice to keep me from catching cold, [a biological virus]: 1. Wear your coat. Keep yourself warm. Don't expose yourself. The 3 1/2 inch disks have a little write-protect tab. If the disk is set to safe (where you may see through the hole), no data may be written to it, including virus's data. 5 1/4 or 8 inchers have a side slot which must be covered with black vinal tape to write-protected them. Is it reasonable to install write-protect toggle switches for hard disks on a personal computers? I use the write-protect all the time on larger computers -- once a machine (software) crashed and destroyied the work of one-hundred people the previous week! 2. Stay out of garbage. Use only reliable 'clean' software purchased from reputible software dealers. How often is food-poisioning contracted from eating food from clean restaurants? There are a few cases software published with unknown viruses lurking in them, but such are usually detected quite rapidly. 3. Quarantine: I have no experience here, is it practical to switch infected systems off of local-area networks? (unplug them)? What other common-sense strategies (as opposed to unreasonable panic strategies) are there to prevent these infections? Should terminate and stay resident programs be purged and reloaded from time to time, for example? I am reminded of a similar phenomena occurring on larger computer systems, where the terminals they employ have a code for "transmit 25th line". Then simply typing some file can cause you to lose all your files: the file contains the code to put "ERASE *.*" on the 25 line, and transmit. The computer sees the data stream "ERASE *.*" and proceeds to erase all files on the account. The cycle can be broken by disallowing the 25line code from appearing in the output -- use special 'display' program, or disabling the transmit 25th line command - -- install a toggle switch on the terminal, or by being careful what you look at -- be aware of the problem. - --SLO 8243274@wwu.edu uw-beaver!wwu.edu!8243274 n8243274@unicorn.wwu.edu ------------------------------ Date: Sun, 05 Nov 89 19:37:00 -0700 From: Keith Petersen Subject: New anti-virus programs uploaded to SIMTEL20 (PC) I have uploaded the following files to SIMTEL20: pd: SHEZ49.ARC Shell for archive manipulation, w/virus check pd: CKOT094.ARC Checks archived files for viruses (req. SCANV) NETSCAN.ARC Network compatible - scan for 46 viruses, v46 SCANRS47.ARC Resident program to scan for many viruses SCANV47.ARC VirusScan, scans disk files for 47 viruses VALIDAT3.ARC Validate shareware programs for authenticity CKOT094, NETSCAN, SCANRS47 and SCANV47 were obtained directly from the Homebase BBS. - --Keith Petersen Maintainer of SIMTEL20's CP/M, MSDOS, & MISC archives [IP address 26.2.0.74] Internet: w8sdz@WSMR-SIMTEL20.Army.Mil, w8sdz@brl.arpa BITNET: w8sdz@NDSUVM1 Uucp: {ames,decwrl,harvard,rutgers,ucbvax,uunet}!wsmr-simtel20.army.mil!w8sdz ------------------------------ Date: Sat, 04 Nov 00 19:89:58 +0000 From: agora.hf.intel.com!greg%medusa.intel.com@RELAY.CS.NET Subject: More CRC suggestions len@csd4.csd.uwm.edu (Leonard P Levine) writes: > A satisfactory system is one in which each user can use a polynomial > of his/her choice and where the list of files and their crc's > (for example) is stored in some arbitrary location. No virus writer > will be looking for YOU, rather just a collection of systems that > are alike enough to infect. The CRC program should encrypt and authenticate its stored data file(s); otherwise, it'd be easy for a savvy virus to essentially 'grep' for strings matching the format of those used by common CRC programs, and then modify that file. Even niftier would be 'roll-your-own' CRC programs, that encourage the user to modify and recompile them from available source; that way, virus authors couldn't compensate for just a few very popular CRC checkers, and would have to contend with thousands (probably millions) of different versions with different filenames and methods of storing the CRCs. [However, the above immediately brings to mind hacked versions of the source, intended to trick nontechnical users into compiling and running evil programs. I suppose we could get the source code from a few (authentic) sources, along with CRCs for that source code... :) Sigh.] Another thought: for people with access to EPROM burners, howzabout burning the (encrypted) CRCs into EPROMs? (I'm thinking primarily of PC clones, with their relatively easily accessible ROM sockets) Whenever new software is installed, the old EPROM could be wiped and reprogrammed. - -- ".. organized crime is the price we pay for organization." - Raymond Chandler Greg Broiles | CI$: 74017,3623 | greg@agora.hf.intel.com 3105 Pine St. | WWIVnet: 1@5312 | Riverside, CA 92501 | Peacenet: gbroiles | tektronix!tessi!agora!greg ------------------------------ Date: Sun, 05 Nov 89 15:34:17 -0500 From: KHV%NIHCU.BITNET@VMA.CC.CMU.EDU Subject: Re: Brain and Ashar virus (PC) I had the same experience as you did Tom, when using SCANV42 to scan a diskette I knew was infected by the Brain virus. I contacted John McAfee, the author of the program, and was told that that was a bug in that particular version of the program. Evidently, he choose overlapping hex strings as his virus signatures, so even though only the Brain virus was actually present, a false positive reading was obtained for the Ashar virus. I haven't tested it yet, but I'm sure that this bug has been corrected in the latest versions of the program (what are we up to now, version 48 or so?). Hope this clears things up. ------------------------------ Date: Mon, 06 Nov 89 09:31:23 -0500 From: Kevin_Haney%NIHDCRT.BITNET@VMA.CC.CMU.EDU Subject: Re: Brain Virus Query (PC) In response to your query about the Brain virus, I have included some information below that was put out by the Computer Virus Industry Assoc. The only things I would add to that description are that the virus does not infect hard disks, only floppies. The virus is non-destructive in that it is not specifically designed to damage any files (except the boot sector)--the damage comes in when it writes over the seven sectors, in a random location in the data area of the diskette, which may be part of a program or data file. The program may then not run or the data may be corrupted, but this is just a side-effect, so to speak. The virus is prevalent at locations which have public-access floppy-based systems such as universities. An infected disk (but not the files) can be recovered by formatting. The sectors flagged as bad can even be recovered if you have a utility such as Norton's that can directly modify the File Allocation Table, and you use it before you reformat the disk. If you perform the DOS SYS command, it will render the virus inactive by rewriting the boot sector and your files will still be there, although the bad sectors will also still be present and whatever damage was done will not be repaired. Hope this information helps! - ----------------------------------------------------------------- Name: Pakistani Brain Origin: Lahore, Pakistan, January 1986; developed by two brothers as an experiment Host: IBM PCs and compatibles Class: Boot sector infector Description: - - Replaces original boot sector with itself - - Moves original boot sector to another location - - Adds seven sectors that contain remainder of virus - - Flags all modified sectors as unusable to protect itself - - Replicates onto all inserted bootable floppies How spread: - - Booting from unknown or shared disks - - Infects through any access to an inserted disk Listing directories, executing programs and so on Through software reboot sequence Symptoms: - - Copyright @BRAIN label displayed in directory of infected disk - - Reboot sequence slowed down - - Excessive floppy activity for simple tasks - - Program crashes for some versions of DOS - - Interrupt vectors modified Potential damage: - - System crash can cause loss of data - - Spreads quickly to all bootable disks Precautions: - - Do not boot from unknown floppies - - Boot only from the hard disk if one exists - - Write-protect all boot disks Recovery: - - Shut down infected systems - - Reboot from a clean, write-protected original boot disk - - List directory of all disks - look for @BRAIN label - - When found, destroy the disk, or: Perform DOS SYS command to rewrite boot sector Recreate volume serial label using any available utility (This procedure will still leave 7 bad sectors with dead virus) Notes: Will live through software reboot. ------------------------------ Date: Mon, 06 Nov 89 12:27:20 -0500 From: "Gregory E. Gilbert" Subject: KillVirus (Mac) Does KillVirus have an nVir "resource". ("nVir" visible when examined with ResEdit.) Or do I have problems with my copy of KillVirus. Thanks much. Gregory E. Gilbert Computer Services Division University of South Carolina Columbia, South Carolina USA 29208 (803) 777-6015 Acknowledge-To: ------------------------------ Date: Mon, 06 Nov 89 10:34:26 +0000 From: Martin Ward Subject: CRC Checking. How about this for a system: Keep the CRC checker program and file of checksums on a separate bootable floppy, which has a suitable AUTOEXEC.BAT file. At the end of the day, power down, insert this floppy and power up. The machine boots off this floppy and is therefore guaranteed free from active viruses, it then automatically checks all executables on the hard disk for any changes. The same disk could go on to do a backup automatically once the machine has been declared free of infections. Martin. My ARPANET address is: martin%EASBY.DUR.AC.UK@CUNYVM.CUNY.EDU OR: martin%uk.ac.dur.easby@nfsnet-relay.ac.uk UUCP:...!mcvax!ukc!easby!martin JANET: martin@uk.ac.dur.easby BITNET: martin%dur.easby@ac.uk ------------------------------ Date: Mon, 06 Nov 89 19:12:45 +0000 From: frisk@rhi.hi.is (Fridrik Skulason) Subject: Typo vs. Typo (PC) There have been two viruses reported in the PC world, with the name "Typo". One is a boot sector virus - a modification of the Ping-Pong virus. This virus was written in Israel. The other virus is a resident .COM infector, 867 bytes long. This one is of U.S. origin. Since having two viruses with the same name will only lead to confusion, something needs to be done. Any suggestions ? - -frisk ------------------------------ Date: 06 Nov 89 20:27:02 +0000 From: kerchen@iris.ucdavis.edu (Paul Kerchen) Subject: NP completeness Recently, I posted an article in which I stated that the virus problem was NP complete. Well, a number of people pointed out my error and so I'd like to apologize. What I meant to say was that the virus problem (at least detection, anyway) is undecideable. However, despite this problem, I still contend that no virus solution will be a 100% solution. I'd like to thank the people who politely pointed out my mistake and the folks who were less than gracious can...well, you know what you can do. I'll have to watch my NP's and Q's more closely (sorry, I couldn't resist). Paul Kerchen | kerchen@iris.ucdavis.edu ------------------------------ End of VIRUS-L Digest ********************* 10-Nov-89 15:45:06-GMT,32903;000000000001 Received: from RUTVM1.RUTGERS.EDU by topaz.rutgers.edu (5.59/SMI4.0/RU1.1/3.04) id AA27893; Fri, 10 Nov 89 10:44:42 EST Message-Id: <8911101544.AA27893@topaz.rutgers.edu> Received: from RUTVM1.RUTGERS.EDU by RutVM1.Rutgers.Edu (IBM VM SMTP R1.2.1MX) with BSMTP id 2577; Fri, 10 Nov 89 11:44:24 EDT Received: from RUTVM1 by RUTVM1.RUTGERS.EDU (Mailer R2.04RU) with BSMTP id 2575; Fri, 10 Nov 89 11:16:24 EDT Date: Fri, 10 Nov 89 07:33:23 EST Reply-To: VIRUS-L@ibm1.cc.lehigh.edu Sender: Virus Discussion List From: "The Moderator Kenneth R. van Wyk" Subject: VIRUS-L Digest V2 #238 Comments: To: VIRUS-L@ibm1.cc.lehigh.edu To: Multiple recipients of list VIRUS-L VIRUS-L Digest Friday, 10 Nov 1989 Volume 2 : Issue 238 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: Sophisticated Viruses Re: Sophisticated Viruses 386 Isolation Pam Kanes book and the CVIA Undecidability RE: MacWight dilemma (Mac) Details of Ogre, Dark Avenger, etc. (PC) Another attack?!? (PC) Re: Sophisticated Viruses? Re: Checksum programs; Hardware protection Ping Pong virus (PC) at UIUC Re: virus problem undecidability New IBMPC anti-virals Re: future viruses on a PC Pull plug before cleaning In Search Of Virus Info [Ed. In an effort to send out one digest per day, this digest is longer than usual. If anyone has truncation problems due to its length (~32k), please let me know.] --------------------------------------------------------------------------- Date: Thu, 09 Nov 89 09:59:00 -0500 From: WHMurray@DOCKMASTER.ARPA Subject: Sophisticated Viruses Thanks to Jim Frost for a very thought provoking posting. Here are some that I had while reading it. >Limiting Propagation Rates. Simple viruses, and often not-so-simple >ones, will proliferate without bounds. Rampant proliferation will >cause the virus to be noticed early in its lifetime and will probably >lead to its early demise. The internet worm did not do this. Most PC viruses do not do it either. When the vector is a diskette, it need not. Most of the network worms have not done it; they wanted to be noticed. Therefore, the requirement is a function of both the chosen vector and the motive. >Detecting and Avoiding "Virus-Protected" Hosts. I have yet to see a >virus which looked at the state of a system to detect virus detection >mechanisms to nullify them and/or avoid infecting them. Biological viruses simply ignore potential but immune hosts. If the potential population is sufficiently large, the presence of immune subjects is not important. However, again motive is important. We have not seen any viruses that were determined to conceal their existence, in part because writing a virus that no one notices is not any fun. If no one notices, then it is not possible to know about propagation or survival. What fun is that? >Count our blessings now because you >won't believe how bad tomorrow's nightmares will be unless we start >teaching ethics to tomorrow's programmers! I will settle for simple self interest. ALL computer users have a vested interest in an orderly environment in which programs can be relied upon to do only what they advertise. Virus writers are soiling their own nests. William Hugh Murray, Fellow, Information System Security, Ernst & Young 2000 National City Center Cleveland, Ohio 44114 21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840 ------------------------------ Date: Thu, 09 Nov 89 10:37:36 -0500 From: Kenneth R. van Wyk Subject: Re: Sophisticated Viruses WHMurray@DOCKMASTER.ARPA writes: >> We have not seen any viruses that were determined to conceal their >> existence... In theory anyway, what proof to we have of their non-existence? If they're determined to conceal themselves, then why would we expect to notice them in the first place? In Cliff Stoll's book, "The Cuckoo's Egg", Dr. Stoll points out that for every forty (approximately) computers that the hacker invaded, only one or two system administrators ever noticed. The connections were relatively overt in that they left behind audit trails ('lastlog' entries), yet very few people noticed. (In my personal opinion, by the way, "The Cuckoo's Egg" should be considered required reading by anyone who runs, or is interested in, computers - *highly* recommended.) >> ...in part because writing a virus that no one notices is not any >> fun. If no one notices, then it is not possible to know about >> propagation or survival. What fun is that? There's an important distinction to be made here - detection during propagation vs. detection after (presumably) successful propagation. A virus could well attempt to conceal its existence while propagating, and then do quite the opposite (!) during a destructive phase. No one would notice until it would be too late. I'm not trying to sound like the voice of gloom and doom, really. I don't believe that the sky is falling. The purpose of this posting isn't to sound sensationalistic - merely to raise some questions. Ken van Wyk ------------------------------ Date: Thu, 09 Nov 89 10:50:00 -0500 From: WHMurray@DOCKMASTER.ARPA Subject: 386 Isolation The isolation hardware in the I386 makes it possible to construct a contained execution environment in which all the effects of execution are contained within the envrionment. Such an environment would be a useful place to test untrusted programs. Has anyone constructed such an environment? William Hugh Murray, Fellow, Information System Security, Ernst & Young 2000 National City Center Cleveland, Ohio 44114 21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840 ------------------------------ Date: 08 Nov 89 02:38:45 +0000 From: kelly@uts.amdahl.com (Kelly Goen) Subject: Pam Kanes book and the CVIA Hi I am passing this note on for the CVIA... no endorsement is made nor representation implied by Amdahl Corp or Onsite consulting as to the information that follows: I am the Acting Technical Director of the National BBS Society and, though I spend a great deal of time on computer virus related activities, I am not an active participant in any of the virus discussion forums, such as Virus-L. I do keep current with important virus issues and virus-related publications and occasionally come across something that requires comment. Pam Kane's book "V.I.R.U.S. - Vital Information Resources Under Siege" from Bantam Books is one such thing. Aside from the many technical inaccuracies and misleading product information contained in the book, Pam Kane's portrayal of the National BBS Society, the Computer Virus Industry Association and John McAfee's involvement in each is highly charged and grossly fallacious. Her assertion, for example, that Mr. McAfee 'owns' the National Bulletin Board Society and controls its virus-related activities is absurd to the point of comedy. The claim that the donation of a five-line bulletin board, months of unpaid time, and the responsibilities of coordination for a loose-knit and highly independent group of 2,000 SysOps is "ownership" cannot be taken seriously. Her entire discussion of the National Bulletin Board Society shows a blatant disregard for the facts and an alarming lack of understanding of the dynamics of virus research. More amazing, though, is her recollection of the events surrounding the formation of the Computer Virus Industry Association, an event that I witnessed first hand. Ms. Kane would have us believe that Mr. McAfee was strongly interested in having herself and other small antiviral product vendors as members and went out of his way to try and force membership on these companies. My own recollection was that Mr. McAfee extended these invitations out of politeness. It is hard to imagine why an organization that includes Microsoft, Lotus, Novell, Boeing Computer Services, Amdahl, Locus, Fujitsu, Ford Aerospace, Martin Marietta and 35 other such companies would be so interested in having Panda Systems as a member. I asked for and received permission from Mr. McAfee to include part of a May 2, 1988 letter from Mr. McAfee to Kate Drew-Wilkerson describing his intent to form the CVIA. I hope this puts his intent in proper perspective: "May 2, 1988 "Kate, " It is clear, at least to me, that computer viruses will not go away of their own accord. On the contrary, they must, based on all known laws of statistics, increase in prevalence. What we see today is merely a shadow of the problems we will face in the future. The number of individual strains will increase at some linear rate, and the incidences of infection will increase geometrically. This much is clear. The time frame is the only unknown. " Accordingly, I feel that the most urgent need is to organize. A consortium of hardware and software developers focused on the unique problems posed by an impending rash of infections is Priority One. For this to work, we mustobviously have the corporate computer industry leaders involved. How to do so at this juncture is the problem. The companies that shape the computer markets and policies have not yet been directly impacted, and by and large they dismiss the issue. In time this will change. For now, however, I will content myself with the three or four security firms who have branched out into the computer virus marketplace and with whom I have established a rapport. We can jointly form the foundations for the later entry of the industry giants. " From a sense of responsibility, and to embark with the necessary open forum required for success, I will extend an invitation to all parties that are known to me to be active in the virus field. It is doubtful, however, given the existing antagonism between the various vendors, that I shall have much success at achieving a quorum. In truth, I am counting on the probability that those vendors who would prove embarrassing as members will, for obvious reasons, decline participation. ... " /s/John McAfee" I would like to thank the moderator of this virus forum for providing a means of voicing my viewpoints in what I feel is an important computer virus area. Aryeh Goretsky, Acting Technical Director National BBS Society 1429 Dry Creek Road San Jose, CA 95125-4617 408 265 8499 Kelly Goen/ Cybernetic Systems Specialists Inc. Disclaimer: neither Amdahl Corp nor Onsite consulting offer any representation warranty or guarentees as to the accuracy of the information in this e-mail. ------------------------------ Date: Thu, 09 Nov 89 12:52:00 -0500 From: "Joseph M. Beckman" Subject: Undecidability The hypothesis of viral detection is that it is an undecidable task to determine whether an arbitrary program on an arbitrary "machine" contains a virus or not. This does not mean the viral detection question is undecidable. First, one is primarily interested in a subclass of the question. This subclass is a Type II error, or false acceptance (saying a program is virus free when it is not). Crocker & Pozzo have argued that it is feasible to create a filter which has a Type II error rate of 0. Naturally, some programs without viruses are rejected by a filter of this type. See their paper in the 1989 IEEE Security & Privacy Conference Proceedings. Second, neither programs nor machines are arbitrary in the real world. One can certainly think of machines (and then of programs running on those machines) where it can be trivially and without error shown whether a particular program is infected with a virus or not. All of this assumes that one has a definition of "virus." Joseph ------------------------------ Date: Thu, 09 Nov 89 12:49:00 -0500 From: Subject: RE: MacWight dilemma (Mac) Possible (though unlikely) solution to the MacWight (MacWrit, or whatever) Virus: Anyone out ther familiar with Timbukto? That nice little DA that allows one user on a net to actually attach his mac to another running on the same net. Even take over the other mac if the other person does not know what is happening. That way it is possible to have something change right before your eyes if you are on a net, running Timbukto and have someone else (who is probably in hysterics) running Tim on another mac on the net. Try capturing someone's mac when he's netTrek and just have fun with the poor boy. it's possible... Alex Z... . . . ------------------------------ Date: Sun, 05 Nov 89 15:01:02 +0000 From: Alan Solomon Subject: Details of Ogre, Dark Avenger, etc. (PC) There has been a number of people recently calling for information about some of the newer viruses, like Ogre, and Dark Avenger. What follows are excerpts from the manual of a commercial product; it's OK for me to post this, as I wrote it and have the copyright! I shan't mention the name of the product, but I must apologise that the pages of the manual do refer to various components of the product. Where it refers to Findvirus, please take this as meaning any virus scanning program that knows about the virus in question; when it refers to Peeka, please take this as meaning any disk sector editor. The paragraph numbers are the chapter numbers in the manual. I've taken the liberty of calling Ross Greenberg's discovery Fumble instead of Typo, as there is already a Typo in the literature, and we don't want two viruses with the same name. Sorry, Ross. If anyone finds any errors or significant omissions in these descriptions, please respond via email or fax to me directly. Finally, could I please lay one myth to rest. Datacrime (called Columbus day in the US) does the low level format on October 13th and every day thereafter until December 31st. It does this in versions 1168, 1280 (infective lengths) and Datacrime II. It does NOT do anything on October 12th, and Datacrime II does NOT go off on Jan 1 to Oct 12th. Datacrime II refrains from the format on Mondays. The whole October 12th thing was caused by a misunderstanding about dates, picked up by the media and turned into a factoid. The other important thing about Datacrime, is that it is extremely uncommon indeed. We have had no (zero, nil) cases in the UK, and I know of only two cases in Holland. Does anyone know of any *confirmed*, definite, sightings? Apart from Fridrik's self inflicted accident, of course :-) Dr Alan Solomon Day voice: +44 494 791900 S&S Anti Virus Group Eve voice: +44 494 724201 Water Meadow Fax: +44 494 791602 Germain Street, BBS: +44 494 724946 Chesham, Fido node: 254/29 Bucks, HP5 1LP Usenet: drsolly@ibmpcug.co.uk England Gold: 83:JNL246 CIX, CONNECT drsolly [Ed. Because of the length of the excerpts, I've sent them to the comp.virus documentation archive sites. Access information will be posted shortly.] ------------------------------ Date: Thu, 09 Nov 89 13:51:40 -0600 From: CA6692@SIUCVMB.BITNET (Vince Laurent - work id) Subject: Another attack?!? (PC) We have encountered something that appears to be a virus of some sort. The symptoms are : 1. When an EXE file is run that is 'infected' the screen gets lines and garbage that looks like 'snow' (TV term there...) 2. After a few runs it changes the file length to 0. 3. When the disk is checked using some utilites there are numerous 'bad sectors' scattered on the disk. Side Note: The color of the 'snow' is the same as the last application that ran (ie when Norton Editor is run with a green screen - there is green snow, white screen editing makes white snow, etc...) I have not been able to 'capture' this virus to get a look at the code. I know of 3 cases so far, some of my coworkers have run across it too. Any ideas on what it might be? --------------------------------------------- | Vincent J. Laurent | | Help Desk | | Computing Affairs | | Southern Illinois University - Carbondale | | CA6692@SIUCVMB | --------------------------------------------- p.s. please! no comments about yellow snow... ------------------------------ Date: Thu, 09 Nov 89 15:17:25 -0400 From: "Joel B. Levin" Subject: Re: Sophisticated Viruses? >I don't agree with you on any of these points, Terry. Say, on the >Macintosh all calls to ROM are done through trap vectors in RAM. These >trap vectors are patched by the system file (to fix bugs), by some >programs and by all anti-virus tools. However, it doesn't take a >genius to figure out that one could restore the trap vector to it's >original value and thereby bypassing the "safe" system. . . . > . . . A patch like this wouldn't occupy much space and is quite >simple to write. Except that when system patches or INIT patches or program patches to the traps were removed by the virus (and how would the virus decide what value to restore them to?--this is different for each ROM and system release version) the user would certainly be likely to notice the resultant changed program behavior -- or system crashes. /JBL ------------------------------ Date: Thu, 09 Nov 89 14:51:40 +0200 From: Y. Radai Subject: Re: Checksum programs; Hardware protection Concerning checksum programs, Paul Kerchen writes: > where does one store these checksums and their keys? If >they are stored on disk, they are vulnerable to attack just like >programs. That is, a virus could infect the program and then update >its checksum, since the key must be somewhere on disk as well (unless >the user enters it every time they compute a checksum--yecch!) and one >must assume that the checksum algorithm is known. Or, >more simply, a virus could simply wipe out all the checksums, >leaving the user to decide which files were infected. Storing the >'sums off line would insure security, but at what cost? Checking >and updating the 'sums with any frequency would become tedious at best. First, let's rule out the possibility of wiping out the checksums. To be successful, a viral attack (as opposed to a Trojan Horse attack) must not be obvious. Such an action would immediately be noticed. That leaves us with the more subtle action of altering checksums. Now there are two types of CSPs (checksum programs), sometimes called "dynamic" and "static", and most of Paul's remarks seem to be based on the assumption that we are using the dynamic type. Dynamic CSPs are resident programs which checksum each program which is execu- ted just before its execution. A well-known example is the checksum feature of FluShot+. Static CSPs are non-resident programs which checksum a list of many files on demand, usually at boot time by vir- tue of being placed in the AUTOEXEC.BAT file. An example is Sentry. Now the dangers described above by Paul are no problem for static- type CSPs. In this case one can keep the CSP, along with the CSB (checksum base) and key (generating polynomial in the case of a CRC), on a write-protected, non-infected bootable diskette, and execute the CSP from that diskette after cold-booting from it. Since the CSP is static, this need be done only once per boot, and the additional in- convenience relative to doing this from the hard disk will be very slight. (In fact, there are even utilities which allow you to specify that the program is to be executed only once a day, once a week, etc. even though the command is in AUTOEXEC.BAT.) But suppose one wants to execute the program from the hard disk any- way. We can still foil the checksum forger by simply requiring the user to supply the key interactively. "Yecch!", says Paul, but he is probably thinking of dynamic checksumming. Again, if one uses static checksumming, the key need be supplied only once per boot at the most. Now let's suppose we're using a dynamic-type CSP and prefer the con- venience of doing everything from the hard disk. Would this really make the checksum and keys vulnerable, as Paul claims? Even if it's true that *theoretically* a virus could find the CSB and key and then alter the former, in practice that seems to me rather unlikely for a variety of reasons: First, if the CSB is stored under a name that is not fixed, how would the virus find it? If it does it by searching all files on the hard disk looking for a certain type of content, then infecting some file and computing its new checksum from the key which it has discovered and updating the CSB, that would take a lot of time. One must remember that any modification in a program which causes it to take much more time than usual is likely to be noticed by the user, causing him to suspect a virus. Secondly, forging checksums would make a lot more sense if there were a single CSP which was used by a majority of the users of a given type of computer. But what good does it do to write a program to forge checksums used by a particular type of CSP when it is use- less on the overwhelming majority of computers? Unless the virus creator is satisfied with attacking a very limited environment, such as a student lab, in which all computers use the same CSP, checksum forging hardly seems worthwhile. This is not to say that there are no dangers to CSPs. But checksum forging is not the main one. On most systems there are CSP-fooling techniques which are not only much faster and independent of the par- ticular CSP, but also easier to write. To give a PC example, suppose the hard disk and RAM are infected by a boot-sector virus which hooks Int 13h in such a way that any attempt to read the boot sector results in reading the sector in which the virus has stored the original boot sector (i.e. it works like the Brain virus except that it infects the hard disk also). If the com- puter is booted from the hard disk, the CSP will be activated only after the virus has installed itself in RAM, hence checksumming the boot sector will not reveal that the boot sector has been modified. This particular trick can be overcome by booting from a clean disk- ette before activating the CSP. But on the PC, at least, there are several other ways of fooling a naively designed CSP which cannot be overcome in this way. Chuck Kichler says things similar to what Paul says above, except that he suggests looking in the program (the CSP) instead of in the CSB. The answers are similar. However, he also suggests using a hardware device. This is not a new idea, and there is at least one commercial implementation of this for PCs, called Disk Defender, con- sisting of a card placed between the disk drive and the controller. It comes with software for dividing the hard disk into two logical drives, one of which is left unprotected for necessary writing, while the other is completely write protected, except when it is necessary to transfer files to it. I agree that this is one of the best types of anti-viral protection. But even if we ignore the tedious installa- tion required (if the disk is not initially empty) and the relatively high price ($240, last I heard), one should not assume that it neces- sarily provides absolute protection; it may still be possible for a virus to infect the normally protected drive during those periods when the protection is removed in order to transfer new files to it. Y. Radai Hebrew Univ. of Jerusalem, Israel RADAI1@HBUNOS.BITNET ------------------------------ Date: Thu, 09 Nov 89 14:56:05 -0500 From: "Mark S. Zinzow" Subject: Ping Pong virus (PC) at UIUC This is a slightly edited copy of our local warning. Today (Thursday, November 9, 1989) the Ping Pong B virus was found on an XT in Newmark hall here at the University of Illinois at Urbana-Champaign. This is the third virus to infect IBM PC's here. The previous PC viruses were Brain and Jerusalem. This virus is a boot sector infector and also goes by the names Bouncing Ball, Italian, VERA CRUZ, and VERA CRUZ B. Please use scanv48.arc (anonymous ftp'able from uxe.cso.uiuc.edu in the directory pc/virus) to search systems for infection, and unvir6.arc (from the same place) to remove the virus from infected systems. VIRUSCAN, the name for the package of programs in scanv48.arc, is a shareware product. Just this week CSO has purchased a site license for the U. of I. so you may ignore the request for a $25 registration if you are using this software here. SCAN.EXE (in scanv48.arc) will report two versions of Ping Pong when it is found. This is a bug, the B version also triggers the message for the non-B version. So far, we think we only have one version of this virus floating around. The program IMMUNE by Yuval Ratavy in unvir6.arc will make your system immune to the Ping Pong, Jerusalem, and several other viruses. Please call me (244-1289 or email markz@vmd.cso.uiuc.edu) if you find a copy of PING PONG as I'm trying to figure out the extent and locations where this virus has spread. In the local versions of this announcement, excerpts from the following VIRUS-L Digests were included: VIRUS-L Digest Wednesday, 18 Jan 1989 Volume 2 : Issue 18 Subject: Re: The Ping-Pong virus (PC) VIRUS-L Digest Thursday, 9 Mar 1989 Volume 2 : Issue 61 Subject: Re: Bouncing ball virus (PC) VIRUS-L Digest Friday, 10 Mar 1989 Volume 2 : Issue 62 Subject: bouncing ball virus (PC) VIRUS-L Digest Wednesday, 10 May 1989 Volume 2 : Issue 112 Subject: Yet more on SYS (PC) VIRUS-L Digest Friday, 12 May 1989 Volume 2 : Issue 114 Subject : 1 byte can save us from the Ping Pong virus (PC) - -------Electronic Mail---------------U.S. Mail--- ARPA: markz@vmd.cso.uiuc.edu Mark S. Zinzow, Research Programmer BITNET: MARKZ@UIUCVMD.BITNET University of Illinois at Urbana-Champaign CSNET: markz%uiucvmd@uiuc.csnet Computing Services Office "Oh drat these computers, they are 150 Digital Computer Laboratory so naughty and complex I could 1304 West Springfield Ave. just pinch them!" Marvin Martian Urbana, IL 61801-2987 USENET/uucp: {uunet,convex,att}!uiucuxc!uiucuxe!zinzow Phone: (217) 244-1289 Office: CSOB 110 \markz%uiucvmd ------------------------------ Date: 09 Nov 89 23:09:50 +0000 From: kerchen@iris.ucdavis.edu (Paul Kerchen) Subject: Re: virus problem undecidability OSPWD@EMUVM1.BITNET (Peter W. Day) writes: >A note to the virus-l digest of 6-Nov-89 said that "the virus problem (at >least detection anyway) is undecidable." Does anyone know if there are >any papers where this result is proved? Or where the problem is >shown to not be NP complete? Or even where the problem is stated >precisely? (Sorry about the mail loop, Peter) I base my arguments upon Fred Cohen's paper "Computer Viruses: Theory and Experiments," which can be found in _Computer Security: A Global Challenge_ ( a collection of security-related papers). In this paper, Cohen talks about the undecidability of detecting viruses in a program and proves why this is the case (although, purists wouldn't call it a proof). Paul Kerchen | kerchen@iris.ucdavis.edu [Ed. The cited Cohen paper was also published in the _Computers and Security_ journal (though I don't have an issue number), as well as directly from Dr. Cohen.] ------------------------------ Date: Thu, 09 Nov 89 20:46:04 -0600 From: jwright@atanasoff.cs.iastate.edu (Jim Wright) Subject: New IBMPC anti-virals More anti-virals. It's getting hard to keep up these days... :-) In brief: alert14g.zip Checks files for changes, use in AUTOEXEC ckot094.zip *** Serious bugs, do not use *** datacure.arc Removes DataCrime virus and prevents damage m-dav.zip Removes Dark Avenger virus netscan.zip Network compatible program to scan for viruses scanrs48.arc Resident program to scan for viruses scanv48.arc Scans files, directories, drives for viruses validat3.zip Use this to check downloads for integrity alert14g.zip Update to the alert13u program in the archives. Add to your AUTOEXEC and it will check the files you specify to make sure they have not changed. Free to government, shareware otherwise. ckot094.zip CHECKOUT, a shell program to simplify use of scanv when scanning multiple archives. Shareware. WARNING!!!! This program has a tendency to delete any file it can find. This is a rather nasty bug. I would recommend you not use any version of this program until an update is released and independently tested. It should already be removed from the anti-viral archives. datacure.arc A working version of the DataCure program to replace the apparently mangled version I got earlier. Includes a program to cure infected files and a program to prevent the DataCrime virus from zapping your disk. Shareware. m-dav.zip A program to remove the Dark Avenger virus. Shareware. netscan.zip Network compatible program to scan disks for viruses. An update to the previous archive of the same name. This program is not quite shareware, in that a site license is required for continued use rather than a simple registration. scanrs48.arc Resident program to scan programs for viruses before execution. Update replaces previous version. Shareware. Includes the VALIDATE program. scanv48.arc Program to scan files, directories and drives for viruses. Update replaces previous version. Shareware. Includes the VALIDATE program. validat3.zip Checksum program to use for validating downloads. Run this on a file, note the numbers it gives, and compare this with the numbers provided by a trusted source. What is a trusted source? That is being worked out. :-) Jim ------------------------------ Date: 10 Nov 89 07:38:05 +0000 From: kelly@uts.amdahl.com (Kelly Goen) Subject: Re: future viruses on a PC Pull plug before cleaning Sorry again turning off power will stop the current execution of the virus... but... unless you are perfect in your safe computing habits and your tools are up to snuff and you give your harddisk an engineering prep as you power up and ALL your software is clean.. you can still be hit upon power up... following post you invok int19 to read the boot tracks in loc 7c00 it is at this point you are first vunerable...and not under control of ANY antiviral tool I have heard about...(VIRUS_PROOF pc designs not withstanding... even cd-rom has been infected during the production of shareware libaraies...) but you wont incurr damage to your data while power is off but neither can you get to it either...I am not saying the problem is unsolvable nor hard to deal with just realize the power off switch is no REAL protection some time or another you will eventually power up... cheers kelly ------------------------------ Date: 10 Nov 89 07:53:56 +0000 From: wugate!smu.edu!mazanec@uunet.UU.NET (Bob Mazanec) Subject: In Search Of Virus Info I am trying to find any and all information available on computer (UNIX & others) viruses for a report in an ethics class (gee, i bet this stuff might even be useful to me in running my little VAX, huh?). Please E-MAIL me any information you might have (or even just references to magazines/books that might have same) on known viruses what/where/when/how/etc. psychology of virus writers immunology what can/has been done bug exploitation/fixing etc. MANY Thanks in advance!! Robert L. Mazanec @ Southern Methodist University {attctc, convex, texsun}!smu!mazanec == mazanec@smu.edu DISCLAIMER: You think they TAUGHT me this stuff?? ------------------------------ End of VIRUS-L Digest ********************* 13-Nov-89 10:51:53-GMT,12930;000000000001 Received: from RUTVM1.RUTGERS.EDU by topaz.rutgers.edu (5.59/SMI4.0/RU1.1/3.04) id AA23391; Mon, 13 Nov 89 05:51:43 EST Message-Id: <8911131051.AA23391@topaz.rutgers.edu> Received: from RUTVM1.RUTGERS.EDU by RutVM1.Rutgers.Edu (IBM VM SMTP R1.2.1MX) with BSMTP id 0258; Mon, 13 Nov 89 06:51:26 EDT Received: from RUTVM1 by RUTVM1.RUTGERS.EDU (Mailer R2.04RU) with BSMTP id 0254; Mon, 13 Nov 89 06:51:22 EDT Date: Mon, 13 Nov 89 05:38:54 EST Reply-To: VIRUS-L@ibm1.cc.lehigh.edu Sender: Virus Discussion List From: "The Moderator Kenneth R. van Wyk" Subject: VIRUS-L Digest V2 #239 Comments: To: VIRUS-L@ibm1.cc.lehigh.edu To: Multiple recipients of list VIRUS-L VIRUS-L Digest Monday, 13 Nov 1989 Volume 2 : Issue 239 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: New Virus (PC) Interferon & The Vision Fund (Mac) "The Cuckoo's Egg," Cliff Stoll, Doubleday, New York ($18.95), Virus trivia (PC) Re: MacWight? (Mac) Re: Where are the Sophisticated Viruses? (PC) Previous Incorrect Attribution New Virus (PC) Re: Identify Ashar Virus (PC) --------------------------------------------------------------------------- Date: Fri, 10 Nov 89 09:32:38 -0800 From: portal!cup.portal.com!Alan_J_Roberts@Sun.COM Subject: New Virus (PC) A new COM infector was submitted to the HomeBase board this evening by Jean Luz of Lisbon, Portugal. The virus is in many respects similar to the Vienna virus - the size increase is 648 bytes, and instead of overwriting every eigth file (on the average) with the re-boot sequence, it overwrites with the characters "AIDS", thus crippling those applications. This virus shoulkd not be confused with the original AIDS virus (very dissimilar). Asside from the mentioned similarities with Vienna, the virus appears to be written from scratch. The 648 length seems to be a chance result. No effects of the virus have been observed other than the above mentioned. The virus has been in Portugal at least two months according to the submitter. Alan P.S. The following presumably straight-faced request was posted on HomeBase by John McAfee. Thought it might be of interest to Virus-L readers: To: All Users From: John McAfee Subject: Reported Possible Virus I received an unusual call from a Mr. Fred Hankel of Fargo, North Dakota this morning. Mr. Hankel was highly agitated and after hearing his long and involved story, I was moved to pass on this condensed summary to all who might be interested: Mr. Hankel reports, and I have no grounds for doubting, that a computer virus invaded his system from a bingo game he purchased in mid-October. The virus activated at 11:00 A.M yesterday and promply melted his power supply and mother board. As he reached for the power switch to turn off the machine, the virus blasted a perfectly circular hole in the front panel of his AT clone and left a three foot oval scorch mark on the back wall of his den. I had not heard of this virus before and felt that an alert might be in order. Anyone experiencing similar symptoms should contact us immediately. Thank you. [Ed. Sounds (to me) like paranoia strikes deep. I trust that everyone will have the good sense to take this report with a large grain of salt...] ------------------------------ Date: Fri, 10 Nov 89 22:17:27 +0000 From: biar!trebor@uunet.uu.net (Robert J Woodhead) Subject: Interferon & The Vision Fund (Mac) On behalf of the Vision Fund, I would like to thank everyone who has sent in a Shareware donation for use of the Interferon program. We have collected a substantial amount of money that has gone to good use. Now I have a request: Please don't send in any more money! Interferon is now an obsolete program; Shareware programs like Disinfectant and commercial programs like (plug, I wrote it) Virex are faster and better. In addition, I've been told by my accountants that the informal structure of the Vision Fund can cause me some tax problems if too much more money comes in. Therefore, I declare both Interferon and MandelColor (another Vision Fund program) to be Freeware. After a certain date, any cheques received made out to the Vision Fund will be returned. Any cash sent in, or cheques made out to Yours Truly, will be spent on wooing women. - -- Robert J Woodhead, Biar Games, Inc. !uunet!biar!trebor | trebor@biar.UUCP Announcing TEMPORAL EXPRESS. For only $999,999.95 (per page), your message will be carefully stored, then sent back in time as soon as technologically possible. TEMEX - when it absolutely, postively has to be there yesterday! ------------------------------ Date: Sat, 11 Nov 89 07:41:00 -0500 From: WHMurray@DOCKMASTER.ARPA Subject: "The Cuckoo's Egg," Cliff Stoll, Doubleday, New York ($18.95), >(In my personal opinion, by >the way, "The Cuckoo's Egg" should be considered required reading by >anyone who runs, or is interested in, computers - *highly* >recommended.) -- Ken Van Wyk As much as I like Cliff Stoll, I still hate to be forced to sell his book. Nonetheless, I am force to agree with Ken on this: the book is required reading. It is so much so, that I do not even harbor any qualms about saying so on the network. William Hugh Murray, Fellow, Information System Security, Ernst & Young 2000 National City Center Cleveland, Ohio 44114 21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840 ------------------------------ Date: Sat, 11 Nov 89 12:34:24 +0000 From: frisk@rhi.hi.is (Fridrik Skulason) Subject: Virus trivia (PC) Just a few random bits of information.... * A diskette infected with the Ohio virus will be immune to infection by the Brain and Den Zuk viruses, since it contains the signature of those two viruses. * The Vacsina virus can only properly infect a .COM file, so when it infects a .EXE file it will do so in two steps, first change it into a .COM file by overwriting the 4D 5A signature with a JMP instruction and placing a 132 byte loader program at the end of the file. The next time this program gets infected it will be infected just like any other .COM file. * Almost all .EXE infecting viruses place the virus code at the end of the infected file. One virus, sURIV 2.0 does not. It will insert itself just after the header of the program it infects. And one question.. What language is "Den Zuk" ? I thought it was Dutch for "The search", but I have been told that it is not. - -frisk ------------------------------ Date: 10 Nov 89 16:46:36 +0000 From: ut-emx!chrisj@cs.utexas.edu (Chris Johnson) Subject: Re: MacWight? (Mac) XRJDM@SCFVM.BITNET (Joe McMahon) writes: >You may (or may not :-) remember the discussions we had here on the >list about this. As far as I remember, there was never a specific >demonstration that there was a virus involved. That doesn't mean that >there wasn't; it just means that there were never quite enough facts >presented to make a case either way. I'd leave it off for now, or >mention it as a "rumored sighting" or whetever. Safest not to mention >it, especially since it was never pinned down and analyzed. > > --- Joe M. I agree whole-heartedly! Please *do*not* mention this alleged virus - the paranoia the initial reports of this alleged virus have given way to is damage enough. There is still *no* evidence that this virus ever existed. Since my initial postings on this subject, I have received a couple of files that, it was thought, might have been infected by this alleged virus. I found no indication of any virus (or anything at all out of the ordinary) in those files. Once again, there is still *no* evidence that this virus ever existed. If new evidence surfaces, this disucssion can continue, but at the moment there's no evidence and, consequently, nothing to discuss. The end. "The onus of proof is on he who asserts the positive." Cheers, - ----Chris - ----chrisj@emx.utexas.edu ------------------------------ Date: Sat, 11 Nov 89 19:52:07 +0000 From: madd@world.std.com (jim frost) Subject: Re: Where are the Sophisticated Viruses? (PC) frisk@rhi.hi.is (Fridrik Skulason) writes: >jim frost writes: >>Given the limited resources of PC environments, it's >>unlikely that you'll get a very sophisticated virus. >I must disagree. In the PC environment it is not a question of limited >resources, but rather the fact that any user process has full access to >ALL resources and can even directly manipulate the hardware if required. >So, my opinion is that it is even easier to write a sophisticated virus on >the PC than in most other environments. No, it's harder. Most of the items which I consider sophisticated require fairly fancy programming which requires code space, data space, and CPU time, each of which is at a premium in most PCs. A really sophisticated virus, one targeted for UNIX, for instance, could easily approach or exceed a megabyte in size. You just can't do that on most PCs, and users would notice even if you could. On the other hand you don't need to. MS-DOS systems are so trivial that it's difficult to build a good virus detector and there are no inherent security systems. Viruses don't need to be sophisticated. >Finally, I want to add one "feature" to the description of a sophisticated >virus: >"Bypass protection programs and jump directly to the hardware, DOS or >BIOS routines." I didn't add that because that's not usually one of the "survival" traits, but rather is used in propagation and/or infection. I have a fairly lengthy document on the kinds of things a real sophisticated virus might do in each stage (what I showed before was a subset of this document). I consider the document sensitive so I am wary of posting it. jim frost madd@std.com ------------------------------ Date: 11 Nov 89 21:56:43 +0000 From: kelly@uts.amdahl.com (Kelly Goen) Subject: Previous Incorrect Attribution Hi all, Well it seems I have been guilty of incorrect attribution of an article I forwarded for Aryeh Goretsky... The forward was NOT officially from the CVIA nor does it represent an official opinion of th CVIA. The forward was from Aryeh Goretsky who was not acting in any official capacity for the CVIA. Here I am redfaced indeed!! my fault only in the incorrect attribution... cheers kelly ------------------------------ Date: Sat, 11 Nov 89 14:39:50 -0800 From: portal!cup.portal.com!Alan_J_Roberts@Sun.COM Subject: New Virus (PC) Yet another virus has been reported and sampled in the Seattle area. The virus is a COM, EXE and Overlay infector that increases the size of infected files by 1644 bytes. It activates on Sundays and displays the message: "Today is Sunday! Why do you work so hard? All work and no play make you a dull boy." File allocation table damage has been reported in two instances, although we could not dupliacte the FAT problem on our test systems. McAfee is planning to put SCAN49 out on Tuesday. 49 will detect this Sunday virus, the Lisbon Virus and Yuval Tal's Do Nothing virus (He sounds pretty haggard over the phone and begins to snarl if the words "new virus" are mentioned). Alan ------------------------------ Date: 13 Nov 89 03:40:48 +0000 From: munnari!stcns3.stc.oz.AU!dave@uunet.UU.NET (Dave Horsfall) Subject: Re: Identify Ashar Virus (PC) It has been pointed out to me (hello Kelly!) that I may have been less than gracious in my response to the report of "ld viruses found." Certainly no offence was meant to John McAfee, and I hope none was taken. However, actual bug details aside, the point I was making that the user of a virus-detector has to have absolute trust in it, and any errant behaviour by the program can only weaken that trust, no matter who the author is. Certainly, a failure to correctly report the number of viruses found would seem to imply a lack of testing. Virus detectors must not only be above reproach, they must be SEEN to be above reproach. Anyone here read comp.risks/RISKS-L ? - -- Dave Horsfall (VK2KFU), Alcatel STC Australia, dave@stcns3.stc.oz.AU dave%stcns3.stc.oz.AU@uunet.UU.NET, ...munnari!stcns3.stc.oz.AU!dave ------------------------------ End of VIRUS-L Digest ********************* 16-Nov-89 19:47:07-GMT,26632;000000000001 Received: from RUTVM1.RUTGERS.EDU by topaz.rutgers.edu (5.59/SMI4.0/RU1.1/3.04) id AA08440; Thu, 16 Nov 89 14:44:42 EST Message-Id: <8911161944.AA08440@topaz.rutgers.edu> Received: from RUTVM1.RUTGERS.EDU by RutVM1.Rutgers.Edu (IBM VM SMTP R1.2.1MX) with BSMTP id 4563; Thu, 16 Nov 89 15:21:12 EDT Received: from RUTVM1 by RUTVM1.RUTGERS.EDU (Mailer R2.04RU) with BSMTP id 4560; Thu, 16 Nov 89 14:39:27 EDT Date: Thu, 16 Nov 89 12:00:37 EST Reply-To: VIRUS-L@ibm1.cc.lehigh.edu Sender: Virus Discussion List From: "The Moderator Kenneth R. van Wyk" Subject: VIRUS-L Digest V2 #241 Comments: To: VIRUS-L@ibm1.cc.lehigh.edu To: Multiple recipients of list VIRUS-L VIRUS-L Digest Thursday, 16 Nov 1989 Volume 2 : Issue 241 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: Identify Ashar Virus (PC) VACSINA contains update facility (PC) New viruses - 867 and 648 (PC) Any quantitative studies of computer virus epidemiology 80386 and viruses (PC & UNIX) Known PC Virus List Signature Programs XTREE virus clarification... (PC) Re: Sophisticated Viruses --------------------------------------------------------------------------- Date: 15 Nov 89 15:59:59 +0000 From: kelly@uts.amdahl.com (Kelly Goen) Subject: Re: Identify Ashar Virus (PC) Now at least I hear the case being correctly stated... and I will say it myself...in the Antiviral industry(sic) there has been a distinct lack of quality control of most popular nostrums......while small bugs may not shake up the experienced bugs do INDEED cause the less computer literate to really wonder about running this or that vendors product on their system...(what with tales of FAT and primary format wiping running rampant over the net ....... VENDORS do you hear me??? dave is stating a very salient point... I do hope someone is indeed listening... cheers kelly p.s. Hi dave!! Kelly Goen CSS Inc. DISCLAIMER: I Dont represent Amdahl Corp or Onsite consulting. Any statements ,opinions or additional data are solely my opinion and mine alone... Seen in alt.sex recently "SEX is FUN, Thats why there are so many of us!!" My Opinion: Sex between Consenting Computers leads to Social Data Diseases! ------------------------------ Date: Tue, 14 Nov 89 21:57:05 -0500 From: Christoph Fischer Subject: VACSINA contains update facility (PC) Hi, we just completed our virus catalog entry for the VACSINA virus and checked with some friends. One of them: David M. Chess pointed out that we overlooked a fact. Well it is a very important fact: VACSINA contains an update facility. The last 4 bytes of an infected file contain F4 7A 05 00. The F4 7A is the VACSINA id and 05 00 is the version number ( lo byte first ) so we have version 0005 of VACSINA. If the virus finds anything less than 0005 it will reconstruct the original file and then it will infect with the new version of VACSINA. Now we understand why the author left so much space in the head of the virus. Also the 3 byte used for the 'VACSINA-TSR is in memory' flag contain a 05 so future versions of VACSINA will know if an older version of VACSINA installed its TSR. If anybody has virus infected files that show F4 7A 06 00 or higher please post a note. Thanks to David again! Chris ***************************************************************** * Torsten Boerstler and Christoph Fischer and Rainer Stober * * Micro-BIT Virus Team / University of Karlsruhe / West-Germany * * D-7500 Karlsruhe 1, Zirkel 2, Tel.: (0)721-608-4041 or 2067 * * E-Mail: RY15 at DKAUNI11.BITNET or RY12 at DKAUNI11.BITNET * ***************************************************************** ------------------------------ Date: 15 Nov 89 00:00:00 +0000 From: David.M..Chess.CHESS@YKTVMV Subject: New viruses - 867 and 648 (PC) I've been looking through a couple of new PC viruses (thanks to John M. and Fridrik S. for the samples), and thought I'd write down a couple of things: - The 867-long COM-infector that only infects on even-numbered days and sometimes messes up one's typing has been called "Typo" and "Fumble" here. To either add to or subtract from the confusion, I'd suggest calling it the "867" until a good reason not to comes along... - The 648-long COM-infector that Alan Roberts reported above is in fact Vienna-derived. It's functionally identical to the Vienna, except that it overwrites the occasional victim with "@AIDS" instead of the Vienna's 5-byte reboot program. The code has been messed with considerably; the author seems to have taken a sample of the Vienna, and asked, for every instruction, "how can I change this to do exactly the same thing using a different set of bytes?". In many places the code is identical; in others, it has been tightened up, or expanded with NOOPS, or tiny and non-functional changes in register usage have been made. The perpetrator was clearly interested in fooling any virus scanner looking for Vienna identification strings (to use Joe Hirst's phrase). DC ------------------------------ Date: 16 Nov 89 00:20:32 +0000 From: pz@apple.com (Peter Zukoski) Subject: Any quantitative studies of computer virus epidemiology out there? Hi - I recently received a request from Richard Dawkins (A zoology professor at Cambridge, author of the "Blind Watchmaker" which is a summary of Darwinian evolution, and the software which helps one understand the power of slight mutations coupled with huge numbers of generations.) for information about computer viruses. Following is his request. He doesn't have access to the interNet, so please send any responses to me, even if this prompts a discussion in this group, as I don't normally read it and wouldn't want to miss anything pertinent. Please mention/send any past discussion of these issues which you might have lying about as well. Thanks "Do what you want -- you will anyway." peterz pz@apple.com Bell: 408-974-2920 Snail: Apple Computer 20525 Mariani MS/76-3C Cupertino, CA 95014 - ---------- My interest is as follows: I want to develop a 3-way analogy between 'real' viruses, computer viruses, andviruses of the mind. To give the idea, I'm pasting in the following draftproposal for a BBC television program that nearly appeared with me as Presenter(in the end the project was shelved, but I now want to pursue the idea further anyway). "PROPOSAL FOR TV PROGRAM: VIRUSES OF THE MIND Three kinds of virus. In all three cases there is information-handling machinery as a sitting target for parasitic self-replicating information or 'viruses'. 1. 'Real' viruses, made of DNA or RNA. They are almost pure information, digital information just like in computers. They use the reading and translating machinery provided by hosts. Build up a picture of host cellular machinery as a sitting target for viruses, rather like a room full of information-handling equipment - xeroxes, teleprinters, computers and so on. The machinery is all there, vulnerable to being exploited. It is good at handling DNA, almost eager to handle DNA, copy it, splice it in, decode it, build the proteins specified by the DNA code. Viral information is like a computer program whose only real purpose is to make copies of itself. The protein jacket etc is just the apparatus needed to propagate copies of the information specifying it. Actually, that is true of all living bodies too (the central message of The Selfish Gene and The Extended Phenotype), but it is particularly stark for viruses. And the special point about viruses is that they use other organi sms' handling machinery. Viruses are propagated through the air (common cold), through saliva (rabies) or other bodily fluids (AIDS). 2. Computer viruses. These are computer programs, written by malicious individuals, whose essential purpose is simply to make copies of themselves. They may also, like 'real' viruses, have deleterious effects upon the host. For instance some viruses delete files at random from the hard disc. Once again we have the same picture of information-handling machinery as a sitting target for parasitic information. Computers are so good at handling information, so powerful at doing what programs tell them to do, that they are, in a sense, asking for trouble, asking to be the victim of malicious, self-replicating information. Computer viruses are propagated by borrowed or pirated floppy discs, over e-mail networks and so on. Unknown before 1980s, they are now alarmingly common. My own hard disc picked up an infection last year and it was a sinister and eerie sensation. 3. Mind viruses. Human minds, too, consist of sophisticated information-processing machinery, like computers and like the DNA-processing machinery of cells. Once again, because of its normal information-processing functions, it is a sitting target for 'viruses'; it is vulnerable to being invaded and taken over by malicious self-copying programs. In this case they propagate themselves via word of mouth, print, television etc. I think the best examples (in the sense of most strongly resembling the other kinds of virus) are to be found in religion, especially the kinds of fundamentalist religion that have become so prominent in the 80s. People actually use the word 'possessed' for the state of being taken over by one of these influences. I suspect that we could actually find film of people in religious trances whose behaviour would strongly resemble the behaviour of people mentally ill with a brain virus. Even if not literally the same, I think that the analogy between the three kinds of virus could be put across convincingly, emphasizing especially fundamentalist faith as an infectious disease of the mind. My own experience of getting letters from religious people (especially in Northern Ireland) after my article in Daily Telegraph forcibly made me think of the behaviour of computers infected by a virus. In particular, there is the weird phenomenon of quoting scriptural verses. These people had read my article, so ought to realise that I'd be unmoved by biblical quotations. Yet their own mind is so taken over by the 'operating system' that is programmed to accept every word of the bible that they cannot conceive of another mind not instantly succumbing to the same thing." So, I'm really after any studies of the details of how computer viruses spread that lend support to the thesis described in the above proposal. Best wishes Richard - ----------------------- Thanks ------------------------------ Date: Tue, 14 Nov 89 17:05:05 -0600 From: Peter da Silva Subject: 80386 and viruses (PC & UNIX) > The isolation hardware in the I386 makes it possible to construct a > contained execution environment... Such an environment would be a > useful place to test untrusted programs. > Has anyone constructed such an environment? Yes. It's called "Merge 386" or "Vp/IX". `-_-' Peter da Silva, Xenix Support. R2419 X5180 'U` "Have you hugged your wolf today?" [Ed. These products, by the way, are DOS emulation boxes for i386 based UNIX and XENIX products.] ------------------------------ Date: Wed, 15 Nov 89 12:53:57 -0800 From: portal!cup.portal.com!Alan_J_Roberts@Sun.COM Subject: Known PC Virus List The following list was put together by John McAfee. The naming conventions follow the ViruScan conventions. Many thanks to David Chess for the concept for the list's format. VIRUS CHARACTERISTICS LIST Copyright 1989, McAfee Associates 408 988 3832 The following list outlines the critical characteristics of the known IBM PC and compatible viruses. Comments and suggestions welcomed. ==========================================================================] Infects Fixed Disk Partition Table-------------+ Infects Fixed Disk Boot Sector---------------+ | Infects Floppy Diskette Boot --------------+ | | Infects Overlay Files--------------------+ | | | Infects EXE Files----------------------+ | | | | Infects COM files--------------------+ | | | | | Infects COMMAND.COM----------------+ | | | | | | Virus Remains Resident-----------+ | | | | | | | Virus Uses Self-Encryption-----+ | | | | | | | | | | | | | | | | | | | | | | | | | | Increase in | | | | | | | | | Infected | | | | | | | | | Program's | | | | | | | | | Size | | | | | | | | | | | | | | | | | | | | Virus V V V V V V V V V V Damage - -------------------------------------------------------------------------- Do-Nothing . . . x . . . . . 608 p Sunday . x . x x x . . . 1636 O,P Lisbon . . . x . . . . . 648 P Typo/Fumble . x . x . . . . . 867 O,P Dbase . x . x . . . . . 1864 D,O,P Ghost Boot Version . x . . . . x x . N/A B,O Ghost COM Version . . . x . . . . . 2351 B,P New Jerusalem . x . x x x . . . 1808 O,P Alabama . x . . x . . . . 1560 O,P,L Yankee Doodle . x . x x . . . . 2885 O,P 2930 . x . x x . . . . 2930 P Ashar . x . . . . x . . N/A B AIDS . . . x . . . . . Overwrites Program Disk Killer . x . . . . x x . N/A B,O,P,D,F 1536/Zero Bug . x . x . . . . . 1536 O,P MIX1 . x . . x . . . . 1618 O,P Dark Avenger . x x x x x . . . 1800 O,P,L 3551/Syslock x . . x x . . . . 3551 P,D VACSINA . x . x x x . . . 1206 O,P Ohio . x . . . . x . . N/A B Typo (Boot Virus) . x . . . . x x . N/A O,B Swap/Israeli Boot . x . . . . x . . N/A B 1514/Datacrime II x . . x x . . . . 1514 P,F Icelandic II . x . . x . . . . 661 O,P Pentagon . . . . . . x . . N/A B 3066/Traceback . x . x x . . . . 3066 P 1168/Datacrime-B x . . x . . . . . 1168 P,F Icelandic . x . . x . . . . 642 O,P Saratoga . x . . x . . . . 632 O,P 405 . . . x . . . . . Overwrites Program 1704 Format x x . x . . . . . 1704 O,P,F Fu Manchu . x . x x x . . . 2086 O,P 1280/Datacrime x . . x . . . . . 1280 P,F 1701/Cascade x x . x . . . . . 1701 O,P 1704/CASCADE-B x x . x . . . . . 1704 O,P Stoned/Marijuana . x . . . . x . x N/A O,B,L 1704/CASCADE x x . x . . . . . 1704 O,P Ping Pong-B . x . . . . x x . N/A O,B Den Zuk . x . . . . x . . N/A O,B Ping Pong . x . . . . x . . N/A O,B Vienna-B . . . x . . . . . 648 P Lehigh . x x . . . . . . Overwrites P,F Vienna/648 . . . x . . . . . 648 P Jerusalem-B . x . x x x . . . 1808 O,P Yale/Alameda . x . . . . x . . N/A B Friday 13th COM Virus . . . x . . . . . 512 P Jerusalem . x . x x x . . . 1808 O,P SURIV03 . x . x x x . . . O,P SURIV02 . x . . x . . . . 1488 O,P SURIV01 . x . x . . . . . 897 O,P Pakistani Brain . x . . . . x . . N/A B Legend: Damage Fields - B - Corrupts or overwrites Boot Sector O - Affects system run-time operation P - Corrupts program or overlay files D - Corrupts data files F - Formats or erases all/part of disk L - Directly or indirectly corrupts file linkage Size Increase - The length, in bytes, by which an infected program or overlay file will increase Characteristics - x - Yes . - No ------------------------------ Date: 16 Nov 89 01:02:36 -0500 From: Bob Bosen <71435.1777@CompuServe.COM> Subject: Signature Programs As a member of the American National Standards Institute's (ANSI) X9E9 working group and an active participant in standards activities regarding computer security and authentication, I have been reading the various comments on "Checksum" programs with a lot of interest ever since this forum became accessible to me about 2 weeks ago. If the comments which follow are way off-base, please forgive my newness to the forum; perhaps these things have been discussed in the less recent past.... I've been surprised at the lack of content regarding sophisticated authentication algorithms. In this forum of late,I've been reading about checksums and CRCs but I haven't heard any mention of ANSI X9.9 or ISO 8731-2, which are both extremely relevant standards. Both of these authentication algorithms have served the international banking community well, having been used for years to secure billions of dollars worth of daily wire-funds transfers without a single verified case of compromise. Checksum programs work by attempting to "authenticate" a program or file by calculating a number, based upon the content of the file. That number serves as a digital "signature" reflecting the exact status of the file at the moment when the calculation was made. Unfortunately, authentication in hostile environments is not a trivial subject, and has been shown to be susceptible to forgery and compromise. Furthermore, as Paul Kerchen and Y. Radai have recently commented, very serious attention must be paid to exactly where the signatures (and any component parts critical to their calculation) are stored. In my opinion, if properly implemented, signature programs have the potential for being much more useful than "scanners" (or any other known anti-viral technique) in most instances, since they don't require any foreknowledge about the viruses which may attack in the future. Relying on simplistic algorithms to calculate these signatures suffers from an obvious disadvantage: Future viruses can compensate for the way the signature is calculated, or forge signatures that appear to be valid. Relying on supposedly "secret, proprietary" algorithms is very risky: the annals of cryptography are littered with the bones of algorithms that couldn't withstand the scrutiny of dedicated adversaries. If the history of algorithmic research can teach us anything, it is that we shouldn't trust any cryptographic algorithms unless they've been examined by a very large population of experts. There is a developing science of "authentication technology" that is revealing important facts about the kinds of algorithms that can be relied upon to resist the scrutiny of adversaries. It's amazing how many people are unaware of these things, and it's D