========================================================================= Date: Wed, 15 Jun 88 03:33:59 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Amanda B Rosen Subject: Another way to delay propagation (ATs and PS/2s) In a previous message I pointed out that Macintosh PRAMs could be used to hold a counter to implement a delay mechanism for a virus. This technique could also be used on ATs and PS/2's (and clones therof) since they also have configuration RAM, or whatever IBM calls it this week. This method would not rely on the ability to write to disks. (One more nasty thought from the source of the great Mac battery wars... :-) /a ========================================================================= Date: Wed, 15 Jun 88 15:02:03 BST Reply-To: Virus Discussion List Sender: Virus Discussion List From: O'Brien Subject: virii on large(r) machines So far this distribution list seems to have concentrated on micros - are there any instances of virus attacks on mainframes/minis/supermicros (ie multi-user machines bigger than PC-AT's) It strikes me that since so many of these machines (especially in the academic community) are networked there is definitely a distribution medium for virii. The only incidents I've heard of have all required huming beans to help "propogate" (?) the virus from one machine to another (XMAS EXEC?) Ian --- JANET: cs_iob@uk.ac.bath.ux63 Ian O'Brien, Systems Programmer, OTHER: cs_iob@ux63.bath.ac.uk Bath University Computing Services USENET: ..!mcvax!ukc!bath63!cs_iob ========================================================================= Date: Wed, 15 Jun 88 10:05:24 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: NYPC meeting summary Last night (June 14, 1988...), I attended an invitation-only meeting of the New York PC users' group. Among the attendees were several representatives from some of the major corporations in the NYC area as well as a few anti-virus program vendors, and myself. The people from the corporations wanted to get some facts about viruses without any media hype. The meeting was set up as a forum discussion, and touched on most of the major points in current virus technology and jargon. Basically, the vendors (and myself) described what known viruses do (by citing several examples) and answered several questions presented by the corporations. Among the questions were "What is the difference between a virus and a trojan horse?", "Can a virus do hardware damage to my PCs?", etc. Hopefully, some common misconceptions were cleared up. Each of the vendors then got a chance to discuss and demonstrate their wares. That brings me to my next topic (finally :-). I'd like to hear from people who've used commercial (and non-commercial) anti-virus packages. Hopefully, we can generate some objective discussions on the various packages here on VIRUS-L. Any takers? Some of the currently available packages are, in no particular order: (a thousand pardons to any which I neglect!) Data Physician Flu Shot Disk Watcher Vaccine (there are a number of products under this name!) Vaccinate Checkup Disk Defender Panda ...the list goes on So, let's hear from people who've used these (or others). Ken Kenneth R. van Wyk User Services Senior Consultant Steve Dallas: Who's driving?! Lehigh University Computing Center Opus: Oh keep your pants on, Internet: I pressed cruise control. BITNET: ========================================================================= Date: Wed, 15 Jun 88 10:30:33 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: Re: virii on large(r) machines In-Reply-To: Message of Wed, 15 Jun 88 15:02:03 BST from > are there any instances >of virus attacks on mainframes/minis/supermicros Much (if not all?) of Fred Cohen's Phd work was done on minis and mainframes. Indeed, the possibilities here seem to be even more limitless than those on micros. Particularly with things like international networks to aid in the distribution of a virus. Ken Kenneth R. van Wyk User Services Senior Consultant Steve Dallas: Who's driving?! Lehigh University Computing Center Opus: Oh keep your pants on, Internet: I pressed cruise control. BITNET: ========================================================================= Date: Wed, 15 Jun 88 16:47:00 LCL Reply-To: Virus Discussion List Sender: Virus Discussion List From: Michael Wagner +49 228 8199645 Subject: Re: virii on large(r) machines > The only incidents I've heard of have all required huming beans to > help "propogate" (?) the virus from one machine to another (XMAS > EXEC?) This isn't only true of larger machines. The micros also needed a 'huming bean' to search out and obtain the infected boot disk. XMAS EXEC was different only because it is unusual in the mainframe world to just run a strange program you picked up on the network (unlike the PC world, where such things are not only run, they are booted from). XMAS EXEC required not just a 'huming bean' but a gullible one, and not just one but many. What was truly amazing was how many it found. Perhaps if they'd been thinking instead of huming the damage would have been smaller. :-) Michael ========================================================================= Date: Wed, 15 Jun 88 11:27:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Jim Shaffer, Jr." Subject: mainframe virii Here at Bucknell University, rumors abound about a virus called TAPEWORM that was allegedly run on one of our mainframes some years ago. Unforunately, all the rumors are so vague that I can't even determine what OS it was running on. As for a time frame, I would have to say probably within the past 5 years. The virus supposedly singled out individual users accounts at random when they logged in (how it was supposed to do this I have no idea) and copied itself to them. The users couldn't erase it, and each time they logged in after the initial infection all of the copies of TAPEWORM in their account generated one new copy, so the population grew exponentially until soon the user's disk quota was exceeded. Has anyone heard of this, or is it just a wild story that got started somehow? (Of course, even if it did happen here it doesn't mean that it happened elsewhere. We've never been a part of any DECnet, UUCP, or any TCP network, so spreading it would have been difficult.) --Jim Shaffer, Jr. (shafferj@bknlvms) P.S. According to the stories, the last person to ever see our virus graduated in 1987, so nobody knows if it's still around or who started it. The computing center staff refuses to give out any information that's even remotely security-related, so I've never asked them. They get suspicious if people start inquiring into possible system bugs. I know this from experience. ========================================================================= Date: Wed, 15 Jun 88 11:57:09 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: me! Jefferson Ogata Subject: a few points Tell me about XMAS EXEC; I've never heard of it. One possible infection mode I've seen for VM/370 mainframes is an EXEC I've seen that spools two punch files together to some user. Only the first file appears in the header information, and there is only one spool file. The result is that a user can transmit an innocuous file to another person with some other file tacked on the end. When the innocuous file is received, the other file is received also. Don't ask me how it works; I just know it works -- I've seen it in action. In every way I was able to determine, there appeared to be only one file, yet when I received that file, it wrote two files to my disk. It only notified me of the first file. This EXEC could easily be used to infect other mainframes with viruses -- send something like XEDIT EXEC on the back of some other file; the next time the victim XEDITs something, the virus is acti- vated. Unless the victim examines his disk everytime he receives a file, he probably won't notice. There is a curious virus said to exist in the C compiler AT&T uses at their research locations. This virus was added by a compiler hacker some time ago, and performs the simple function of printing a happy birthday message for that hacker every time the compiler is run on his birthday. This virus is particularly curious because it is virtually impossible to find where in the C compiler it is located. This was done by taking advantage of the fact that the C compiler is used to compile itself every time it is updated. For example, suppose you write a piece of code that can reproduce itself (typical self-printing program). This code performs the following function: if you see some piece of code in the C compiler, print yourself along with a replacement for that code, and code to print out a happy birth- day message on my birthday. This code is triggered at one particular place in the C compiler code. Whenever that code is scanned, it is replaced by all the virus code. The trigger code can be completely innocuous; it need only be in a place where code can filter the scanner output. Now as soon as the C compiler has compiled the new version of itself, the virus code can be removed from the source code. Each time the compiler is run on itself it will insert the virus code at some point. But the virus code is only alive in the executable version, not in the source code. According to legend, to this day no one has discovered where the trigger code is, nor has anyone been able to disable the virus. This is the way I've heard it. - Jeff Ogata ========================================================================= Date: Wed, 15 Jun 88 14:15:35 EDT Reply-To: Malcolm Ray Sender: Virus Discussion List Comments: Warning -- original Sender: tag was malcolm@JVAX.CLP.AC.UK From: MALCOLM@JVAX.CLP.AC.UK Subject: The Intruder Versus the Hacker Apropos the discussion about teaching virus-writing, I thought I'd toss in the following quote, which I think has some relevance. It's from 'Stalking the Wily Hacker', a very interesting article in the May 1988 issue of the Communications of the ACM, describing how staff at LBL traced a hacker. Copied with the implicit permission of the ACM: > The Intruder versus the Tracker > > Skills and techniques to break into systems are quite different > from those to detect and trace an intruder. The intruder may not > even realize the route chosen; the tracker, however, must understand > this route thoroughly. Although both must be aware of weaknesses in > systems and networks, the former may work alone, whereas the latter > must forge links with technical and law-enforcement people. The intruder > is likely to ignore concepts of privacy and trust during a criminal trespass; > in contrast, the tracker must know and respect delicate legal and ethical > restrictions. > > Despite occasional reports to the contrary, rumors of intruders building > careers in computer security are exaggerated. Apart from the different > skills required, it is a rare company that trusts someone with such ethics > and personal conduct. Banks, for example, do not hire embezzlers as > consultants. Donn Parker, of SRI International, reports (personal > communication, September 1987) that job applications of several intruders > have been rejected due to suspicions of their character and trustworthiness. > On March 16th, the Washington Post reported the arrest of a member of the > German Chaos computer club, prior to his giving a talk on computer security > in Paris. Others who have broken into computers have met with physical > violence and have been ostracized from network activities. A discipline > that relies on trust and responsibility has no place for someone technically > competent yet devoid of ethics. [Stalking the Wily Hacker; Clifford Stoll, Communications of the ACM May 1988 Copyright 1988 ACM 0001-0782/88/0500-0484 $1.50 Permission to copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct commercial advantage, the ACM copyright notice and the title of the publication and its date appear, and notice is given that copying is by permission of the Association for Computing Machinery. To copy otherwise, or to republish, requires a fee and/or specific permission.] Well, he's got a point. Once someone's got a taste of the havoc they can cause with their very own virus, would *you* trust them to look after your systems? ------------------------------------------------------------------------ Malcolm Ray JANET: malcolm@uk.ac.clp.jvax Senior Systems Officer BitNet: malcolm@jvax.clp.ac.uk City of London Polytechnic No other routes please! Quis custodiat ipsos custodes, or something like that ========================================================================= Date: Wed, 15 Jun 88 14:17:57 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Kenneth Ng Subject: hidden files on VM/CMS >From: me! Jefferson Ogata >One possible infection mode I've seen for VM/370 mainframes is an >EXEC I've seen that spools two punch files together to some user. >Only the first file appears in the header information, and there >is only one spool file. The result is that a user can transmit an >innocuous file to another person with some other file tacked on the >end. When the innocuous file is received, the other file is >received also. Don't ask me how it works; I just know it works -- >I've seen it in action. In every way I was able to determine, there >appeared to be only one file, yet when I received that file, it >wrote two files to my disk. It only notified me of the first file. >This EXEC could easily be used to infect other mainframes with >viruses -- send something like XEDIT EXEC on the back of some other >file; the next time the victim XEDITs something, the virus is acti- >vated. Unless the victim examines his disk everytime he receives a >file, he probably won't notice. I'm not sure how this works, but look at sendfile with the acknowledge option. When a receive is performed, a file 'Acknowl dgement' is sent back to the host. Therefore my bet is that it has something to do with the 'netdata' format. ========================================================================= Date: Tue, 14 Jun 88 23:24:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List Comments: Resent-From: WHMurray@DOCKMASTER.ARPA Comments: Originally-From: WHMurray@DOCKMASTER.ARPA From: WHMurray@DOCKMASTER.ARPA Subject: Academic Assignment of Viruses A society that depends upon any mechanism for its own proper functioning, cannot tolerate, much less encourage, any tampering with the intended operation of that mechanism. Therefore, one is tempted to rise up in indignation at the idea of a qualified academic assigning a virus to his students. The next thing you know, they will be assigning plagiarism. How about the forgery of academic credentials? Perhaps we should offer a course in how to falsify research results. Or, perhaps, on how to trash another's experiments, notes or reports. Perhaps it is a sign of immaturity that we are unable to recognize the moral equivalency. I will leave open the question of whether the immaturity is in the technology, the society, or academia. I thought that we put this issue to bed several years ago when we stopped assigning the breaking of security. It seems that we did not. For an academic to be unable to recognize that assignments, and the recognition that goes with their successful completion, encourages the behavior assigned, demonstrates a lack of understanding of the activity in which he is engaged. If he understands it, and still makes such an assignment, he demonstrates a lack of understanding of where his real interest rests. Such irresponsible behavior may account, in part, for the anti-academic bias in our society and for the manifest distrust of the scientific establishment. It is of little wonder that the citizens of Cambridge, Massachusetts are reluctant to trust the likes of these with genetic engineering. If there is any lesson that we should have learned from the computer, it is that understanding the effects of what we intend for it to do is a daunting task. Even getting it to do what we intend is not trivial. It seems to me, that there is plenty of material here for assignments; we need not look to assignments which are at best trivial, and at worst, dangerous. William Hugh Murray, Fellow, Information System Security, Ernst & Whinney 2000 National City Center Cleveland, Ohio 44114 21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840 ========================================================================= Date: Wed, 15 Jun 88 16:26:52 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Kenneth Ng Subject: CMS netdata files >From: Kenneth Ng >>From: me! Jefferson Ogata :edited query on reader files with several files in it: >I'm not sure how this works, but look at sendfile with the acknowledge >option. When a receive is performed, a file 'Acknowl dgement' is >sent back to the host. Therefore my bet is that it has something >to do with the 'netdata' format. Naturally after I send the message out I remember how to look at a file to see if there are more than one file. Get the number of records off the 'q rdr all' command, then do a 'PEEK X (FOR Y' where 'X' is the spoolid, and 'Y' is the number of records minus 1. You'll see all kinds of funky stuff there, which is the NETDATA format. ========================================================================= Date: Wed, 15 Jun 88 16:29:21 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: forwarded report on VACCINE from J.D. Abolins Software Review by J.D. Abolins (first submittal: ASCIIRIBER) VACCINE, VERSION 2.0 (not to be confused with FoundationWare's VACCINE, VERSION 1.2 or several other programs by the same name.) WorldWide Data Corporation 17 Battery Place New York, NY 10004 1-800-643-3000 ext. 123 for all credit card and COD orders from individuals. 1-212-422-4100 for other calls and orders. 1-212-809-7206 for FAXed Corporate Purchase Orders. For IBM and IBM compatible computers (including PC, XT, AT (286 & 386), and PS/2 - 30,50,60, or 80) using DOS 2.0 or later. Sold on a 5.25" 360K floppy diskette only. Not copy-protected. 3.5" diskette version copies will be provided on exchange basis to REGISTERED USERS ONLY. Price: $79.95 (Discount prices available for large orders.) WorldWide Data's VACCINE is one of the many "anti-viral" software packages on the market now. These programs offer to guard computers from malicious computer programs, known as "Trojan Horses" and "viruses". Many of these programs emphasize the parallels between computer "viruses" and biological viruses. VACCINE is no exception; its very name has a medical connotation. Its packaging displays pictures of hypodermics, forceps, Kelly clamps, and other medical instruments. The medical analogy was so strong, I felt I had to sterilize my hands before loading the program into the XT. The VACCINE package includes one 5.25" diskette, a nine-page instruction book, registration card, and a couple of information sheets. The diskette itself included three main programs- VACCINE, ANTIDOTE, and CHECKUP. The are several utility and sample files files included, as well as a README file for additional documentation. The instructions were clear, concise, and simple. ANTIDOTE, which is the first program to be run when installing VACCINE, scans executable files on one's hard disk, looking for signs of program code to any of the various "viruses" known to WorldWide Data. ANTIDOTE can run periodically to check for suspicious code. CHECKUP examines the executable files on one's hard drive, derives checksums, checks the files' sizes, and compares the information against a file of values from an earlier CHECKUP run. If the file of previous values doesn't exist, CHECKUP will create a new one. It will give a status report telling one which files have been changed, deleted, or added. VACCINE is a memory-resident program which detects programs that change memory tables or they to become memory-resident. To prevent continual false alarms when running legitimate programs, one must prepare a configuration file which lists the names of legitimate program which may trigger off VACCINE's warnings. This is quite simple. The documentation suggests that VACCINE be invoked by the AUTOEXEC.BAT so that it is always in the background. When it detects a program attempting to change the memory tables or become memory- resident, VACCINE sounds off rapid pulsing tones and flashes a warning at the bottom of the screen. It gives one three options- "Y" to continue the program, "R" to reboot the system, or "A, Alt-A, or Control-A" to add the detected program's name to the configuration file. Simple enough. The option to update the configuration file is excellent; the update can be done with one keystroke. As mentioned several times above, VACCINE is simple to install and to use. But a major question remains- "how effective is it against destructive programs?". Since I don't have samples of "virus" program, I could not run a full "live ammo" test. Yet from examining and using the package, I have found several indicators of its capabilities and weaknesses. The package does a good overall checkup of the EXECUTABLE FILES. This will detect most of the "viruses" which infect executable files. VACCINE will not detect anything that infects other files, such as overlay files. For moment, most of the "viruses" that I have heard about would be detected by VACCINE since they, at some point, will affect executable files. There are no such assurances for the future. A major precaution that must be taken with this software was with any other "anti-virus" software- one's system must be "clean" before installing the software. Otherwise, the software may consider the destructive software as a part of the normal environment. This is why the VACCINE documention specifies that one uses ANTIDOTE first. But if ANTIDOTE misses bogus code, it may be a while before CHECKUP of VACCINE detect the code. While running CHECKUP several times, I have noticed a quirk that can cause problems for some users. I use a subdirectory with a high-order ASCII character in its name. The first time I ran CHECKUP, it worked well since it was creating a new checksum/size file. But when I ran CHECKUP again, it gave me an error message, saying that the program found an invalid character in the checksum/size file. After experimenting with renaming of the unusual subdirectory, my suspicions were confirmed. CHECKUP can be thrown off by high- order ASCII (ASCII 128-255) in filenames or directory names. This quirk makes it impossible to effectively use CHECKUP on the whole hard disk or on the root directory; CHECKUP can still used with subdirectories that don't have the high-order ASCII codes. This should be no problem for most users, but some users should be aware of this quirk. I know no solution to this quirk other than changing the filenames or directory names. VACCINE was simple to install and to use. It seems to offer a good amount of protection against the most of the common types of malicious programs. But will only scan executable files, so other files are still vulnerable. Then there is the matter of CHECKUP's quirk regarding non-standard filenames. Then considering the price of VACCINE ($79.00), I would recommend for the average home PC user to check out some of the other "anti-virus" software before deciding which one to buy. Some have options that VACCINE does not and many offer a bit more for less cost. VACCINE will definitely do the job of providing some protection for one's system. But there is no 100% effective "anti-virus" program. So whatever software, one uses, one must still compute wisely. [Thanks, J.D. Anyone else have any similar reports on other products? Ken] Kenneth R. van Wyk User Services Senior Consultant Steve Dallas: Who's driving?! Lehigh University Computing Center Opus: Oh keep your pants on, Internet: I pressed cruise control. BITNET: ========================================================================= Date: Wed, 15 Jun 88 17:42:45 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Joe McMahon Subject: Mac Vaccine Vaccine for the Macintosh Author: Don Brown, CE Software Price: Free Type of program: Virus blocker (INIT file) Installation: Copy file into System folder Action: Vaccine blocks attempts to write code resources of various types (including FKEYs, MDEFs, WDEFS, and INITs) and displays a modal dialog alerting the user as to the attempt. The user may choose to allow or disallow the access. Vaccine has an "expert mode" which places a tiny icon in the upper right-hand corner of the screen which can be clicked to allow or disallow the access. Some users have reported trouble with the Font/DA Mover and Vaccine, but I have not had any problems. Vaccine is quiet, unobtrusive, and should stop any virus which does not completely avoid using the Toolbox to modify the resource fork of files. ========================================================================= Date: Wed, 15 Jun 88 14:57:00 PDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: DBUERGER@SCU Subject: RE: NYPC meeting summary Re: Ken van Wyk's request for people who use anti-virus software: I use several programs as part of a general plan to protect myself. I recognize that this plan isn't perfect, but what else can one do? I run Data Physician's DATAMD program, which checks pre-tagged .exe and .com files upon each boot-up. I used to run a similar program they sell, which does the same thing at user-specified intervals automatically while my AT is on. So far the software has not detected viral attack against these file. It has detected changes when I've modified the files, so I know the detection system is active. When I get new .com or .exe files, especially binaries off the net or from bulletin boards, I run CHK4BOMB on each one to look for ascii text that suggests the possibility of a Trojan, as well as to see if the program might generate disk write activity. I then use Data Physician's DISKLOCK program that isolates my hard disk from the floppies. I switch to a floppy and execute the program a specified number of times. On the floppy is a copy of Sophco's CANARY program that tells you if it's been infected by a virus. If that passes, I then change the system date and run the program several more times. If everything checks out, I presume that the program is safe and proceed to use it. Granted, none of this is fail-safe, yet I feel some responsibility to check this stuff, especially since I usually end up passing it out to interested users here at the University. If I can get source code, we often regenerate the binaries from that. Hope this might be of interest.... David J. Buerger Santa Clara University dbuerger@scu.bitnet ========================================================================= Date: Wed, 15 Jun 88 16:49:43 CST Reply-To: Virus Discussion List Sender: Virus Discussion List From: David Camp Subject: Re: virii on large(r) machines In-Reply-To: Message of Wed, 15 Jun 88 15:02:03 BST from >So far this distribution list seems to have >concentrated on micros - are there any instances >of virus attacks on mainframes/minis/supermicros >(ie multi-user machines bigger than PC-AT's) Within the last year there was a major infection of .BITNET by the program XMAS EXEC. Since most .BITNET nodes are running VM/CMS, it was able to take advantage of a common environment. It required the gullibility of the receiving user to propagate. Once run, it displayed a Christmas Tree (as promised) on the screen, but then proceeded to redistribute (SENDFILE) itself to every user in ones NAMES file (the CMS equivalent of a Rolodex). I read one message that said it also consulted your NETLOG for prospective destinations. An international effort commenced to eradicate the virus and to identify the originator. The last word was the user was identified and stripped of his network access privileges. Supposedly large portions of .BITNET were overloaded by this virus, and had to be temporarily disconnected. -David- > >It strikes me that since so many of these machines >(especially in the academic community) are networked >there is definitely a distribution medium for >virii. The only incidents I've heard of have all >required huming beans to help "propogate" (?) >the virus from one machine to another (XMAS EXEC?) > >Ian >--- >JANET: cs_iob@uk.ac.bath.ux63 Ian O'Brien, Systems Programmer, >OTHER: cs_iob@ux63.bath.ac.uk Bath University Computing Services >USENET: ..!mcvax!ukc!bath63!cs_iob *----------------------------------------------------------------------* | (314) 362-3635 Mr. David J. Camp | | ^ Division of Biostatistics, Box 8067 | | Room 1108D < * > Washington University Medical School | | 706 South Euclid v 660 South Euclid | | Saint Louis, MO 63110 | | Bitnet: C04661DC@WUVMD.BITNET | | Internet: C04661DC%WUVMD.BITNET@CUNYVM.CUNY.EDU | | or: david@wubios.wustl.edu | *----------------------------------------------------------------------* ========================================================================= Date: Wed, 15 Jun 88 17:04:56 CST Reply-To: Virus Discussion List Sender: Virus Discussion List From: David Camp Subject: Re: NYPC meeting summary In-Reply-To: Message of Wed, 15 Jun 88 10:05:24 EDT from > > >That brings me to my next topic (finally :-). I'd like to hear from >people who've used commercial (and non-commercial) anti-virus packages. >Hopefully, we can generate some objective discussions on the various >packages here on VIRUS-L. Any takers? Some of the currently available >packages are, in no particular order: (a thousand pardons to any >which I neglect!) > >Data Physician >Flu Shot I have had a limited experience with an early version of FLUSHOT. I downloaded it to my PC and installed it as instructed. I then proceeded to use my favorite software. I quickly realized that this program was being over-protective. I could not get any normal work done because of the incessant interrupts. I suppose it would be useful when you are trying out a new program. Since it prevented many correct programs from working, I doubt it could identify a rogue. Remember, this was an early version. I do not know what improvements have been made since then, but with the dopplegangers on the market, I am afraid to pursue it any further. -David- >Disk Watcher >Vaccine (there are a number of products under this name!) >Vaccinate >Checkup >Disk Defender >Panda >...the list goes on > >So, let's hear from people who've used these (or others). > >Ken > >Kenneth R. van Wyk >User Services Senior Consultant Steve Dallas: Who's driving?! >Lehigh University Computing Center Opus: Oh keep your pants on, >Internet: I pressed cruise control. >BITNET: *----------------------------------------------------------------------* | (314) 362-3635 Mr. David J. Camp | | ^ Division of Biostatistics, Box 8067 | | Room 1108D < * > Washington University Medical School | | 706 South Euclid v 660 South Euclid | | Saint Louis, MO 63110 | | Bitnet: C04661DC@WUVMD.BITNET | | Internet: C04661DC%WUVMD.BITNET@CUNYVM.CUNY.EDU | | or: david@wubios.wustl.edu | *----------------------------------------------------------------------* ========================================================================= Date: Wed, 15 Jun 88 18:39:00 EST Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Loren J. Miller, WCIT" Subject: WordPerfect virus (?) and Brain Hello Virus Fighters, Recently we have been having some problems with WordPerfect, which is the Word Processor installed in the computer labs of the Wharton School. One of our people sent out a message which briefly described the problem as she saw it. The message is at the bottom, below my notes. Note that sometimes the floppy disks of those people who are bitten by this virus have a volume name "(C) Brain". We know that Brain is "supposed" to be a malign virus, but every time we have examined the code written by Brain to the floppy to propogate itself, it looks pretty harmless, and when we boot on a Brain diskette it doesn't progressively chomp up the disk with bad sectors. It looks like it alters the boot sector and makes a copy of itself in another sector which it marks as bad, then stops, awakening only to copy itself to a new disk (the Brain we have been able to isolate can't propogate itself on a HP Vectra, which is our most common PC clone). This particular Brain cannot infect hard disks (at least on a HP Vectra), it only gets DS/DD floppies, and the only way it gets in our labs is by people coming in and running an infected program off their own floppy. One of the problems with identifying this virus (we've been calling it the Error 31 Virus) is that any time it strikes, demolishing the FAT, the computer (in our labs HP Vectras) hangs up and won't respond to any keyboard commands. When the computer is restarted all signs of the virus executable are gone. While this is an excellent prophylactic measure against infection, the users of our lab do not turn computers off and on before they start working on them, instead they gravitate to the computers that are already on. Linda's description of the problem follows here. >From: FRED::BOHNSACK "Linda Bohnsack" 9-JUN-1988 16:18 >To: CONSULTANT >Subj: What to do when someone reports a possible virus or you suspect a virus! > >Recently we have seen the Disk Error 31 problem in WordPerfect. We suspect >that this is a virus which attaches itself to the WordPerfect program. We have >no idea where it comes from, but we know that it is invoked when saving a >file. > >This particular suspected virus erases both FATs (File Allocation Tables), and >the information cannot always be recovered from the disk afterwards. > >So what do we do? > >IF IT IS A KNOWN VIRUS: (We should have a brief explanation on how to fix > the disk AND/OR recover the information.) > > (c) Brain is a known virus which is known to have no damaging effect > on the files of the disk. It modifies the boot area and marks a few > sectors as bad. A disk can probably also become infected with a > damaging virus to create damage on a disk making it appear as if > it is a (c) Brain damaged disk. > > If anyone does discover beyond a shadow of a doubt, a (c) Brain > virus that is damaging - bring it to me.....I've got to see it before > I'll believe it. > > >IF IT IS A SUSPECTED VIRUS: (We need to collect information on it.) > > 1. Alert the user not to reboot the machine, if possible. > > 2. Take down the machine number (or position in the lab). > > 3. Have the user put a sign on the machine - DO NOT USE - VIRUS. > (If the user is desparate about his file, reboot to recover > a WP backup file {WP}BACK.1 in the public directory.) > > 4. Attempt to recover the disk information for the user with > NORTON UTILITIES in MAINTENANCE mode (if you don't know how to > do this have them wait for Michael or a more experienced PC > consultant). > > 5. If you have the machine unrebooted, alert Linda to take a look > at it. (to collect more info on it). (If Linda is not available, > please leave a message with Lisa or the receptionist in 315. > Phone : 898-1395) > > 6. Send MAIL to Linda, Michael, Loren and Carol so that we can track > the problem machines for the code or to replace the software if > it repeats the problem within the week. > >ALSO be kind to our user. Appear concerned, empathetic, and calm. > >PLEASE do not get excited. An excited consultant creates a panicked user. >(This theory is akin to being calm during fire alarms, and air raids.) > >The user is probably near hysteria already because they just lost x hours >of work on our computers. If anybody else has seen something similar to this situation, or has otherwise pertinent information, please comment to me via the list. * * * * * * * * * * * * * Thanks! * * * * * * Loren J. Miller * * * * Senior Large Systems Consultant * * * Computing and Instructional Technology * * The Wharton School * * University of Pennsylvania * (215) 898-1837 U.S. Mail: Internet: -------------------------------- ------------------------- 301 Steinberg Hall-Dietrich Hall MILLERL@WHARTON.UPENN.EDU 3620 Locust Walk -or- Philadelphia, PA 19104 MILLERL@WHARTON "He has the right to criticize who has the heart to help" - Abraham Lincoln ========================================================================= Date: Wed, 15 Jun 88 20:43:37 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: me! Jefferson Ogata Subject: Re: hidden files on VM/CMS > From: Kenneth Ng > I'm not sure how this works, but look at sendfile with the acknowledge > option. When a receive is performed, a file 'Acknowl dgement' is > sent back to the host. Therefore my bet is that it has something > to do with the 'netdata' format. Actually it has nothing to do with acknowledge or Netdata format. It uses disk dump format through your virtual punch. It first spools your punch continuous, then disk dumps various files to it and closes the punch file. The only file that shows up to RDRLIST or Q RDR is the first disk dump. It IS possible to check whether the number of lines in the file matches with what a Q RDR says, but how many people do that? - Jeff Ogata ========================================================================= Date: Wed, 15 Jun 88 22:44:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: WHMurray@DOCKMASTER.ARPA Subject: Re: virii on large(r) machines In-Reply-To: Message of 15 Jun 88 10:02 EDT from O'Brien It is true that most of the network viruses have depended on duping the target into executing the virus. The XMASCARD EXEC simply demonstrates how easy that is to do. The demonstration is even more powerful because many of the victims of that virus have been specifically warned not to execute unsolicited programs. They have even been specifically warned about Christmas greetings. VM, Unix, Multics and VMS are particularly vulnerable because they employ the same name space for programs and data. VM and Multics are slightly less vulnerable to the extent that executables do have specific file types. However, one should always be careful regardless of the name or type. In his Turing Award paper, Ken Thompson demonstrates that one man's data is another man's program. Both Thompson and Cohen point out conditions under which application data can be employed as the vector to distribute a virus. A problem for any virus designer is to get his code executed. The PC viruses have demonstrated a number of solutions to this problem. It would not be appropriate to discuss any further solutions to that problem here. Suffice it to say that good computer hygiene requires that you not accept any unsolicited mail and be careful even with data from known sources. Note that the XMASCARD appeared to come from a friend. Good hygiene also requires that you not execute untrusted code while connected to the environment. VM offers a solution to this problem; that is to run VM under VM. In this event you will own all of the products of the execution, since you own the virtual punch/network. Of course this assumes that you have access to a copy of VN/CP and sufficient resource to execute it. As I have pointed out before, although the author of a virus can predict how it will behave in the target execution environment, he cannot predict very well how it will behave in a population. If you introduce a virus into the population of which you are a member, then you will likely be one of its victims. Since you cannot predict how it will behave in the population, you can still be the victim even if you yourself are immune. Note that the author of the XAMSCARD was immune since he would recognize it and not be duped. However, he was still a victim of the saturated net. Note that the XMASCARD was benign in the execution environment. However, in the net, it was far more destructive than the author himself could have expected or predicted. ========================================================================= Date: Thu, 16 Jun 88 00:46:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List Comments: Resent-From: WHMurray@DOCKMASTER.ARPA Comments: Originally-From: WHMurray@DOCKMASTER.ARPA From: WHMurray@DOCKMASTER.ARPA Subject: Re: The Intruder Versus the Hacker In-Reply-To: Message of 15 June 1988 14:15 edt from MALCOLM%JVAX.CLP.AC.UK at CUNYVM.CUNY.EDU > Well, he's got a point. Once someone's got a taste of the havoc they > can cause with their very own virus, would *you* trust them to look after > your systems? I can conceive of the circumstances under which I might. But the author of such an assignment has a much more difficult problem. He must trust fifteen or so people, all of whom have the pride of authorship that he has given them, never to let their creation out of the sterile environment. That is a much less sanguine situation. I might be willing to trust three people who were mature and informed, but to trust fifteen, at least some of whom are young, and about whom I can have at best a limited knowledge would be at least risky. Given the destructive potential of a virus, it is clearly unprofessional. ____________________________________________________________________ William Hugh Murray 216-861-5000 Fellow, 203-966-4769 Information System Security 203-964-7348 (CELLULAR) Ernst & Whinney ARPA: WHMurray @ DOCKMASTER 2000 National City Center MCI-Mail: 315-8580 Cleveland, Ohio 44114 TELEX: 6503158580 FAX: 203-966-8612 21 Locust Avenue, Suite 2D Compu-Serve: 75126,1722 New Canaan, Connecticut 06840 ENVOY 100: WH.MURRAY ========================================================================= Date: Thu, 16 Jun 88 00:58:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: WHMurray@DOCKMASTER.ARPA Subject: Re: a few points In-Reply-To: Message of 15 Jun 88 11:57 EDT from "me! Jefferson Ogata" The XMASCARD EXEC was reported in the Wall Street Journal and has been dicussed in this forum and in RISKS. It originated in BITNET where it was fairly benign, but passed into VNET via a gateway. When executed it displayed a greeting to the user and sent a copy of itself to everyone in the user's maillog and NAMES file. In VNET, where the number of users known to the typical user is numbered in the high tens to low hundreds, the number of copies created saturated the net. As to the exposure that you raise, it relates to DISKDUMP rather than to PUNCH. It has been fixed. The fix is very expensive. William Hugh Murray, Fellow, Information System Security, Ernst & Whinney 2000 National City Center Cleveland, Ohio 44114 21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840 ========================================================================= Date: Thu, 16 Jun 88 09:44:06 CET Reply-To: Virus Discussion List Sender: Virus Discussion List From: Peter Vons Subject: Re: hidden files on VM/CMS In-Reply-To: Message of Wed, 15 Jun 88 14:17:57 EDT from Receiving multiple files with receive, where you only see one file in your reader is common practice within VM/CMS. Those files are generated with DISK DUMP with continous spooling of the punch. There is even a warning in the DISK DUMP help text about this. Even worse is that Receive only warns you if the visible file is already on your disk. The other (invisible) files are overwritten on existing files without any notice. I once got a PROFILE EXEC from somebody in this way without noticing. The next time I logged in again it was executed. I was lucky that it was not harmfull. I know that there are programs around on some Listservs which can signal this kind of readerfiles. Peter Vons (SOND0008@HASARA11) ========================================================================= Date: Thu, 16 Jun 88 11:45:00 LCL Reply-To: Virus Discussion List Sender: Virus Discussion List From: Michael Wagner +49 228 8199645 Subject: Re: a few points > One possible infection mode I've seen for VM/370 mainframes is an > EXEC I've seen that spools two punch files together to some user. > Only the first file appears in the header information, and there > is only one spool file. The result is that a user can transmit an > innocuous file to another person with some other file tacked on the > end. When the innocuous file is received, the other file is > received also. Don't ask me how it works.... Indeed this is (at least was) true. You can DISK DUMP two files together in a documented way, and only the first one will be announced in the header. The rest are only announced in the body itself. As I recall, if you DISK LOAD them back, you do get the list. This feature of DISK is actually useful, since it allows you to package up and send large collections of CMS files in one spool file. However, the RECEIVE command, as part of being 'user friendly', suppresses all output from the underlying functions it calls, and then you don't know if files have been overwritten. Don't know if this has been fixed in the mean time. I always used to DISK LOAD to an empty disk just to be safe. Michael ========================================================================= Date: Thu, 16 Jun 88 11:53:00 LCL Reply-To: Virus Discussion List Sender: Virus Discussion List From: Michael Wagner +49 228 8199645 Subject: Re: hidden files on VM/CMS > It uses disk dump format ... The only file that shows up to > RDRLIST or Q RDR is the first disk dump. It IS possible to check > whether the number of lines in the file matches with what a Q RDR > says, but how many people do that? More to the point, it is possible to find out what sort of reader file you have in your reader, and handle DISK DUMP files more carefully. I think the ipf RDR command will tell you this (but I don't remember the details). Michael ========================================================================= Date: Thu, 16 Jun 88 13:28:00 URZ Reply-To: Virus Discussion List Sender: Virus Discussion List From: BG0@DHDURZ2 Subject: Re: virii on large(r) machines Hi folks, in his message from 06/15/88 O'Brien mentioned the topic of mainframe viruses. He writes that nothing is known about infections of mainframes or mainframe viruses itself. Thats not correct. Fred Cohen started his experiments with computer viruses on mainframes. The first virus was written for a VAX 11/750 system running UNIX (Ultrix?). The following experiments were carried out on a UNIVAC 1108 (running a Bell- LaPadula system), on a Tops-20, on a VAX running VMS and on a VM/370 system. So you can see that the first viruses were mainframe viruses and *NOT* PC-based viruses. But it seems to me that Fred Cohen was not the first one to implement self- reproducing code on a computer. I want to mention the work of J.Kraus from the University of Dortmund 1980/81 (3 years before Cohen). The title of the paper was "Selbstreproduzierende Software (self-reproducing software)". He gives a very complete theoretical background of selfreproducing software and some examples of such code in a real assembler language (SIEMENS assembler language; the same assembler language as the IBM/370 system but with a different operating system - but also a mainframe). Interesting note: You cant get the orignal work from 1980 but just a modified (and I think "moderate") version from 1981. Someone wants to keep things secret. :-( I wrote a replacing virus for a IBM 30xx running MVS/370 a year ago. Its about 600 lines long. Because my account on that machine is restriced to "harmless" applications after the system manager realized what I am working on, I was not able to improve the virus... What about "non-academic" virus infections on mainframes? I never heared of any case that was verified to be a virus infection. But there are some rumors about that. The first one I knew is related to the events in Berlin, January 1986. On Jan. 23,1986 some students at TU (technical university) Berlin announced a strike for better payment. These students are employed by the university to support younger students in their studies at the department of computer science. So the striking students are very knowledge- able of the IBM 4381 running VM. What happend? On Jan.31,1986 the mainframe performance was bad as never before. It was impossible to use the computer. The system managers noticed that many parts of the operating system and most application programs spend a lot of time to increase a counter and then to decrease the counter again before they start their normal execution. This "increase/decrease of useless counters" increases with time so some people expected to find a virus. Did they found one? I dont know. The mainframe was disconnected from all networks for 14 (!!) days and everything was analysed by computer stuff from IBM and the university. They "solved" the problem by generating a very new system and to "erase" all application programs. So if you want to know more about it I think you have to ask the TU Berlin, Department of Computer Science or IBM.... There are two or three more rumors about virus on mainframes but much less is known about the circumstances so I dont want to mention them here. All the best to you all, Bernd. +--------------------------------------------------------------------+ I "Beam me up, Scotty. There is no intelligent life down here..." I +--------------------------------------------------------------------+ ========================================================================= Date: Thu, 16 Jun 88 08:58:41 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: forwarded review from Ted Shapin From: Ted Shapin Subject: Review of IBM Protection Programs This file is IBMPROT.DOC. Reviews of Virus Protection Programs Please feel free to add to this list. Version 1, 6/15/88, T. Shapin =============================================================== Class 1 are programs that warn of changes to system files after the fact. These methods either compute some sort of CRC or hash sum, or compare a file against a copy of the file. While it is theoretically possible for a particular CRC to be forged, each program seems to use a different algorithm for the computation so that different values are obtained. Furthermore, each version of DOS will give a different values, so I doubt that the signature can be forged practically. =============================================================== CHKSUM.ARC, contains: CHKSUM.C, CHKSUM.DOC, CHKSUM.EXE, CRC16.C, STOI.C. From: Bob Taylor, compiled using Turbo C 1.5. What it does: Computes a redundancy check (CRC) for any file, (including system and hidden), and compares a computed CRC for a file with a specified one given as a parameter to the program. Wildcard file names and more than one filename can be supplied as parameters. Either gives a warning message or optionally sets a return code. On a vanilla 4.77 Mhz PC, it takes about 7 seconds to check all three system files. Evaluation: Fast and very useful. [T.S.] - - - - CHECK-OS.ARC, contains: CHECK-OS.DOC, CHECK-OS.EXE, CHECK-OS.PAS. From: R.J. Bartlett & Erik Ch. Ohrnberger Compiled with Turbo Pascal version 4.0. What it does: It checks the Filesize, File Date/Time (last updated), and Checksum of COMMAND.COM, AUTOEXEC.BAT, and CONFIG.SYS. Will also check system files. Evaluation: On my system it would not handle the "FCBS=" parameter in my CONFIG.SYS file. It needs some work. [T.S.] - - - - CHKUP14.ARC, contains: CHECKUP.DOC, CHECKUP.EXE, REGISTER.DOC. From: Richard B. Levin. BBS's: (215) 969-8379 or (215) 635-5226 Compiled Microsoft BASIC v.6.0 What it does: Compares a target file's size, its incremental checksum, and its total checksum. Evaluation: While the method of computing hash sums would be difficult to forge, it prints lots of messages when it runs, and there is no provision for returning error codes that can be tested in a batch file. I find the the lack of source code a minus and the appeals for money obnoxious. [T.S] - - - - CONDOM.ARC, contains: CONDOM.BAT, CONDOM.DOC, CPY.C, CPY.EXE, DIF.C, DIF.EXE, READ-ME.NOW. From: Charlie Ros5e [sic], Boulder, Colorado, BBS Fido Node 104/23, Account Name: Charlie Rose; and Gerry Williams, Albuquerque, New Mexico, BBS Fido Node 15/1001. DIF.C and CPY.C, were compiled with Aztec C86, Version 3.40b, Manx Software Systems. What it does: CPY makes a reference copy of any file, including system, or hidden. DIF compares a current file to the reference copy and sets an error return code that can be tested in a batch file that indicates what happened. Evaluation: Very useful for checking system files for any changes. [T.S.] - - - - FILECRC.ARC, contains: COMPARE.CHN, COMPARE.COM, COMPARE.PAS, FILECRC.COM, FILECRC.DOC and FILECRC.PAS. From: Ted H. Emigh, Department of Genetics, North Carolina State University Box 7614, Raleigh, NC 27695-7614, emigh@ncsugn.uucp, NEMIGH@TUCC.BITNET. Compiled with Turbo Pascal 3.0. What it does: FILECRC creates a list of all the files on the default drive along with creation date, file size, and a CRC (cyclic redundancy check) for each file. When FILECRC is run again the new list is compared with the old list. Evaluation: I tried it on two systems and it didn't work. They both hung and I had to reboot. [T.S] - - - SYSCHK1.ARC contains SYSCHK.EXE and SYSCHK.DOC. From: Terratech, 19817 61st Ave. S.E., Snohomish, WA 98290 What it does: Performs checksums of the first and second files in the root directory and the COMSPEC file. These are the three system files. The first time the checksums are displayed. If they are given as parameters, they are compared against the current values. Error levels are set so a batch file can test the results. Evaluation: Works well. This is shareware, with donation information only given if you request it with "SYSCHK /?". [T.S.] - - - - VACCINE.ARC, contains VACCINE.EXE, VACCINE.DOC. From: BBS (616)361-7500 What it does: A compiled BASIC program that will give the size, time and date of a supllied file name. If these are given as parameters, it will compare the current values with the parameters and print a message that they agree or disagree. It will not read files with the system attribute. Evaluation: Probably not very useful. [T.S.] - - - - VIRUSCK.ARC contains: LICENSE, README, VIRUSCK.DOC, VIRUSCK.EXE. From: Matt Cohen, PO Box 10589, State College, PA 16805-0589 Written in Turbo or Microsoft C Source code: 83 lines What it does: It runs a program and reports any changes in its size or date after it is executed. Evaluation: Not recommended. [T.S.] =============================================================== Class 2 programs terminate and stay resident and attempt to stop undesirable activity. =============================================================== C-4.COM, INSTALL.EXE From: Interpath, 4423 Cheeney St., Santa Clara, CA 95054, (408) 988 3832. What it does: This is a commercial product that costs $40. It makes itself resident, hooking vectors 9, 13, 21, 22, 26 and 2F. A message pops up if any forbidden disk activity tries to take place and gives you the option of allowing or aborting the action. It protects against any program that attemots an interrupt level write ti a disk, or any program that attempts to modify or rename an EXE or COM program or CONFIG.SYS. Evaluation: It does not warn of batch file modifications. The vendor has cooperative in modifying the program when indesirable interactions with other TSR programs were found. Useful in a situation where existing applications are being run. Probably not suitable for use where programmers are busy developing new programs. (These people seem to operate the National BBS Society, too.) [T.S.] - - - - DPROTECT.ARC contains: DPROTECT.COM, DPROTECT.DOC, READ.ME. From: Gee M. Wong for Public Domain use ONLY. What it does: It installs itself as a resident program, and monitors the use of the BIOS level interupt 13H to protect one or more disks. If it detects a write request to a protected disk, it will warn you and then reboot your PC. Evaluation: Not very practical. I need to be able to write to my hard disk. [T.S.] - - - - STOP1.ARC contains: NEWSTOP.ASM, NEWSTOP.COM, STOP.DOC. From: Carey Nash, The Programmer's Forum, (818) 701-1021 What it does: TSR that hooks interrupt 13H used for ALL low level disk I/O. If write or format is requested, it will not allow interrupt 13 to perform the command, but instead, it return a value to tell the calling program that the write, or format was successful. It also uses interrupts 9 and 1C. It can be turned on and off from the keyboard. Evaluation: When I tested it with a program that modifies sector 0, it an error message saying A: was write protected. It might be useful in particular circumstances with unknown programs, but I would not recommend it for general use. [T.S.] - - - - HDSENTRY.ARC contains: HDSENTRY.ASC, HDSENTRY.ASM, HDSENTRY.COM, and README.1ST. From: Andrew M. Fried, 895 Cynthia Drive, Titusville, Fla. 32780 (305) 268-4500 What it does: It will enable you to run any program on a floppy drive undisturbed, but prevent most programs from accessing the hard disk for any type of destructive call. Nondestructive calls such as reading or resetting the drive are permitted; formatting and writing to the disk are trapped and prevented from occuring. Interrupt 26h, the absolute disk write interrupt, is also effectively removed from the system by this program. Hooks interrupt vectors 13h and 26h. Evaluation: Useful. It prevented a program from changing sector 0 on my hard disk, although the program ran to completion and thought that it did. [T.S] - - - - BOMBSQAD.ARC contains: BOMBSQAD.COM, BOMBSQAD.DOC. (Version 1.3) From: Andy Hopkins, 526 Walnut Lane, Swarthmore, PA 19081. BBS: 302-764-7522 What it does: It hooks interrupt vectors 13 and 70, intercepts calls, displays what is going to happen, and asks if you want to continue Evaluation: It did stop calls to write to a sector on my hard drive, but it also interfered with being able to read from A: when it should have allowed that operation. [T.S.] ================================================================= Class 3 Combination programs. These combine a check of system files with a TSR part that watches for dangerous disk activity. ================================================================= FSP-12.ARC contains: $READ_ME.1ST, $TOC, FLUSHOT.DAT, FLU_POKE.COM, FLU_REG.FRM, FSP.COM, FSP.TXT, F_FEED, HARDWARE.TXT, MY_OWN.CPY, PRINT.BAT, RAMNET.TXT, REWARD.FRM, REWARD.LST, THE_COOP.TXT, UPDATES.TXT. [Flu_shot+] From: Ross M. Greenberg, 594 Third Avenue, New York, N.Y. 10016 BBS:(212)-889-6438. What it does: After performing a check sum of the three system files, it installs itself as a TSR COMMAND.COM copy, hooking interrupt vectors 8, 9, 13, 20, 21, 26, 27 and 28. It reads a data file that tells how you wish files to be protected, e.g. no read, read only, no EXE or COM or BAT files, etc. When any program attempts to do something forbidden, a pop-up window tells you and lets you abort or allow the operation. Evaluation: Although PC Magazine, June 88 recommended it, a number of people have reported serious bugs that have not yet been fixed by the author. At this time, this version is *not* recommended. ================================================================= Miscellaneous ================================================================= CHK4BOMB.EXE ("Check for Bomb"). From: Andrew M. Fried, 895 Cynthia Drive, Titusville, Fla. 32780 (305) 268-4500 What it does: It reads a .EXE of .COM program file from disk and attempts to spot dangerous code and suspicious messages. Evaluation: Useful for displaying text strings in program files, but of almost no usefulness for virus protection. [T.S.] - - - - VIRU-SIM.TXT, VIRU-SIM.EXE. From: National BBS Society/ICUG, 4423 Cheeney Street, Santa Clara, CA 95054. Voice - 408 727 4559, BBS - 408 988 4004 What it does: VIRU-SIM is a program that simulates characteristic activities that .COM and .EXE infector viruses use for replication. It also simulates some of the destructive activities used by viruses to destroy disk information. It does not simulate the infection techniques of boot infector viruses (such as the Pakistani Brain Virus). VIRU-SIM may be used as a tool to test the effectiveness of anti-viral measures and as demonstration tool for viral replication activities. VIRU-SIM is available free of charge from the BBS Society's Homebase bulletin board, or is available on diskette for a $3.00 mailing and handling fee. Evaluation: Useful for testing protection programs. [T.S.] ======== end ======= Kenneth R. van Wyk User Services Senior Consultant Steve Dallas: Who's driving?! Lehigh University Computing Center Opus: Oh keep your pants on, Internet: I pressed cruise control. BITNET: ========================================================================= Date: Thu, 16 Jun 88 16:29:48 +0300 Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Y. Radai" Subject: Re: a few points The message "a few points" from "me! Jefferson Ogata" mentioned both an EXEC virus for VM/370 mainframes and a virus which survives recompilation even though no trace of it remains in the source program. Several people have commented on Jeff's first point. I just wanted to remark that an excellent article describ- ing the second type of virus can be found in ABACUS, Vol. 4, No. 4 (Summer 1987), pp. 7-25. Y. Radai Hebrew Univ. of Jerusalem RADAI1@HBUNOS.BITNET ========================================================================= Date: Thu, 16 Jun 88 09:42:09 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "David M. Chess" Subject: Christmas-card EXEC Nit: the file was named "CHRISTMA EXEC", not "XMASCARD EXEC" (as Bill Murray has referred to it once or twice). Just to keep things as clear as possible... Dave Chess, IBM T. J. Watson Research Center (Affiliation given for identification purposes only) ========================================================================= Date: Thu, 16 Jun 88 10:24:12 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: forwarded comments on compiler virus These comments on a compiler virus come to us from Martin Ward: From: Martin Ward Date: Thu, 16 Jun 88 10:44:59 +0100 One way to get around the C-compiler virus (which exists only in the executable and copies itself into any new version of the C compiler it compiles) is to write a "quick and dirty" C _interpreter_ in C. This can be safely compiled by the infected compiler (since presumably it can't recognise and infect an interpreter), then you use the interpreter to interpret the (clean) compiler source code compiling itself to generate a (clean) compiler executable. I have heard of a more insidious version of such a virus which lived in the C compiler executable and the login executable. The login executable allowed anyone who typed in a certain userid to log in as root without needing a password, the compiler executable recognised that it was compiling "login" an inserted the extra code - it also recognised if it was compiling a C compiler and inserted the recognition code in that! Thus no trace of the virus appeared in any source code. Totally unconfirmed rumour has it that these executables actually made it out on a release tape, the implication being that if large parts of AT&T became infected then after the next release the virus author would have a back door into any UNIX system which had the new release. Martin. My ARPANET address is: martin%EASBY.DUR.AC.UK@CUNYVM.CUNY.EDU JANET: martin@uk.ac.dur.easby BITNET: martin%dur.easby@ac.uk UUCP: ...!mcvax!ukc!easby!martin Kenneth R. van Wyk User Services Senior Consultant Steve Dallas: Who's driving?! Lehigh University Computing Center Opus: Oh keep your pants on, Internet: I pressed cruise control. BITNET: ========================================================================= Date: Thu, 16 Jun 88 13:03:14 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Joseph Sieczkowski Subject: Rumor >I have heard of a more insidious version of such a virus which lived in the >C compiler executable and the login executable. The login executable >allowed anyone who typed in a certain userid to log in as root without needing >a password, the compiler executable recognised that it was compiling "login" >an inserted the extra code - it also recognised if it was compiling a C >compiler and inserted the recognition code in that! Thus no trace of the >virus appeared in any source code. I believe that the rumor that you are speaking of is that of the first C compiler. Supposedly the authors (Kerningham and Ritchie) put this little chunk of code in so they could log into any unix system. If the processes were listed, someone was running login (in actuallity, they were floating around the system.) This problem was quickly fixed with the next version. joes@scarecrow.csee.lehigh.edu PS: Fred Cohen briefly mentioned in his thesis that the NSA was rumored to having something like this floating around on various systems. As to its truth, I have no idea. ========================================================================= Date: Thu, 16 Jun 88 13:39:27 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List Comments: In-Reply-To: 15 Jun 88 11:57:09 EDT From Jefferson Ogata From: Otto Stolz +49 7531 88 2645 Subject: VM/SP: Two-files-in-one from reader This is an old topic to people concerned with data integrity in VM/SP systems :-( . I always had hoped, it would not become known too widely. There exists a clean version of the MODULE internally called by RECEIVE and other commands, which won't accept partitioned files. As far as I know, it is available to node administrators only from their respective NETSERV nodes. Regards Otto Stolz ========================================================================= Date: Thu, 16 Jun 88 13:32:00 EST Reply-To: Virus Discussion List Sender: Virus Discussion List From: GILL@QUCDNAST Subject: Re: Sent VM/CMS viruses It seems to me that it is easy enough to BROWSE or PEEK at an incoming file before RECEIVEing it. In such a situation, shouldn't the extra files also be shown if one searches far enough through the file listed in RDRLIST? Another point, the hidden second (or third - is this possible?) file would have a certain number of lines. Is this not included in the number of records listed in RDRLIST? As far as I can see, the possibility of such a thing being allowed to happen is enough to convince me that that particular part of VM/CMS is BROKEN and needs to be fixed in a hurry. You want to see some quick action? Send a malignant virus through such a method to IBM. If it infects them, then solution will be on the table within days, that is if IBM dares to admit that they had been infected. ____________________________________ Arnold Gill | If you don't complain to those who | Queen's University at Kingston | implemented the problem, you have | gill @ qucdnast.bitnet | no right to complain at all ! | ------------------------------------ ========================================================================= Date: Thu, 16 Jun 88 11:27:00 CST Reply-To: Virus Discussion List Sender: Virus Discussion List From: DAVIDLI@SIMVAX Subject: RE: Re: The Intruder Versus the Hacker William Huhg Murray writes: >MALCOLM%JVAX.CLP.AC.UK at CUNYVM.CUNY.EDU writes: >> Well, he's got a point. Once someone's got a taste of the havoc they >> can cause with their very own virus, would *you* trust them to look after >> your systems? >I might be >willing to trust three people who were mature and informed, but to trust >fifteen, at least some of whom are young, and about whom I can have at >best a limited knowledge would be at least risky. Given the destructive >potential of a virus, it is clearly unprofessional. Please define "mature and informed". Relate your definition to readers of this particular list. Then demonstrate how "youth" with this knowledge are any more risky than the "mature and informed". When you have done that, please relate the study of the creation and destruction of a computer-virus with the study of computer security issues. Finally -- justify your own "right" to read and/or post to this list, in view of the fact that the information posted here may [or may not] be useful to those seeking to circumvent computer-virus protection measures. After you have done so, I may listen to such specious argumentation as has appeared on this list ever the past week or so. ========================================================================= Date: Thu, 16 Jun 88 14:05:27 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: Re: Sent VM/CMS viruses In-Reply-To: Message of Thu, 16 Jun 88 13:32:00 EST from >You want to see some quick action? >Send a malignant virus through such a method to IBM. If it infects them, >then solution will be on the table within days, that is if IBM dares to admit >that they had been infected. You may well see a whole lot more than just action by doing that. No, that is *not* a good idea to encourage. I believe that William Murray pointed out that the bug in VM/SP has already been fixed anyway. Getting attention in the above manner is, I repeat, *NOT* a good idea. Ken Kenneth R. van Wyk User Services Senior Consultant Steve Dallas: Who's driving?! Lehigh University Computing Center Opus: Oh keep your pants on, Internet: I pressed cruise control. BITNET: ========================================================================= Date: Thu, 16 Jun 88 10:51:12 PLT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Andrew Vaught <29284843@WSUVM1> Subject: PC Anti-Viral Programs It would be easy for a virus to avoid "online" detection by many of the anti-viral software now available-- Simply have the virus check the INT 13h vector before it does any disk work. If the vector does not go directly to DOS, then abort and remain undetected. Now the virus has been stopped from propagating, (and even fooled by a legitamate TSR that has put its own hook in), but it still remains undetected. Another way around the use of interrupts would be to do its own low-level disk I/O, but this would probably restrict it to one particular brand of PC- hardware differences may prevent it. I suppose the best way would be to make a table of all the INT 13h vectors for each release of the DOS, and use that. Unless MS-DOS loads the read/write handlers into different places depending on how the machine is booted up, the virus is shooting at stationary targets. Andy ========================================================================= Date: Thu, 16 Jun 88 14:55:42 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: me! Jefferson Ogata Subject: some more points > From: Bill Fenner > That doesn't dignify a response. Hmm...curious. Then what were you doing? > From: GILL@QUCDNAST > Subject: Re: Sent VM/CMS viruses > It seems to me that it is easy enough to BROWSE or PEEK at an > incoming file before RECEIVEing it. In such a situation, shouldn't > the extra files also be shown if one searches far enough through the > file listed in RDRLIST? Another point, the hidden second (or third - > is this possible?) file would have a certain number of lines. Is this > not included in the number of records listed in RDRLIST? The other files are not visible to BROWSE or PEEK. The number of lines will differ between PEEK and Q RDR however. Many people (I, for one) ALWAYS PEEK incoming files before RECEIVEing them. It's the handiest way I know of deciding whether the file warrants your disk space. For example, I PEEK incoming VIRUS-L mail. :-) The suggestion about infecting IBM is a very bad one I think. > From: Andrew Vaught <29284843@WSUVM1> > Subject: PC Anti-Viral Programs > It would be easy for a virus to avoid "online" detection by many of > the anti-viral software now available-- Simply have the virus check the > INT 13h vector before it does any disk work. If the vector does not go > directly to DOS, then abort and remain undetected. Why abort? The virus can just take note of the vector, install a new vector straight to DOS, and restore the old one when it's finished. Alternatively it can just make direct calls to DOS without using the interrupt vector at all. - Jeff ========================================================================= Date: Thu, 16 Jun 88 19:43:00 CST Reply-To: Virus Discussion List Sender: Virus Discussion List From: David Camp Subject: Banish the List I am proposing this just as a possibility. Suppose the VIRUS-L list became a source for would-be virus-writers? There has been a lot of information on the list that may help one write a virus. If I were interested in creating viruses, would I not surely subscribe? Perhaps this is a reason for the list to be moderated/ censored. Perhaps this is cause to abolish the list. Feel free to flame if you must, my bit-bucket is industrial size. -David- *----------------------------------------------------------------------* | (314) 362-3635 Mr. David J. Camp | | ^ Division of Biostatistics, Box 8067 | | Room 1108D < * > Washington University Medical School | | 706 South Euclid v 660 South Euclid | | Saint Louis, MO 63110 | | Bitnet: C04661DC@WUVMD.BITNET | | Internet: C04661DC%WUVMD.BITNET@CUNYVM.CUNY.EDU | | or: david@wubios.wustl.edu | *----------------------------------------------------------------------* ========================================================================= Date: Thu, 16 Jun 88 22:11:00 EST Reply-To: Virus Discussion List Sender: Virus Discussion List From: ACS045@GMUVAX Subject: reply to "Banish The List" > I am proposing this just as a possibility. Suppose the VIRUS-L >list became a source for would-be virus-writers? There has been a >lot of information on the list that may help one write a virus. >If I were interested in creating viruses, would I not surely >subscribe? Perhaps this is a reason for the list to be moderated/ >censored. Perhaps this is cause to abolish the list. Feel free >to flame if you must, my bit-bucket is industrial size. >-David- > Bitnet: C04661DC@WUVMD.BITNET > Internet: C04661DC%WUVMD.BITNET@CUNYVM.CUNY.EDU > or: david@wubios.wustl.edu I don't think much good could be done by banishing the list. For one thing, if you're coming to this conclusion only now, it seems to me to be a case of closing the barn door after the cows have escaped....This is because A. From what I've seen zip through my mailbox on here in just 1 day, I could wreak some pretty heavy havoc in a number of places, were I the twisted, childish type of person that goes in for that sort of "fun", so as far as banishing the list from that standpoint, hey, the damage has already been done, we might as well keep it up to protect ourselves. B.A lot of whats been floating around recently have been discussions of old virii and their related cures, so anybody wanting to glean virus-writing hints from here is going to have to lookm a lot harder elsewhere. Besides, if they're THAT determined, they'll do it without our "help", and are probably capable of more insidious things than what they read. Granted, we do want to keep this out of the hands of 13-yr old pimple faces and others who haven't the maturity to keep from writing these little beasties, and I'm not saying we should post the source to XMAS EXEC or (c)BRAIN on the list, but it seems to me that if somebody wants to write a virus bad enough, they'll do it....I've amazed myself a number of times at the coding solutions I've come up with to various problems(NOT, **NOT** Virii) over the years, and I'm sure that there are people out there who are a hell of a lot more clever than me..not that we should throw our arms up in the air either and wait for the next sicko to come down the | (pipe :), but use the list for what I believe it ewas started for..to share and communicate information about virii and ways of stopping them... Steve ------------------------------------------------------------------------------- Flames, comments,lawsuits,etceterizations to: Steve Okay (ACS045@GMUVAX.BITNET/acs045@gmuvax2.gmu.edu/CSR032 on The Source) "UNIX is a registered footnote of Bell Labs" ========================================================================= Date: Fri, 17 Jun 88 03:12:43 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: me! Jefferson Ogata Subject: Re: Banishing the list I strongly oppose the idea of banishing or censoring this list. I oppose the idea that information about viruses should be hidden from public view. How can we fight a problem we don't understand? The only folks who will get hurt by ignorance are those of us trying to keep our environments virus-free. Keeping viruses an open subject helps us to fight them. It MAY help the virus-writers as well, but there are probably at least 300 users for each virus-writer. Seems to me the help is way into the profit-margin. - Jeff ========================================================================= Date: Fri, 17 Jun 88 07:43:53 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: Re: Banishing the list In-Reply-To: Message of Fri, 17 Jun 88 03:12:43 EDT from ENOUGH ALREADY! I'm the listowner, and the list is going to remain. Period. If you people want to discuss the pros and/or cons of having such a list, then don't do it here. Enough said (I can't overstress this)! Ken Kenneth R. van Wyk Calvin: When I take a bath, I always User Services Senior Consultant put my rubber ducky in the Lehigh University Computing Center water first. Internet: Hobbes: For companionship? BITNET: Calvin: No, to test for sharks! ========================================================================= Date: Fri, 17 Jun 88 07:46:00 CST Reply-To: Virus Discussion List Sender: Virus Discussion List From: DAVIDLI@SIMVAX Subject: RE: reply to "Banish The List" Steve Okay writes: >Granted, we do want to keep this out of the hands of 13-yr old pimple faces and >others who haven't the maturity to keep from writing these little beasties, May I remind readers of this list that most computer crimes are committed by computer professionals, NOT "13-year old pimple faces"? May I also point out that such computer-viruses as the XMAS EXEC and the Macintosh "Happy Birthday" were written by (supposedly) mature adults. Such characterizations only serve to promote a stereotype which, as far as I'm concerned, is as far from the truth of the matter as one can get. -- David Meile, systems manager Disclaimer: standard -- my words, my thoughts. Your mileage may vary. ========================================================================= Date: Fri, 17 Jun 88 08:28:00 CDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: MADS@UNO Subject: possible conference topic Note: I originally sent this to virus-l@bitnic and discovered my error. I hope it was killed so that two messages do not appear. Conferees: The SIGUCCS (Special Interest Group - University Computing Centers and Services) will hold the annual computer center management conference in St Louis, March 15-17, 1989. One of the topics will be viruses, trojan horses, worms, etc., IF THE TOPIC SEEMS TIMELY AND WORTHWHILE. As assistant program chair for the conference, I am interested in your comments on 1) the topic; 2) possible panelists. This session is scheduled for Wednesday, March 15th at 3:00 - 5:00 at the conference site in the downtown Marriot. We do not normally provide honoraria or other reimbursements to speakers. We are hoping that you can provide us with some leads on speakers and/or organizations that are interested in this topic or have had bad experiences with viruses, etc. Send all mail directly to me (MADS@UNO) on BITNET. mads (MADS@UNO 504-286-6390) ========================================================================= Date: Fri, 17 Jun 88 14:26:47 EST Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Neil Goldman (216) 861-5000" To: VIRUS-L at LEHIIBM1 Re: Wall Street Journal, 6/17/88 An interesting article. It describes (presumably) this list as "Techies around the country experiment with program codes and computer virology, exchanging an endless stream of messages daily about virus effects, vaccine strategies, and gossip." A fairly accurate, yet somewhat trivializing, description. I have a problem with some of the vendors. Digital Dispatch, for example, claims to have the National Computer Security Center, a branch of the NSA, as a customer. I spoke with someone I know at their Office of Research and Development this morning. She said they purchased a copy of DataPhysician for evaluation. We just did so too. I guess they will say we are a customer. We, of course, are a customer. But when your average PC owner reads that, he/she will view that as an endorsement on our part. It certainly is not. That's marketing for you. Neil Goldman NG44SPEL@MIAMIU.BITNET ========================================================================= Date: Fri, 17 Jun 88 16:22:31 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: David.Slonosky@QueensU.CA Subject: Cross-checking code Would it be possible to design an environment in a different operating system to check viruses without the risk of having them infect a disk? For example, you want to check a diskette which is formatted for MS-DOS for the possible existence of a virus. Could you set up an AMIGA or a Macintosh to emulate MS-DOS and detect a suspected virus without the risk of having it contaminating your own system? This is a sketchy idea, true, but I thought I'd ask it anyway. ========================================================================= Date: Fri, 17 Jun 88 16:36:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Jim Shaffer, Jr." Subject: RE: Cross-checking code I suppose anything is possible, but the amount of work required would be quite another subject. I've seen programs written in one version of DOS that could read files written in completely incompatible versions of DOS *on the same machine*. I've also seen an Atari ST emulating a Macintosh with near-perfection. Which brings me to a question: if you were to set up an emulator, how do you protect it against virus infection? My understanding of the Mac emulator on the Atari is that probably could be infected, though I've had no hands-on experience with the emulator or with viruses. ========================================================================= Date: Fri, 17 Jun 88 17:27:00 CST Reply-To: Virus Discussion List Sender: Virus Discussion List From: DAVIDLI@SIMVAX Subject: RE: Cross-checking code Jim Shaffer writes: > Which brings me to a question: if you were to set >up an emulator, how do you protect it against virus infection? My understanding >of the Mac emulator on the Atari is that probably could be infected, though >I've had no hands-on experience with the emulator or with viruses. For all intents and purposes, those computer-viruses which infect the Macintosh via the System (or other) files, and which don't directly affect hardware would have a similar affect when using the Magic Sac Plus emulator on the Atari ST. Because that emulator does not currently work with HyperCard though, there would be little chance of becoming infected with the "Happy Birthday" computer-virus which came, as I've been told, on one of the public domain HyperCard stacks. I have not, up to this time, encountered a computer-virus using the Magic Sac Plus -- but I haven't been using any of the newer public domain software with it either. Using the pc-ditto emulator on an Atari ST would, I think, make the disk drives more susceptible to some of the computer-viruses which have been found on IBM systems. (The Atari ST can read and write IBM 3.5" disks directly.) In any case, when using software on a machine, whether that machine is being "emulated" or not, the simple precautions against computer-viruses should still be taken. ========================================================================= Date: Sat, 18 Jun 88 13:42:41 CST Reply-To: Virus Discussion List Sender: Virus Discussion List From: David Camp Subject: Re: Cross-checking code In-Reply-To: Message of Fri, 17 Jun 88 16:22:31 EDT from >Would it be possible to design an environment in a different operating >system to check viruses without the risk of having them infect a disk? >For example, you want to check a diskette which is formatted for MS-DOS >for the possible existence of a virus. Could you set up an AMIGA or >a Macintosh to emulate MS-DOS and detect a suspected virus without >the risk of having it contaminating your own system? This is a sketchy >idea, true, but I thought I'd ask it anyway. It is much easier to simply run the suspect code on a system without a hard disk. That is what I did when I downloaded PK36.EXE, the latest version of PKARC, from SIMTEL20. We have a PC-Convertible that has only two diskettes, no hard disk. I suppose this is an effective defense against simple Trojans, but a delayed-trigger virus or Trojan may get past it. -David- *----------------------------------------------------------------------* | (314) 362-3635 Mr. David J. Camp | | ^ Division of Biostatistics, Box 8067 | | Room 1108D < * > Washington University Medical School | | 706 South Euclid v 660 South Euclid | | Saint Louis, MO 63110 | | Internet: david@wubios.wustl.edu | | Bitnet: C04661DC@WUVMD.BITNET (for awhile) | *----------------------------------------------------------------------* ========================================================================= Date: Sun, 19 Jun 88 15:39:31 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: me! Jefferson Ogata Subject: Re: Cross-checking code > Would it be possible...? It would be possible; maybe not that easy. A virtual machine could be created to emulate a PC with, say, two virtual floppy drives and a virtual hard drive. The host machine would emulate the drives using swap space on its hard drive. I don't know of any way a virus could infect the host machine via swapping. Such an emulator could have various virus-oriented features, such as automatic trace of disk access -- what tracks were accessed and what files, and what net changes had been made to disk contents. It could also trace memory accesses to determine whether any funny business was going on in memory. Such an emulator would be pretty bulletproof, since it would be interpreting all of the machine code and never executing it direct- ly. A PC with a hard drive would be a good candidate for the host as well, although it would be desperately slow. Xerox workstations have a feature that allows you to stick a PC emulator card in the back and run a PC window. The workstations have a real floppy you can use, but allow you to create as many virtual floppies as you need. This might be a fairly safe way to test code. I'm not going to try it anytime soon, though. If you do try it, try it on someone else's Xerox. :-) By the way, other machines have similar features. - Jeff ========================================================================= Date: Sun, 19 Jun 88 15:43:59 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: me! Jefferson Ogata Subject: Re: Cross-checking code > Would it be possible...? It would be possible; maybe not that easy. A virtual machine could be created to emulate a PC with, say, two virtual floppy drives and a virtual hard drive. The host machine would emulate the drives using swap space on its hard drive. I don't know of any way a virus could infect the host machine via swapping. Such an emulator could have various virus-oriented features, such as automatic trace of disk access -- what tracks were accessed and what files, and what net changes had been made to disk contents. It could also trace memory accesses to determine whether any funny business was going on in memory. Such an emulator would be pretty bulletproof, since it would be interpreting all of the machine code and never executing it direct- ly. A PC with a hard drive would be a good candidate for the host as well, although it would be desperately slow. Xerox workstations have a feature that allows you to stick a PC emulator card in the back and run a PC window. The workstations have a real floppy you can use, but allow you to create as many virtual floppies as you need. This might be a fairly safe way to test code. I'm not going to try it anytime soon, though. If you do try it, try it on someone else's Xerox. :-) By the way, other machines have similar features. - Jeff ========================================================================= Date: Mon, 20 Jun 88 08:37:06 IST Reply-To: Virus Discussion List Sender: Virus Discussion List From: yosi Subject: Re: Sent VM/CMS viruses In-Reply-To: Message of Thu, 16 Jun 88 13:32:00 EST from ========================================================================= Date: Mon, 20 Jun 88 08:54:54 IST Reply-To: Virus Discussion List Sender: Virus Discussion List From: * PF03 UNDEFINED Subject: Re: PC Anti-Viral Programs In-Reply-To: Message of Thu, 16 Jun 88 10:51:12 PLT from <29284843@WSUVM1> ========================================================================= Date: Mon, 20 Jun 88 08:39:10 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: forwarded historical comments from Reid Fletcher Date: Fri, 17 Jun 88 17:56:40 MDT From: fletcher@UWYO.BITNET (Reid Fletcher) I became aware of viruses or virus-like codes around 1973. My mentors informed me of virii in existence (at least in idea form) in 1968. This places these creations firmly in the mainframe era. I remember hearing about self-replicating code in college in 1973 *for certain* although I can't recall the context. It was discussed in benign and malevolent scenarios. I had also been informed of a virus like code implanted in a piece of software that was actually distributed by the vendor. It was benign (sort of). It existed on SDS Sigma series machines running UTS (later CP-V) which had the Extended Fortran-IV compiler. The trap operated like this. If a users' source code contained the statement *GO TO JAIL (assigned GO TO) the compiler would issue an error code something along these lines: *Warning, go directly! Do not pass go. Do not collect $200. Then the compiler would cease compilation. The programmer that planted this little trick went to some trouble to disguise it. The recognition string in the compiler was coded in as a series of bytes in their decimal equivalents of the appropriate EBCDIC codes, along with totally misleading commenting. The string was declared external and actually referenced in a different module by code that was also misleadingly commented. A dedicated analyst could find it if they looked hard enough and had sufficient access to the system and listings. Reid Fletcher * GO TO JAIL and WARNING, GO DIRECTLY!... are taken from the MONOPOLY game, of course, which is property, and a trademark of Parker Brothers. Kenneth R. van Wyk Calvin: When I take a bath, I always User Services Senior Consultant put my rubber ducky in the Lehigh University Computing Center water first. Internet: Hobbes: For companionship? BITNET: Calvin: No, to test for sharks! ========================================================================= Date: Mon, 20 Jun 88 12:11:58 GMT Reply-To: Malcolm Ray Sender: Virus Discussion List Comments: Warning -- original Sender: tag was malcolm@JVAX.CLP.AC.UK From: MALCOLM@JVAX.CLP.AC.UK Subject: C compiler "virus": enough! Joseph Sieczkowski writes: > >I have heard of a more insidious version of such a virus which lived in the > >C compiler executable and the login executable. The login executable > >allowed anyone who typed in a certain userid to log in as root without needin > >a password, the compiler executable recognised that it was compiling "login" > >an inserted the extra code - it also recognised if it was compiling a C > >compiler and inserted the recognition code in that! Thus no trace of the > >virus appeared in any source code. > > > I believe that the rumor that you are speaking of is that of the first > C compiler. Supposedly the authors (Kerningham and Ritchie) put this > little chunk of code in so they could log into any unix system. If the > processes were listed, someone was running login (in actuallity, they > were floating around the system.) This problem was quickly fixed with > the next version. > > joes@scarecrow.csee.lehigh.edu > > > PS: Fred Cohen briefly mentioned in his thesis that the NSA was rumored > to having something like this floating around on various systems. > As to its truth, I have no idea. Haven't we had enough unconfirmed rumours? This one's even libellous (though I see Joseph has cleverly spelt Brian Kernighan's name wrong to halve his liability). Fact: Ken Thompson was the culprit, he described it in his 1983 Turing Award lecture (see Comm. ACM August 1984), and it wasn't his intention to provide himself with a worldwide Unix trapdoor. In fact, if anyone outside AT&T and Bell can *prove* to me that they have a current compiler with his Trojan I'll donate 10 pounds to the charity of their choice. Hey, wanna hear about the Vatican conspiracy in the VAX microcode? P.S. Of course, I'm not saying it *can't* be done, or that it *hasn't* been. But let's not get carried away, hmm? ------------------------------------------------------------------------ Malcolm Ray JANET: malcolm@uk.ac.clp.jvax Senior Systems Officer BitNet: malcolm@jvax.clp.ac.uk City of London Polytechnic No other routes please! Unix is a registered ideology of AT&T ========================================================================= Date: Mon, 20 Jun 88 19:29:00 LCL Reply-To: Virus Discussion List Sender: Virus Discussion List From: Michael Wagner +49 228 8199645 Subject: Re: reply to "Banish The List" > -- David Meile writes... > May I also point out that such computer-viruses as the XMAS EXEC > ... were written by (supposedly) mature adults. I think XMAS EXEC was written by a university student. Having been one of those myself once, and having seen various pranks pulled by freshmen and the like, I'm not sure how appropriate the word 'mature' is here :-) Michael ========================================================================= Date: Mon, 20 Jun 88 17:27:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: WHMurray@DOCKMASTER.ARPA Subject: Product demonstration report I have just seen a demonstration of VACCINE. This program computes a 32 bit CRC for all or any known programs and permits them to run unimpeded. For any unknown program, it will exclude it altogether, or permit it to run only in a protective shell. At installation option, it will check the crc at boot time or at runtime. While the overhead for checking at boot time is noticeable, that for checking at run time is not. While the impact on the user for running in the protective shell is noticeable, this need not be done often and does not involve any special set-up or invocation. In addition to the obvious application of protecting a given machine against viruses, this product can also be useful in protecting communities of machines. It can also be used for limitng users to authorized programs and for helping to ensure sompliance with license agreements. This program is a product of Foundation Ware and must be distinguished from other products with similar names. William Hugh Murray, Fellow, Information System Security, Ernst & Whinney 2000 National City Center Cleveland, Ohio 44114 21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840 ========================================================================= Date: Mon, 20 Jun 88 23:42:03 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Loren K Keim -- Lehigh University I was just reading the reaview of "VAccine" by FoundationWare. I had the opportunity (with Chris Bracy and Joe Sieczkowski) to go out to San Francisco recently (I'm an East Coatster myself), and test out Vaccine for FoundationWare. To tell the truth, its a very good package for businesses and government, but I wouldn't recommend it for the average programmer. Several other companies have released anti-viral programs based on the Vaccine Shell, and I remain against the idea. The probelem with a shell is that you must OKAY software before you run it. That means if you are writing a program, you must take a bunch more keystrokes to okay it each time you run it. With Vaccine, that often takes some doing. I can't compalain abou tit though. It does stop any virus I've run accross yet. And it is probably good for places that do no programming. Unfortuanatley (please excuse my typing, I am on a dumb terminal with no backspace or delete!) I remain unimpressed with most anti-viral packages. I haven't found one that I truely like. FoundationWare's owner challedned Chris, Joe and I to try to break their program, and we were able to come up with a few designs to do it in just under 10 minutes. Average viruses woul,dn't come up with what we doid however. Of all the shell programs, Vaccine is one of the best, but again, I would not use one. You cannot program. Your compute becomes an isolated machine. ( Loren Keim ========================================================================= Date: Mon, 20 Jun 88 23:12:13 PST Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Tim Streater (415) 926-2743" Subject: Going to Jail and not even getting $200 I have worked with the Xerox compiler that gave the cute $200 message. It was when I worked at CERN, on a Cii 10070 (a French identical copy of a Sigma 7). However I am not aware that it stopped compiling after generating the message. Near as I could tell it just issued a warning and carried on. Mind you, I didn't make a habit of using JAIL as a variable in a GOTO statement, just did it once or twice for fun. So I could easily not have noticed that behaviour. Tim Streater / SLAC-SCS Networking Development. ========================================================================= Date: Tue, 21 Jun 88 08:06:35 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List Comments: In-Reply-To: 15 Jun 88 11:57:09 EDT From Jefferson Ogata From: Otto Stolz +49 7531 88 2645 Subject: VM/SP Release 5 doesn't RECEIVE hidden files; Hello, this is good news, and not an unconfirmed rumour. On thursday, I had started writing my note in order to tell you that VM/SP Release 5 contained an antidote to the possible poisining uncovered by Jefferson Ogata's contribution. As I could neither find it in SC24- 5290-0 "Release 5 Guide", nor in SC24-5330-0 "Using Release 5 Enhance- ments", I thought I was wrong, and announced this NETSERV stuff, instead. Now, I looked it up in SC19-6209-4 "CMS Command Reference, Release 5", and -- heureka! -- there it sits and waits for you! I cannot under- stand why they didn't mention it in the other two books (one of them is nearly two inches thick!). Perhaps, they were ashamed admitting impli- citly that they had to remove a serious flaw in their design :-) The RECEIVE and READCARD commands have been enhanced with a new triple of options: FULLPROMPT, MINPROMPT, and NOPROMPT. With RECEIVE, the default is MINPROMPT, and with READCARD (seldom used), it is NOPROMPT -- that's the risky one :-( The explanation for MINPROMPT says: > Minprompt > specifies that a prompt is issued when the name of the first (or > only) file differs from the name of the spool file; the prompt for > the first file is suppressed when it has the same name as the spool > file. A prompt is always issued for the second an subsequent files. Further explanations show that RECEIVE will prompt you for hidden files from partioned data sets in DISK DUMP and NETDATA format, whilst it will read in continuously punched spool files into a single (and harmless) disk file with all those :READ statements embedded. READCARD will accept punched spool files and create multiple disk files from them, evaluating the :RDR statements. In any case, no file will creep onto your disk unnoticed, if you use the MINPROMPT or FULLPROMPT option: instead, you'll be notified and prompted for approval of every file. There remains one dark spot. A usage note for the RECEIVE command says: > The MVS with TSO Extension Program Product ... can send, as a unique > case of multiple files in one transmission, one note and a data file > together. The note will be the first file in the transmission and the > data file will be second. RECEIVE will add the note to the appropriate > notebook, receive the data file, and give informative messages for each > action. This is the only form of multiple NETDATA files supported by > the RECEIVE command. This paragraph has come unaltered from the Release 4 manual. As the last sentence clearly contradicts the new sections on MINPROMPT, I still hope that it is an oversight by the authors, and RECEIVE will not only "give an informative message" for the second file but rather ask the user for approval. We plan to introduce Release 5, tomorrow. And I'd gladly appreciate a MVS/TSO volunteer to sending me a duplicate file as outlined in the quotation above. I hope, it is specific enough to be followed by a MVS/TSO user. I'll shortly report to the list the results of this test, and possibly other experiences with Release 5. Best regards Otto Stolz ========================================================================= Date: Tue, 21 Jun 88 13:49:30 mdt Reply-To: Virus Discussion List Sender: Virus Discussion List Comments: Warning -- original Sender: tag was From: Bill Kinnersley Subject: Re: Historical Comments The "GO TO JAIL" code lives on today, in Honeywell's CP6. The Fortran 77 compiler Version D00 still produces this warning message. Of course this is not a virus. Pretty soon we'll be calling everything that doesn't work right a virus. "Sorry, Prof. My program's not working yet. It must have a virus." X-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-X Another file downloaded from: The NIRVANAnet(tm) Seven & the Temple of the Screaming Electron Taipan Enigma 510/935-5845 Burn This Flag Zardoz 408/363-9766 realitycheck Poindexter Fortran 510/527-1662 Lies Unlimited Mick Freen 801/278-2699 The New Dork Sublime Biffnix 415/864-DORK The Shrine Rif Raf 206/794-6674 Planet Mirth Simon Jester 510/786-6560 "Raw Data for Raw Nerves" X-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-X