Return-Path: XPUM04@prime-a.central-services.umist.ac.uk Received: from G.SEI.CMU.EDU by ubu.cert.sei.cmu.edu (5.61/2.3) id AA26019; Tue, 12 Jun 90 07:25:14 -0400 Received: from SEI.CMU.EDU by g.sei.cmu.edu (5.61/2.5) id AA13189; Tue, 12 Jun 90 07:25:11 -0400 Received: from nsfnet-relay.ac.uk by sei.cmu.edu (5.61/2.3) id AA04527; Tue, 12 Jun 90 07:24:59 -0400 Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK via Janet with NIFTP id aa10911; 12 Jun 90 11:40 BST From: Anthony Appleyard To: KRVW <@NSFnet-Relay.AC.UK:KRVW@sei.cmu.edu> Date: Tue, 12 Jun 90 11:08:44 BST Message-Id: <$TGVTCZHTCBVX at UMPA> Subject: Virus-L vol 0 issue #0816 Virus-L Digest Tue, 16 Aug 88, Volume 0 : Issue #0816 Today's Topics Re: VM Mainframe Problems Re: VM Mainframe Problems REXX Re: VM Mainframe Infiltration Re: VM Mainframe Infiltration Virus Talks Virus-L Topics Re: Virus-L Topics Re: VM mainframe viruses ** no subject, date = Tue, 16 Aug 88 15:18:00 EDT Virus-L Topics RE: re:Trapping Disk calls Protecting Command.com Definitions Re: command.com ------------------------------ Date: Tue, 16 Aug 88 09:27:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: WHMurray@DOCKMASTER.ARPA Subject: Re: VM Mainframe Problems In-Reply-To: Message of 14 Aug 88 15:01 EDT from "Loren K Keim -- Lehigh University" >I think you missed the point. You are under the assumption >that someone has to execute a bacterium for it to propogate. One of the problems that a designer of a virus must solve is how to get his program executed. One of the easiest solutions to this problem is to get the the victim to invoke it. There are a number of ways to do that. One of them is to simply invite him to do so. Another is to give the program an attractive name. This is called "bait." A second problem is to get the copy propagated to a new execution environment. This is trivial in VM since, by default, all virtual machines are connected in a virtual network. Note that if I can dupe "A" into executing the virus, and if that causes a copy of the virus to be sent to "B," the virus will appear to "B" to have originated with "A." If, as is likely, "B" knows and trusts "A," then that trust will be conferred on the virus. This makes it easier to dupe "B" into executing it. The defenses suggested by Hank are useful. However, in order to be completely effective, they must be observed by most of the users within the community. The virus only has to dupe some of the users in order to prosper; it need not dupe all. Note that the virus usually appears to have come from a known and trusted source. Fred Cohen has demonstrated that in a population of hundreds of users, the virus can propagate to every user within a matter of hours. Incidentally, you should read his papers. It would save a lot of needless speculation about things that he has already demonstrated. 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: Tue, 16 Aug 88 10:02:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: WHMurray@DOCKMASTER.ARPA Subject: Re: VM Mainframe Problems In-Reply-To: Message of 14 Aug 88 15:01 EDT from "Loren K Keim -- Lehigh University" One other point that should be made in the context of network viruses, is that the perpetrator can potentially benefit himself. Viruses in the PC world are merely destructive. They can be employed in the furtherance of vengeance, but they are less useful in satisfying greed. Not so in the network; in addition to replicating itself, the virus can send information back to its originator. (Of course this requires that it contain information about its origins; this increases risk for its perpetrator.) 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: Tue, 16 Aug 88 09:54:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: WHMurray@DOCKMASTER.ARPA Subject: REXX Those of you who are on BITNET probably use REXX even if you are not aware of it. Some of the rest of you may not know what it is. REXX is a command language and interpreter. It is sufficiently rich that almost any thing can be written in it. Its power is extended by its ability to invoke and use commands, other REXX procedures, pipes, filters, programmable editors and formatters, and even other application programs. REXX language interpreters exist for CMS, TSO, and PC DOS . IBM has committed to produce such interpreters for most of their operating systems. Thus, we have the potential for a virus with a wide range of potential targets. In this context, it should be noted that REXX scripts are interpreted rather than executed. However, it can invoke things which are executed. It can, for example, invoke "copy." It can name parts of itself, and thus address them. If it knows its own name, a condition easily met, then it can address itself. On the other hand, if it does not know its own name, a condition equally easily met, then it will have difficulty addressing itself. It should also be noted that, since much of the power comes from the ability to employ things in its environment, it is not totally environment independent. Since commands and naming conventions vary from environment to environment, it is difficult to write a REXX script that will run across environments. Nonetheless, the power of REXX greatly reduces the work factor that a virus designer confronts. (I once wrote a very powerful Trojan Horse that required only two lines of REXX. I wrote it in one half hour even though it was the first REXX procedure that I had ever written. All the knowledge and information that I needed was available on line in the form of HELP and models.) 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: Tue, 16 Aug 88 09:11:54 CST Reply-To: Virus Discussion List Sender: Virus Discussion List From: Claudia Lynch Subject: Re: VM Mainframe Infiltration In-Reply-To: Message of Sun, 14 Aug 88 14:51:21 EDT from What is the name of the program on VM to answer mail? We might be interested in it here at the University of North Texas. Claudia Lynch -------------------- Date: Tue, 16 Aug 88 10:45:02 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: Re: VM Mainframe Infiltration In-Reply-To: Message of Tue, 16 Aug 88 09:11:54 CST from >What is the name of the program on VM to answer mail? We might >be interested in it here at the University of North Texas. >Claudia Lynch I use MAIL and MAILBOOK, but that really isn't in the context of this discussion group. Ken P.S. Anybody responding to this, please do so directly to the sender, not to this list. Thank you. Kenneth R. van Wyk Today - 19th anniversary of Woodstock. User Services Senior Consultant There's supposed to be a million and Lehigh University Computing Center a half people here by tonight! Internet: The New York State Throughway is BITNET: closed man! - Arlo Guthrie -------------------- Date: Tue, 16 Aug 88 11:07:31 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "David A. Bader" Subject: Virus Talks Loren Keim states: > We have discussed (dare I say it?) very little >on this list. The basic purpose of the conference is for >people to get together and discuss viruses among themselves, >show each other what they've come up with in terms of >viral protection and what problems they've had. These sorts >of conferences are generally very successful in that they >produce some very useful ideas. >David, we have touched very little on Worm Process propogation, >or limited functionality (Fred Cohen's idea), limited transitivity >(which has been around for a while), bottom-up system usage, >and various theories of security or anti-viral protection. >We have simply discussed CRC systems, DER encryption schemes, >and various viruses. I believe a conference can produce a lot >more than short letters back and forth. Loren, Then why don't we discuss these topics on the list, instead of re-hashing all these "trivial" problems. Why do some people need to travel hundreds of miles to discuss the problems that this list can solve? David Bader DAB3@LEHIGH -------------------- Date: Tue, 16 Aug 88 11:19:24 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Loren K Keim -- Lehigh University Subject: Virus-L Topics If anyone really wants to hear about limited transitivity theory, I will put some up, but the problem is that this list (correct me if I'm wrong Ken) is for discussion, not for me to lecture to people or anyone else to. Generally, if you want to learn about various subjects, get articles on them, there are many published. Problems sometimes result from the fact that their are some people on this list (William Murray, Joseph Beckman and others) who truely do know something about viruses and security problems, and there are others who really don't. I think its often hard to discuss things. One of the things I like the most about having a virus conference is that we will be given the chance to exchange ideas and if anyone wants to learn something, its much easier to discuss ideas and theories isn person rather than over a list. If anyone feels that I am totally incorrect in that feeling, feel free to tell me. Loren -------------------- Date: Tue, 16 Aug 88 11:29:21 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Ken van Wyk Subject: Re: Virus-L Topics In-Reply-To: Your message of Tue, 16 Aug 88 11:19:24 EDT > If anyone really wants to hear about limited transitivity > theory, I will put some up, but the problem is that this > list (correct me if I'm wrong Ken) is for discussion, not > for me to lecture to people or anyone else to. There's nothing wrong with presenting an overview of such topics, and of course, subsequently leaving them open for other discussions. Also, it's quite acceptable to give an overview and refer the readers to specific books/articles, etc. > Generally, > if you want to learn about various subjects, get articles > on them, there are many published. I agree; I think that everyone who is truly interested in the subject should at least read Dr. Cohen's dissertation. Ken Kenneth R. van Wyk Today - 19th anniversary of Woodstock. User Services Senior Consultant There's supposed to be a million and Lehigh University Computing Center a half people here by tonight! Internet: The New York State Throughway is BITNET: closed man! - Arlo Guthrie -------------------- Date: Tue, 16 Aug 88 10:39:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: WHMurray@DOCKMASTER.ARPA Subject: Re: VM mainframe viruses In-Reply-To: Message of 14 Aug 88 04:42 EDT from "Hank Nussbacher" >I think you should be more selective about your use of the word >mainframe. Each operating system has its own "way" of working and >one method of introducing a virus into a "mainframe" environment - >will not be successful in another opertaing system. The issues here are generality and transitivity. Systems in which a user can both write and execute an arbitrary program, are more vulneralble than those in which the user is limited to the use of programs of managements choice. (Almost all readers of this forum will recognize the former; they may not recognize the latter, but this class includes application machines, servers, ATMs and arcade games.) Transitivity can be defined as the potential for data to become procedure (or, if you like, program.) One man's data is another man's program. However, almost all systems today support the ability to interpret command language scripts (e.g., CMS EXECs, TSO CLists, Unix shell files, PC DOS batch files, etc.) Thus, we go back to generality, i.e., is the capability made available. In the current issue of "Computers and Security," Fred Cohen argues that, in the face of viruses, we must be prepared to restrict sharing, transitivity and generality. I concur. 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: Tue, 16 Aug 88 15:18:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Tomcats on Deck I recently signed onto this list and have been perusing some of the archived files only to discover that little of it deals with mainframes. Although I find much of the material interesting, it's not very helpful to me in pursuing my current project: detecting viruses that might be coming into our VAX/VMS system over BITNET. If anyone has any ideas on how I might better secure our facility here. - ------------------------------------------------------------------------------ Don Sottile Hofstra University Technical Services Hempstead, NY, USA aka - ------------------------------------------------------------------------------ -------------------- Date: Tue, 16 Aug 88 16:09:17 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "David M. Chess" Subject: Virus-L Topics Surely one of the nicest things about a list like this is precisely that there *are* both knowledgeable people and not-yet-knowledgeable people, and the former can give information and advice to the latter? If you know things about (for instance) the limiting of transitivity that you think many of the rest of us don't know, you shouldn't hesitate to tell us. Doesn't need to be a lecture, of course. Could just be "Here's a two-paragraph summary, a practical example, and an article to read for more detail". I think that'd benefit many/all of us... DC -------------------- Date: Tue, 16 Aug 88 18:04:25 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Art Larky " Subject: RE: re:Trapping Disk calls I stand corrected on Autoexec - Command.com does get executed first; however, see my next memo on protecting command.com. > Can you not adjust your CONFIG.SYS to hide almost anything within r RAM? >your ram? >Stevo Well, yes. You can install drivers via config.sys. Usually they are RAM drives, etc. They can be anything if you want to take advantage of thee fact that they get called during the initialization process. I don't see have much expectation of a virus being able to modify config.sys and give you a plague-ridden ake fake driver, but its possible. I would expect to notice such a radicalical thing myself. Art Larky - CSEE - Lehigh -------------------- Date: Tue, 16 Aug 88 21:20:31 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Art Larky " Subject: Protecting Command.com Here are some suggestions for protecting yourself from a command.com virus: Floppy disk based systems: (1) Make a copy of your original system disk and put a write protect tab on it. Boot from that disk only and don't have a system on any other disk that you use in your system. (Make several copies of this disk, of course.) Hard disk systems: These are more vulnerable because you have to have command.com le available on the disk and the disk cannot be write protected because its the one you are using actively, so: (1) Rename command.com to some other name which is meaningful only to you. Don't tell anyone else what that name is. (Keep the .com extension.) (2) Modify IO.SYS (or IBMIO.SYS) by replacing the string COMMAND.COM with the new name which you have chosen. Use a seven character name because I'm not sure what would happen if you tried to shorten the length of the string. (3) Add to CONFIG.SYS the line shell=d:\command.com (4) Add to CONFIG.SYS the 'device=' line to create a ram disk large enough to hold command.com. (3) above assumes that that will ome become drive D. (5) Add to your autoexec.bat the line copy ugh.com d:%command.com (replace ugh.com by the name you have chosen for your secret copy of command.com.) Now, if someone infects command.com, it will be the copy in ram disk nd and not your permanent copy and the infected copy will go away when you oot re-boot the system, even if you just do a warm boot. Of course, a clever virus could read your config.sys and your autoexec.bat and . . . . . ; BUT, you have the upper hand (I hope) because you have been able to boot with a clean copy of command.com and a clean (I hope) copy of autoexec. Your autoexec can do CRC's and such to protect itself and your your hidden copy of command.com. For those who doubt that this will work: I have tried it and, if YS the file name in IO.SYS is changed (with Norton Utilities or Debug), it will use the re-named copy of command.com with no complaints. ts. I would welcome any comments about hidden pitfalls in this approach. By the way, one benefit is that, with command.com in ram, you will oke invoke it faster at job end and when your program does a push to DOS. Art Larky, CSEE Dept, Lehigh University -------------------- Date: Tue, 16 Aug 88 21:14:07 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Robert Newberry Subject: Definitions Hello all I was wondering if someone could send me a list of all the known computer diseases and define some of the terminology used when describing the diseases. I am writing a paper on computer viruses and I would like to include a definitions section. Due to the fact I am Kind of a beginner at using computers, I don't know some of the terms used. Thanks in advance. Robert Newberry University of Akron Akron, Ohio 44304 USA P.S. Thanks for the information on computer virus legislation! :-) -------------------- Date: Tue, 16 Aug 88 21:57:00 EST Reply-To: Virus Discussion List Sender: Virus Discussion List From: ZDABADE@VAX1.CC.LEHIGH.EDU Subject: Re: command.com After reading Art Larky's message on command.com, I felt that I must also share how I have been protecting my computer against the dreaded Command.com strain of viruses. Like A.L.'s protection scheme, my method does almost the same effect by renaming and copying files. Here is what happens each time my computer boots: (the autoexec dealing with virus protection ) 1) Config.sys creates a 384K Ram disk 2) CHECKUP 1.4 is used to monitor the fingerprint of Command.com by copying its image from a subdirectory into the root and comparing Command.com with the image. 3) Copy Command.com to the RAM disk and set it write protected on both the Hard drive and the ram disk 4) Set COMSPEC = E:(ramdisk)\COMMAND.COM 5) And finally, I have Flushot plus 1.4 (kind of) working to consistently check my CRCs of important files (Command.com, io.sys, msdos.sys,etc.) I figure that if I am infected by a virus, my hard disk's Command.com will be infected, and on my next bootup, I will know about it and automatically replace the corrupted file. Since my COMSPEC is pointing to my RAM disk's Command.com, I will have no problems in that "infection" session of spreading the virus. If my Command.com that is on my RAM disk is infected, SO WHAT??? It will be replaced on my next bootup and won't be able to spread. I guess anyone writing a virus has it one step easier now knowing various user's configurations and trying to find the holes in our thinking. But I feel that the more protection schemes used and spread across the world- wide computing systems, the less the chance of any virus propagating. David /-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-\ | From: David A. Bader, Studentis Maximus | | | | DAB3@LEHIGH SloNet: 1402 Lorain Avenue | | ZDABADE@VAX1.CC.LEHIGH.EDU Bethlehem, Pa. 18018 | | | | SchoolNet: Box 914, -On a mostly harmless | | Lehigh University, blue green planet... | | Bethlehem, Pa. 18015 -And loving it! | \________________________________________________________________________/ -------------------- *** end of Virus-L issue ***