========================================================================= Date: Mon, 15 Aug 88 11:07:32 SST Reply-To: Virus Discussion List Sender: Virus Discussion List Comments: Date: 8-15-88 11:06am Comments: From: anyone:Staff:ISS Comments: To: {virus-l@lehiibm1}:bitnet, Comments: {LKK0@lehigh}:bitnet Comments: cc: Jim Comments: Subj: re: MAINFRAME WOE'S CONTINUES From: Jim Crooks Subject: re: MAINFRAME WOE'S CONTINUES >It may be true that it is harder to write a mainframe anti >viral package than a micro av package, BUT its also generally >harder to write a virus for that system. don't agree see comments below >Our job isn't to create a virus-proof system, I don't believe >one exists... but what we can do is make the environment >harder and harder to attack, make the virus writer really >work to write a good virus, and make the number of people >who can write a virus to go oaround our systems so small >that no one does it. agree >Loren I think that one has to keep in mind the *KEY* difference between a micro environment (DOS, OS/2, etc.) and a mainframe (MVS, CMS, VMS, UNIX, etc.) is that the mainframe OS is immune to direct attack (OS kernel is protected, OS files are protected, user files are not). Viral attack requires modification of executables (per the definition of a virus). If *ONLY* authorized programs (linkers) running from protected (read-only) filespace can write or modify an executable, then the low-grade user vector for the virus is stopped cold. The only path to infection is a super-user running an infected program; an authorized virus can nullify protection of executable files... A much smaller and harder window for a virus to get through. The only other loop-holes to plug would be file rename (to executable name), file copy/restore - the same protection criteria could be applied to file system utilities as you require of Linkers (authorized, protected filespace). It would only take small mods to existing mainframe security systems implement the above protection systems. The same hooks and exits used by the security systems can be used by a anti- virus developer to protect just executables if a site doesn't want to pay for a complete security system (cost in $$$ and overheads). Since the mainframe OS is better protected, other loop-holes are harder to find for the virus-writer. And once protected, the mainframe will tend to stay safe. I *REALLY* think that mainframe protection development is trivial compared to trying to protect a micro; when you stopper up the many guage 0 holes, there are thousands of size 00, millions of 000... For the PC just a couple of non-trivial changes could make the environment much easier to protect: - external switch to protect boot partition on HD (IBM, clone-makers, disk sub-system people are you listening?) - all executable files encrypted on disk (with DES or even a simpler algorithm), file decrypted by loader, key specified by user at boot through keyboard or ???. Encrypt by linker or conversion utility (after power off restart!) James W. Crooks Member, Advanced Technology Application Staff Telephone: (65) 772-2009 FAX: (65) 778-2571 BITNET: JIM@ISS.NUS.AC.SG BIX: jw.crooks Envoy(Telemail): jw.crooks Institute of Systems Science, National University of Singapore Heng Mui Keng Terrace, Kent Ridge, Singapore 0511 ========================================================================= Date: Mon, 15 Aug 88 03:22:01 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Amanda B Rosen Subject: Hiding large camouflaged viruses ========================================================================= Date: Mon, 15 Aug 88 08:03:33 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 Sun, 14 Aug 88 14:51:21 EDT from >It depends on the program. Clarkson University makes a program >which I'm using right now on a VM system to answer your >mail. It allows easy access to VM systems from microcomputer >networks. It redefines all sorts of key configurations and >allows some interaction with VM files and programs. Excuse me Loren, but you're on a MUSIC/SP system, not a VM system. MUSIC/SP runs as a disconnected virtual machine under VM/CMS, and its disk structure bears very little resemblence (sp?) to VM/CMS. Also, the terminal program, PCWS, was written by McGill University, not Clarkson. Ken Kenneth R. van Wyk User Services Senior Consultant Hobbes: What fun is being "cool" Lehigh University Computing Center if you can't wear a Internet: sombrero?! BITNET: ========================================================================= Date: Mon, 15 Aug 88 10:09:05 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Loren K Keim -- Lehigh University Subject: VM Modem Protocal Ken, I really wish you wouldn't make statements like "You are not using this or that program" unless you really know what I'm using. I am not discussing PCWS from McGill. I was playing with another program to emulate 3270's terminals on another machine. Actually though, I do want to correct one thing. I don't believe the program I'm using is sanctioned by Clarkson, looking at it, it may just be written by someone there. Loren ========================================================================= Date: Mon, 15 Aug 88 12:11:37 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Loren K Keim -- Lehigh University Subject: The Conference... Okay, We're ready to tell you about the computer virus conference coming up! THE COMPUTER VIRUS AND SYSTEM SECURITY CONFERENCE We will be holding the first Computer Virus and System Security Conference at Lehigh University in the Lehigh Valley, Pa. (Bethlehem, Allentown area) on October 21, 22 and 23 (a Friday, Saturday, and Sunday). Because specific rooms are still under discussion, we cannot give you a precise schedule of events. The cost will be $50.00. This includes entrance to the conference and all discussions. Preliminary Schedule: -------------------- The following is a VERY tentative schedule. It will be altered as we get nearer to the conference date. We are juggling large rooms, including a very large hall for round table discussions and several large auditoriums. We'll have a better idea of exactly how the conference will be set up within two weeks. We'll need more information on exactly how many people will be attending the conferences and an exact list of speakers. We have several people who have tentatively said yes to speaking at the conference and we'll be contacting others over the next week. We expect additions to this schedule, and will post them as we get them. We already have a good group of people working on the conference, so it should go over quite well. I'd also like to thank Craig Pepmiller for his suggestions. Fri, Oct. 21: 1:00 PM - 2:30 PM What is a Virus? A seminar, including demos of several viruses on various systems. These will be WELL contained. 2:45 PM - 3:15 PM Introductions (Guests can introduce themselves to each other in a lounge area). Coffee, Donuts and Coke will be served. 3:30 PM - 4:45 PM Viral Detection Methods (Seminar) 5:30 PM - 6:30 PM Dinner (Restraunt locations will be provided and groups can break up to discuss topics). Sat, Oct. 22: 10:00 AM - 11:00 AM Computer Security Concerns I (We will go over protection schemes for schools and businesses and review simple, inexpensive ways of keeping your LAN's clean.) 11:00 AM - 12:00 PM Computer Security Concerns II System Integrity, Limited Transitivity will be main emphasis at this time. (Government security systems, banking systems, and early and future forms of virus stopping designs). 12:00 PM - 1:00 PM Lunch 1:15 PM - 1:45 PM Worm Demonstration 2:00 PM - 4:30 PM Discussions. We will hopefully be set up in a large area. We will have electricity to do demonstrations and people can show each other virus and anti- virus programs. Hands-On. 2:00 PM - 4:30 PM While the discussions are going on and people are trading software, we will have speakers discussing their own experiences with viruses. One seminar will teach the game, Corewars on the MacIntosh. 5:30 PM - 6:30 PM Dinner break 7:00 PM - 9:00 PM Another Seminar, we haven't decided on the topic. Sun, Oct. 23: 10:00 AM - 2:00 PM Round table discussions in a large hall. People can come and go as they like. Coffee, Cookies and Coke will be served. At several conferences and at the round table discussions, we will make various articles on viruses and security concerns available. We are expecting to add seminars. If you have any suggestions on exactly what you'd like to hear about, please let me know by writing to LKK0 at LEHIGH.Bitnet. Price Tag: --------- This is a non-profit conference. The $50.00 will be used to rent conference rooms, to print a magazine for the conference, for coffee, donuts and snacks at the conference, and to pay for speakers to fly in. I still feel we may come up short, so we are allowing on Saturday, vendors to set up their equipment or anti-viral packages. This is not a show to sell products, but vendors may demonstrate their products. For a table at the show, we are asking for $400.00 from each vendor. For a full page ad in the magazine we will be printing, we will be asking for $400.00. For a half page ad, $250.00, and for a quarter page ad, $145.00. Color ads will cost more, please call me at (215) 865-4253 for color ads. Please send a check for the conference to: Computer Virus Conference c/o Loren K Keim P.O. Box 2423 Lehigh Valley, Pa. 18001 I will send back to you brochures on some local hotels, including The Allentown Hilton, Hotel Bethlehem, the Sheridan Jetport, the Econo Lodge, the Holiday Inn's and the Red Roof Inn. We will also be sending more specific information about the conference and where rooms are closer to the conference date. How Do I Get There? ------------------ The Lehigh Valley (Allentown) is an hour from Philadelphia. We will be sending maps of the Lehigh Valley and of Pennsylvania to those who ask. From Philadelphia: The Pennsylvania Turnpike, Route 9 passes through West Allentown, take the 22/78 exit East to Bethlehem, Rt 378 South to South Bethlehem. Lehigh University owns the mountain. OR take Rt 309 North to Rt 378 North to Lehigh. From New York: Take I78 West to 22 West to Bethlehem. 378 South to Lehigh. Others traveling by plane: the ABE international airport (the largest of our airports) is serviced by several major airlines including United, Eastern, Continental, among others. Connections to ABE are made out of Chicago, Atlanta, and many others. WARNING: ------- IF WE FIND ANYONE WHO HAS PURPOSELY OR ACCIDENTLY RELEASED A VIRUS ON ANY OF OUR SYSTEMS, ACTION WILL BE TAKEN AGAINST THAT GROUP OR INDIVIDUAL. Any questions, please send them to LKK0@LEHIGH. ========================================================================= Date: Mon, 15 Aug 88 14:43:03 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "David A. Bader" Subject: conference One question, Loren, about the conference: Is the $50 going to be worth the price for the people who get the Virus List (and don't want to hear a re-hash of everything said here a thousand times over) or is it going to have fresh, new input and ideas? Also, Who are the speakers going to be??? It seems that reading through old virus lists might contain more information than having ANYONE talk about the subjects... Here's an idea: Have bound copies of the old virus list logs available (to buy?!?) so that people can gain some more knowledge through them.. Once again, these are my ideas and are not usually accepted by others.. If you wish to complain, fine; everyone else does. -David DAB3@LEHIGH ========================================================================= Date: Mon, 15 Aug 88 14:49:45 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Steve Subject: Encryption I think J. W. Crooks idea of executable file encryption is a nice idea if the encryption/de-encryption process could be protected. I was thinking along the same lines myself but I didn't bring it up (and I may be wrong!) because I didn't think it was a practical or defensible scheme. If you use the same encryption algorithm with a built-in key for every encryption/de-encryption, then a virus has only to locate that segment of the program which does that and use it. If you use the same algorithm everytime, but always query the user for the key, then even if the virus knows the algorithm, it can't make use of it because it lacks the key. However, just because you don't store the key on disk somewhere doesn't make it safe, even if the algorithm is a good one. The de-encryption program file must be vulnerable because it must be available at startup (or you can't run any programs at all!) and therefore must be sitting there unencrypted on your disk. A virus could infect the de-encryption program (e.g. the loader program) (say when you run some trojan horse program) and then just wait until you run your next program which will require the loader to query for the key (unless the loader only queries for the key once (at boot), and then the key is just sitting there in memory, waiting to be snatched). Whatever the senario, whether the virus steals the key from the deencryption program as it runs or directly from the user or from memory or whatever, the key clearly has to be around to be stolen whenever you run a program. With the key in its possession, the virus knows how to read any of your other programs, including the encryption program (if it isn't already sitting there unencrypted on your disk). Now all it has to do to infect your programs is to de-encrypt them, alter their code and then re-encrypt. It certainly makes life harder for the virus, but I'm not sure if it offers a significantly increased level of security compared to the price you have to pay (the complication of encryption, and then there's the added hazard of what to do if you forget the key...), unless you can make it harder for the virus to get at the encryption/de-encryption process. On the other hand, just because a scheme can be foiled doesn't mean that it is of no value. I think an invincible protection scheme will never exist, but we may find a scheme which will never let any viruses through. Steven C. Woronick ========================================================================= Date: Mon, 15 Aug 88 15:24:34 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: Re: Encryption In-Reply-To: Message of Mon, 15 Aug 88 14:49:45 EDT from > I think J. W. Crooks idea of executable file encryption is a nice >idea if the encryption/de-encryption process could be protected. >Steven C. Woronick In Fred Cohen's dissertation, he talks about using RSA public key encryption combined with checksum (or CRC) signatures to protect files from alteration. Specifically, use the RSA encryption to encrypt a file, then discard the private key thereby making the encryption process one way, perform a checksum of the resulting encrypted file, and store that checksum on disk. It is then easy to validate the signature, but next to impossible to reverse engineer the checksum, particularly if you use long encryption keys. The problem with this method is that there is relatively considerable overhead involved in the authentication process. If, however, you only perform the authentication process periodically, it could be a viable file protection scheme; at least it should be able to detect unauthorized file modifications with a high degree of certainty. The RSA public key encryption, by the way, uses two encryption keys - one for encryption and one for decryption. Figuring out one from the other would be extremely difficult. Regards, Ken Kenneth R. van Wyk Today - 19th anniversary of Woodstock. User Services Senior Consultant By the time we got to Woodstock, Lehigh University Computing Center We were half a million strong, Internet: And everywhere was a song, BITNET: And a celebration. - Joni M. ========================================================================= Date: Mon, 15 Aug 88 12:42:00 CDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Gerald L. Schmalzried" Subject: Re: VM Mainframe Problems Loren K Keim states: > I think you missed the point. You are under the assumption > that someone has to execute a bacterium for it to propogate. > In VM systems, at least in Rexx programs, a virus can be > hidden. This could be one of your own programs, and I've > written several Rexx programs, with a hidden line somewhere, > or even an appended line that when you run it, it will > propogate. Right. Which means that someone has to execute the bacterium for it to propogate. Even REXX programs don't jump up and start executing all by themselves. PROFILEs (similar to PCs' AUTOEXEC.BATs) could be thought of that way, but those are actually called by someone (CMS or XEDIT) and can be overridden. The CHRISTMA EXEC would never have gotten out of node 1 without someone executing it. Just having it won't spread it. Perhaps you could restate your point in case I missed it... --Gerald ========================================================================= Date: Mon, 15 Aug 88 13:37:42 CDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Len Levine Subject: AT configuration I wonder what would be the effect of telling my AT, through some configuration changes that I have no hard disk. I can run a program that permits me to tell the battery operated RAM package that I have one of 45 or so different hard disks, or by putting a zero in some location tell it that I have no hard disk. Can a virus guess what sort of disk I have? What would happen if the virus guesses wrong? Interested in some feedback here. + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + | Leonard P. Levine e-mail len@evax.milw.wisc.edu | | Professor, Computer Science Office (414) 229-5170 | | University of Wisconsin-Milwaukee Home (414) 962-4719 | | Milwaukee, WI 53201 U. S. A. Modem (414) 962-6228 | + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + ========================================================================= Date: Mon, 15 Aug 88 16:03:06 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: Re: AT configuration In-Reply-To: Message of Mon, 15 Aug 88 13:37:42 CDT from >I can run a program that permits me to tell the battery operated RAM >package that I have one of 45 or so different hard disks, or by >putting a zero in some location tell it that I have no hard disk. Can >a virus guess what sort of disk I have? Certainly within one of 45 or so tries... :-) >What would happen if the >virus guesses wrong? If the virus (or any program) only tries to read the disk while it's set to be the wrong type, no harm should happen (well, the seek motor might not like life too much if you try to go to, for example, cylinder 800 when you only have 619). If the virus writes while set up wrong, it's highly likely that you'd be spending some time in the not too distant future reloading your hard drive. What would be the advantage(s) of doing that, though? To test to see if a program contains a virus before trusting it on your hard drive? Ok, that could be of limited utility. Bear in mind, however, that it would be painless for a virus to (purposely) not do any damage, or even try to propogate, if there is no hard drive present. Also, chances are pretty good that a virus wouldn't try to assume that you have a hard disk if DOS says that there is none present - it would be shooting into the dark so to speak. Ken Kenneth R. van Wyk Today - 19th anniversary of Woodstock. User Services Senior Consultant By the time we got to Woodstock, Lehigh University Computing Center We were half a million strong, Internet: And everywhere was a song, BITNET: And a celebration. - Joni M. ========================================================================= Date: Mon, 15 Aug 88 18:45:00 EST Reply-To: Virus Discussion List Sender: Virus Discussion List From: ZDABADE@VAX1.CC.LEHIGH.EDU Subject: RE: AT CONFIGURATION Try running FluShot+ 1.2 on your AT computer and then you will know what it is like to have your CMOS setup corrupted so that DOS (or a virus) can't find any fixed drive! I think it would be difficult for a virus writer to experiment setting different fixed drive types in your CMOS hoping to get some fixed drive available. Would the virus writer not be safer by checking for the fixed drive first? (on an AT: in the CMOS); then if one exists, attack it. Otherwise, his/her virus might end of with "drive not found" type errors. /-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-\ | 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! | \________________________________________________________________________/ ========================================================================= Date: Mon, 15 Aug 88 22:04:07 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Loren K Keim -- Lehigh University Subject: Conference Amanda, the letter you sent to Virus-L did not get to me, I just got the header. If it was important, could you resend it? David Bader: 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. I got quite a few replies to my VM system comments. Again, I am sorry, but I am not quite used to VM yet and am not that good with it. I also do not have a system account and have very limited access, so its hard for me to proceed, unlike other machines I've worked on. Over the next few weeks, hopefully, I will have something more substantial worked out and will describe possible infiltration methods. One of the comments I received was something like: "If you have to execute the Rexx program to propogate the virus, it is a bacterium." No, I was not talking about a program which is a virus, I am talking about inserting a few lines of viral code into someone else's Rexx program. Sure ALL viruses have to be run to propogate, the difference between a bacterium and a virus (as it was explained to me recently) is that a bacterium IS a program and a virus places itself into a REAL program of the users. Thank you for all your VM suggestions by the way, and incidently, if, for some reason, I sounded like I disliked DER encryption, that is certainly not true, it is very good. I also am a big fan of forcing the user to put in a key. Loren Keim ========================================================================= Date: Mon, 15 Aug 88 22:08:39 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Loren K Keim -- Lehigh University Subject: Conference AGAIN Alright David, Since you have asked, I may as well reply here. He wanted to know what the 50 bucks was for. Because we will (as it looks now) have a large group of experts and amateurs showing up, we will need to rent room space. This costs money. Several people have also suggested coffee and donuts or cookies at the conference and its a good idea. About half the people who wrote in wanted some sort of magazine/book written for the occation to include some speaches and some papers. We'd also like to make certain papers available to the people. One of the bigger expenses is flying in good speakers, people who have dealt with viruses and security problems for some time. Rather than have just anyone talk about subjects (which I'm sure everyone can read books and tell us what they read), we'd really like to have the people who've worked on viruses and propogation theories. However, I am still in the process of trying to contact people from "Computers and Security" magazine and others. I hope people are interested in this conference, we've gotten a ton of mail on it. I believe it will be fun, educational, and hopefully will bring something out of it. Thank you, Loren Keim ========================================================================= Date: Mon, 15 Aug 88 21:52:00 EST Reply-To: Virus Discussion List Sender: Virus Discussion List From: KAPLANB@IUBACS Subject: virus conference - air Conference Attendees - I've gotten airline fares for major cities to Allentown, PA. Cities: Chicago (O'Hare), San Francisco, Los Angles (LAX), New York City (JFK), Miami, Minneapolis. Please send me a e-mail note if you would like a copy. I will not put it on the Virus-List - waste of space/time for those who have no intention of going to the conference. I made the departure date Friday, October 21 and return date Sunday, October 23. If you are not on Bitnet - please! make the return address easy for me to answer you back! ========================================================================= Date: Mon, 15 Aug 88 23:38:40 PDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: NEWMAN@CITHEX Subject: RE: Hiding large camouflaged viruses SIGNOFF VIRUS-L ========================================================================= 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! | \________________________________________________________________________/ ========================================================================= Date: Wed, 17 Aug 88 12:19:32 SST Reply-To: Virus Discussion List Sender: Virus Discussion List Comments: Date: 8-17-88 12:16pm Comments: From: anyone:Staff:ISS Comments: To: {virus-l@lehiibm1}:bitnet Comments: cc: Jim Comments: Subj: Dr. Cohen's Dissertation From: Jim Crooks Subject: Dr. Cohen's Dissertation Is Dr. Cohen's Dissertation available anywhere (for $$$)? Anyone know how to go about getting a copy? Thanks, James W. Crooks Member, Advanced Technology Application Staff Telebox(DIALCOM): 12:GVT331 ATTN:((JIM)) BITNET: JIM@ISS.NUS.AC.SG BIX: jw.crooks Institute of Systems Science, National University of Singapore Heng Mui Keng Terrace, Kent Ridge, Singapore 0511 ========================================================================= Date: Wed, 17 Aug 88 12:19:23 SST Reply-To: Virus Discussion List Sender: Virus Discussion List Comments: Date: 8-17-88 12:15pm Comments: From: anyone:Staff:ISS Comments: To: {virus-l@lehiibm1}:bitnet Comments: cc: Jim Comments: Subj: re: VIRUS-L TOPICS From: Jim Crooks Subject: re: VIRUS-L TOPICS In Reply To: Loren K Keim -- Lehigh University Tue 16 Aug 88 > Generally, > if you want to learn about various subjects, get articles > on them, there are many published. Agreed - I think that we could further the aims of this list if there was a compiled bibliography of "Computer Virology". In fact I'd be willing to compile one for submission to Ken van Wyk to be put up as a listserv file, if all you VIRUS-L'ers will send references to me... please to my personal id: jim@iss.nus.ac.sg the id on the envelope is a distribution system| > 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. Discuss already - the novices will just have to read the message logs and literature references to get up to speed. Discuss the *REAL* issues and problems at hand on the list. That is one of the known problems of discussion lists; some noise in the signal. > 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 in person rather than over a list. I agree that face-to-face discussion is "easier" than phone or message, but some of us who won't be able to get to the conference have to make do with what is available. James W. Crooks Member, Advanced Technology Application Staff Telebox(DIALCOM): 12:GVT331 ATTN:((JIM)) BITNET: JIM@ISS.NUS.AC.SG BIX: jw.crooks Institute of Systems Science, National University of Singapore Heng Mui Keng Terrace, Kent Ridge, Singapore 0511 ========================================================================= Date: Tue, 16 Aug 88 23:19:05 PDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: NEWMAN@CITHEX Subject: Signoff SIGNOFF VIRUS-L ========================================================================= Date: Wed, 17 Aug 88 03:29:44 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Amanda B Rosen Subject: COMMAND.COM and viruses Two people have recently mentioned how they protect COMMAND.COM from infection by virus. While their system may (and may not) protect them against today's viruses, they are not a significant barrier to even fairly "stupid" viruses. First of all, running your CLI out of a ramdisk is not going to fool most viruses. Unfortunately, MS-DOS makes it easy for viruses to spot what is most likely to be your real CLI- C:\COMMAND.COM It would probably protect you much more to partition your disk so that you have a 1 MB C: partition and the rest of your disk in D:. Boot up with the COMSPEC set to D:COMMAND.COM. This will give better results. Of course, while experts can get their disk to have any name they like, most users will always be running out of the C: device. Too bad. File systems with named devices would eliminate this problem. (Mac HFS, for example) Secondly, this again brings up the topic of disguised viruses. Someone (Art Lakey?) said that a virus would not be likely to use device drivers as a vector since he would notice the difference. In fact, this is one of the more trivial types of disguise a virus might use- just make sure that any references to the CONFIG.SYS file don't show the line, make sure updates don't clobber the line, and hide the driver in the way discussed in my previous article on camouflaged viruses. Actually, that's not so trivial... but compared to some of the horror-story viruses being discussed recently, it's pretty tame. /a ========================================================================= Date: Wed, 17 Aug 88 11:40:37 IST Reply-To: Virus Discussion List Sender: Virus Discussion List From: Yosi Subject: Re: Virus-L Topics In-Reply-To: Message of Tue, 16 Aug 88 11:29:21 EDT from Hello there, Reading the mail in the list teaches me a lot. I live far away so no chance that I come to the conference. Starting to keep subjects out of range for this list - save them for the conference - will harm these that will not go there. It will be nice to know that subjects raised in the conference - will be summerized here. To the discussion started by Loren K Keim - It is important to read summerized 'lectures' as well as techniques to prevent viruses : mixing theory with practice. Yosi ||||||||||||||||||||| ------------------------------ | YOSI ALMOG PHONE: WORK - 972-(0)4-292173 | USER SERVICES CONSULTANT * TECHNION - ISRAEL INSTITUTE OF TECHNOLOGY * TAUB COMPUTER CENTER * ARPANET : CCAYOSI@TECHNION.BITNET@CUNYVM.CUNY.EDU * DOMAIN : CCAYOSI@TECHNION.TECHNION.AC.IL * BITNET: CCAYOSI@TECHNION ========================================================================= Date: Wed, 17 Aug 88 07:18:36 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List Comments: In-Reply-To: Poster of 16 Aug 88 09:54:00 EDT from WHMurray at DOCKMASTER.ARPA From: Otto Stolz +49 7531 88 2645 Subject: Amendmend from a REXXpert (or a would-rather-be-REXXpert :-) > If it does not know its own name, a condition equally easily met, ... No, because every REXX program knows its own name by means of the PARSE SOURCE statement. Btw, every REXX program knows its own source code by means of the sourceline function, which makes virus-writing easier. > ... it is not totally environment independent. > ... it is difficult to write a REXX script that will run across > environments. Yes, and to the extend that the very statements a bacterium or virus would use to propagate (e.g. COPYFILE) are *not* part of the REXX language (at least not of every implementation) but rather of the environment. Regrettably, this constraint is relaxed by two mechanisms: 1. every REXX program knows the environment it's running in (PARSE SOURCE and PARSE VERSION); 2. REXX can be used to program the XEDIT editor (available on CMS and PC -- I don't know about TSO/E) which constitutes a much more versatile and compatible environment. Best wishes Otto ========================================================================= Date: Wed, 17 Aug 88 07:54:20 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 Wed, 17 Aug 88 12:19:23 SST > Agreed - I think that we could further the aims of this list if > there was a compiled bibliography of "Computer Virology". In fact > I'd be willing to compile one for submission to Ken van Wyk to be > put up as a listserv file, if all you VIRUS-L'ers will send > references to me... please to my personal id: jim@iss.nus.ac.sg > the id on the envelope is a distribution system| Great idea! I've had a number of requests for good references and where to get them. It would be very worthwhile having a bibliography (of sorts) here on the LISTSERV. Jim, send me what you have, and I'll put it up. Thanks! Ken Kenneth R. van Wyk Today - 19th anniversary of Woodstock. User Services Senior Consultant Lehigh University Computing Center You kids are great! Internet: - Max Yasger, the man who owned the BITNET: farm on which Woodstock was held. ========================================================================= Date: Wed, 17 Aug 88 09:25:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: the Preserver Subject: Where in the heck are those Papers? Recently on this list, some people have advocated that in general the members of this list should go out and read some references. Agreed, but where are they? I believe someone came up with the idea of making a VIRUS-L bibliography, an idea I laud, however, I have noticed that certain people even when they do give references (which is almost never) do not give complete or correct references. As to Mr. Cohen's dissertation, I recently called USC and tried to get a copy of it, and I was told that the author had pulled it from circulation, apparently so he could publish a book. I would like to borrow someones copy to read, since I am sure the book will be out RSN. A final request, could someone send me information on how to subscribe to Computers and Security. Thanks Les vishnu@pine.circa.ufl.edu vishnu@ufpine ========================================================================= Date: Wed, 17 Aug 88 09:59:55 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Art Larky " Subject: Cohen thesis This may or not be the case with Fred's thesis, but most universities require that theses be published by having them filed on microfilm by University Microfilms in Ann Arbor, Michegan. Some helpful soul might want to contact them to see if it is available there. Art Larky ========================================================================= Date: Wed, 17 Aug 88 09:03:40 CDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Len Levine Subject: Re: AT configuration In-Reply-To: Message from "Kenneth R. van Wyk" of Aug 15, 88 at 4:03 pm >>I can run a program that permits me to tell the battery operated RAM >>package that I have one of 45 or so different hard disks, or by >>putting a zero in some location tell it that I have no hard disk. Can >>a virus guess what sort of disk I have? [..] > Also, chances are >pretty good that a virus wouldn't try to assume that you have a hard disk >if DOS says that there is none present - it would be shooting into the >dark so to speak. > >Ken > That was just my point. At least for the next little while, we can expect that virus codes will not look for hard disks on systems that show none. + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + | Leonard P. Levine e-mail len@evax.milw.wisc.edu | | Professor, Computer Science Office (414) 229-5170 | | University of Wisconsin-Milwaukee Home (414) 962-4719 | | Milwaukee, WI 53201 U. S. A. Modem (414) 962-6228 | + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + ========================================================================= Date: Wed, 17 Aug 88 10:15:11 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Art Larky " Subject: More on command.com Amanda B Rosen writes: >First of all, running your CLI out of a ramdisk is not going > to fool most >viruses. Unfortunately, MS-DOS makes it easy for viruses to >spot what is >most likely to be your real CLI- C:\COMMAND.COM My suggestion was to get rid of C:\COMMAND.COM entirely by re-naming the file to something personal (LEHIGH7.COM, for example) and changing the name in IO.SYS. Then the only place where the file exists as COMMAND.COM is on ram disk. The virus will have no problem finding it there since that is what comspec will point to; however, that's an expendible version. Of course, the virus could look in IO.SYS for the real name, but it has to do that after boot-up and after the clean command.com and autoexec have had a chance to run and look for trouble. Hopefully, the virus will be content to feast on easier pickings! Art Larky ========================================================================= Date: Wed, 17 Aug 88 10:26:34 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Ken van Wyk Subject: Re: More on command.com In-Reply-To: Your message of Wed, 17 Aug 88 10:15:11 EDT > My suggestion was to get rid of C:\COMMAND.COM entirely by > re-naming the file to something personal (LEHIGH7.COM, for > example) and changing the name in IO.SYS. I believe that it's even easier than that; you can put a SHELL=C:\LEHIGH7.COM statement in your CONFIG.SYS file. Of course, a virus *could* parse the CONFIG.SYS for a SHELL statement... Ken Kenneth R. van Wyk Today - 19th anniversary of Woodstock. User Services Senior Consultant Lehigh University Computing Center You kids are great! Internet: - Max Yasger, the man who owned the BITNET: farm on which Woodstock was held. ========================================================================= Date: Wed, 17 Aug 88 12:28:58 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Art Larky " Subject: Re:re:command.com >> My suggestion was to get rid of C:\COMMAND.COM entirely by >> re-naming the file to something personal (LEHIGH7.COM, for >> example) and changing the name in IO.SYS. >I believe that it's even easier than that; you can put a >SHELL=C:\LEHIGH7.COM statement in your CONFIG.SYS file. Of course, a >virus *could* parse the CONFIG.SYS for a SHELL statement... >Ken True, I guess I feel better having the file name buried in autoexec, particularly since I could have autoexec execute some program with an innocuous name that, in fact, was copying my 'LEHIGH7.COM' to ram under the command.com name. Now the virus has to examine everything that autoexec executes looking for my copy program. I could encode the file names in that program so they would not be recognizable and could not be parsed by the virus. As I said before, go pick on a smaller guy, Mr Virus. Art Larky ========================================================================= Date: Wed, 17 Aug 88 14:03:47 LCL Reply-To: Virus Discussion List Sender: Virus Discussion List From: Scott C Crumpton Subject: "Computers and Security" Would someone please post an address and subscription info for "Computers and Security". Thanks. ---Scott. * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * | Scott C. Crumpton | Bitnet: nescc@nervm | | MVS Systems Programmer | Internet: nescc%nervm.bitnet | | NE Regional Data Center | Voice: 904-392-4601 | | 233 Space Sci. Research Bldg. * - * - * - * - * - * - * - * - * - * | University of Florida | If you want an offical opinion, | | Gainesville, FL 32611 USA | ask my cat. That's his job. | * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * ========================================================================= Date: Wed, 17 Aug 88 14:29:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: the Preserver Subject: How to subscribe to _Computers and Security_ Many thanks to Ken for providing me with a lead. To get a complimentary copy of _Computers and Security_ send a letter requesting such to Computers and Security c/o Dr. Highland 562 Croydon Road Elmont, NY 11003 Please include your name, organization (if any), and mailing address. The complimentary copy will arrive in about 4-6 weeks, and (I guess?) subscription information will be inside it. Les vishnu@pine.circa.ufl.edu vishnu@ufpine ========================================================================= Date: Wed, 17 Aug 88 13:47:16 CDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Len Levine Subject: Re:re:command.com In-Reply-To: Message from "Art Larky" of Aug 17, 88 at 12:28 (noon) > >>> My suggestion was to get rid of C:\COMMAND.COM entirely by >>> re-naming the file to something personal (LEHIGH7.COM, for >>> example) and changing the name in IO.SYS. > > >True, I guess I feel better having the file name buried in autoexec, >particularly since I could have autoexec execute some program with >an innocuous name that, in fact, was copying my 'LEHIGH7.COM' to ram >under the command.com name. Now the virus has to examine everything >that autoexec executes looking for my copy program. I could encode >the file names in that program so they would not be recognizable >and could not be parsed by the virus. As I said before, go pick on >a smaller guy, Mr Virus. > Art Larky > I truly do not understand how you can use autoexec.bat for protection. That program gets run very late in the boot process. As I understand it, the boot examines config.sys to see what is to be established as a part of the io and msdos resident portions of the code, and only then brings up command.com (or its alias) and finally after command.com is loaded, it is executed with autoexec running as the first job. + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + | Leonard P. Levine e-mail len@evax.milw.wisc.edu | | Professor, Computer Science Office (414) 229-5170 | | University of Wisconsin-Milwaukee Home (414) 962-4719 | | Milwaukee, WI 53201 U. S. A. Modem (414) 962-6228 | + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + ========================================================================= Date: Wed, 17 Aug 88 15:38:00 EST Reply-To: Virus Discussion List Sender: Virus Discussion List From: ZDABADE@VAX1.CC.LEHIGH.EDU Subject: RE: Re:re:command.com For *most* Command.com viruses, isn't it better to get rid of the virus as soon as possible (using autoexec.bat techniques such as Art Larky and I have suggested) than not protecting in such a manner at all? The less time the virus is around, the better a computer's chances for survival, I think. Mr. Levine: What method do you use in protecting from this strain of virus? /-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-\ | 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! | \________________________________________________________________________/ ========================================================================= Date: Wed, 17 Aug 88 17:24:46 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Art Larky " Subject: Command.com again Len Levine says: >I truly do not understand how you can use autoexec.bat for protection. >That program gets run very late in the boot process. As I understand >it, the boot examines config.sys to see what is to be established as a >part of the io and msdos resident portions of the code, and only then >brings up command.com (or its alias) and finally after command.com is >loaded, it is executed with autoexec running as the first job. I'm assuming that you have been able to defend yourself enough so that you are starting out with a clean copy of the re-named command.com and have not yet been infected. Then everything is under your control through the boot process and you are working with a benign, healthy, un-adulterated command.com. If you have checked and medically certified your autoexec.bat, then you are starting up your system cleanly. Autoexec can contain the code to make the temporary copy of command.com in ram disk (from hidden sources and using encripted file names) and can run your CRC checkers and set up Flushot or whatever to watch over what you do after that. If, despite your precautions, command.com gets infected, its the only the ram copy and that goes away when you reboot. If you want to be safe truly, don't let anyone near your machine and don't ever run anyone else's software or anyone else's disks. What I hope I am suggesting is a method of making infecting my command.com hard enough that the virus will not get a good toe-hold on my system. Keep the comments coming - as long as I can argue them down, we have a viable possibility for protection. Art Larky Professor, CSEE, Lehigh University ========================================================================= Date: Wed, 17 Aug 88 19:20:14 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Loren K Keim -- Lehigh University Subject: System Generality Since it was brought up, Computer Generality basically means that a computer is designed for one function, unlike an IBM PC which can be used for many many functions. Fred Cohen has stated in the past that we should limit a machine's usefulness in order to prevent viral spread. I'm not sure that is the answer. Agreed that if a computer cannot produce multiple functions, its very difficult, if not impossible, to propogate a virus through that particular system. Unfortunately, the machines that are most at risk from damage from computer viruses are government computers, banking computers and so on. If we make these machines specific to a purpose (ie: have a database program in ROM and allow no other program to run), then we limit our ability to climb the technological ladder. As we design faster and better systems, we have to replace everything we have. If we do not have these machines as specific purpose machines, then they are still in almost as great a risk group as before. Lorne ========================================================================= Date: Wed, 17 Aug 88 19:24:44 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Loren K Keim -- Lehigh University Subject: Conference Speaches For the many, many people who sent me letters asking if they could get "minutes" from this conference: I will try to compile copies of all the speaches made at this conference and have someone take notes on panel discussions. We will then make this available to those who cannot make the meeting. The book which we will be distributing at the conference will also be available. We will probably charge for the book, to handle printing costs and shipping costs, but I think it will be well worth it. Incidently, we've had a lot of talk about protecting command. com on MS-DOS micros. And we've had quite a few good comments. One thing I should point out though is that command.com viruses are a small portion of the types of viruses out there that hide themselves in the boot sector, Bios, Io, executables, command files, in memory, and even between sectors (theoretical, I haven't seen one myself). Protecting command.com helps to protect your system, but the system must be protected as a whole, which is more difficult. Loren ========================================================================= Date: Wed, 17 Aug 88 22:05:34 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "David A. Bader" Subject: viruses Loren Keim states: >Agreed that if a computer cannot produce multiple functions, >its very difficult, if not impossible, to propogate a virus >through that particular system. Doesn't the very definition of a "computer" mean that it can perform various functions? Otherwise what would the use of one be besides a paperweight? Loren continues: >> Unfortunately, the machines that are most at risk from damage from computer viruses are government computers, banking computers and so on. If we make these machines specific to a purpose (ie: have a database program in ROM and allow no other program to run), then we limit our ability to climb the technological ladder. As we design faster and better systems, we have to replace everything we have. If we do not have these machines as specific purpose machines, then they are still in almost as great a risk group as before. Lorne >>endquote What reasons do you have that banks and government systems are more infested with viruses??? Although it must be a hard statistic to find, since most humans don't know what a computer virus is even if it were to kill their main-frame or PC, I would think that the major virus attack is on such computers as PC labs, university systems, (and other "public sites" that can't monitor most users of the system.) On a banking system, for all our monies sake, I would hope that 1) only authorized administrators use the computer, and 2) none of them want to kill their bank's files. (The ssame reasoning goes with the government.) David A. Bader DAB3@LEHIGH ========================================================================= Date: Thu, 18 Aug 88 00:15:44 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Loren K Keim -- Lehigh University Subject: Virus Infection Potential David, > Doesn't the very definition of a "computer" mean that it can > perform various functions? Otherwise what would the use of > one be besides a paperweight? I have never seen a computer defined as a box that can perform various functions. A computer can do one specific function without being a paperweight. Have you ever seen a calculator? Have you seen a television? In a way, each of these is a computer and each has a specific function. What I said in my letter, paraphrasing Fred Cohen, is that if we make computers perform one specific function (like a computer to open doors for us when we approach, or a computer to cook our food in the microwave) then it does not have a serious problem with viruses. If we limit the functionality of a computer, we limit the approach, or the infectibility of a computer. Unfortunately, it also means that we may need more equipment to do something. I also never stated that government and bank computers were more infected than other computers, nor that they were more at risk of being infected. They DO however, often have the most to lose. I believe I also added a "so on" onto the end of that. What I was saying is that we have to protect our "secure systems" (I'm sure most of you have heard the term before). Viruses have been able to do what other programs cannot, they sidestep security by entering a computer by way of an authorized user who doesn't realize that he or she is carrying the virus. It doesn't matter much if a college LAN loses all its information (unless someone stores important research on that LAN), but it is critical if a large banking institution loses all its records (which happened recently), or if NASA loses the program which runs the spaceshuttle just as its blasting off. > I would hope that 1) only authorized administrators > use the computer, and 2) none of them want to kill their > bank files. This is absolutely irrelevant. Few people PURPOSELY infect their computer systems. How many of us go around injecting bad programs into our own important files? That is rediculous! When someone's disk is infected by a virus, they generally don't know it. They spread the virus to their company's files accidently, they don't realize that they are carrying something deadly to their records. Loren Keim ========================================================================= Date: Thu, 18 Aug 88 03:02:36 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Robert Newberry Subject: Beginnings Hello all I was wondering when the first computer virus was first descovered? Rob... ========================================================================= ROBERT NEWBERRY = = UNIVERSITY OF AKRON = I COUNLDN'T THINK OF ANYTHING = COMPUTER CENTER = WITTY TO SAY! = AKRON OHIO 44304 USA = = ========================================================================= ========================================================================= Date: Thu, 18 Aug 88 09:10:46 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "David A. Bader" Subject: reply to virus chat >> Doesn't the very definition of a "computer" mean that it can >> perform various functions? Otherwise what would the use of >> one be besides a paperweight? > >I have never seen a computer defined as a box that can perform >various functions. A computer can do one specific function >without being a paperweight. Have you ever seen a calculator? >Have you seen a television? In a way, each of these is a computer >and each has a specific function. I agree that a calculator is a computer, and it can perform various functions... It CAN also have I/O lines (such as to printers or input tape or something like that.) Also, If in one of your previous messages you said that theoretically viruses can hide in between disk sectors, why can't they hide in the memory of a simple calculator... Maybe 2 + 2 *does* equal 5 on a corrupt calculator!!! Also, isn't a "computer" as we call it (like a PC or a mainframe) just a glorified calculator. The center of a computer's functioning is its ALU, and that is just the same as a calculator, just on a different scale. As for a TV being a limited function computer, so is the human body for that reason! You have input, output, conversions inbetween... I don't think resorting to a TV is a good example though of a single function computer since ANYTHING we name can be a one function computer! >What I said in my letter, paraphrasing Fred Cohen, is that >if we make computers perform one specific function (like >a computer to open doors for us when we approach, or a >computer to cook our food in the microwave) then it does >not have a serious problem with viruses. If we limit >the functionality of a computer, we limit the approach, >or the infectibility of a computer. Unfortunately, it >also means that we may need more equipment to do something. Don't we already have these things?? How about at security doors where you need to punch in a code to open the door? That is a computer there, or most microwave are digital making them computers of sort.. My point is that when we talk viruses, we usually mean "computers" on one-level deeper, but ANY one-function computer can get a virus if the correct input is applied. > They DO however, >often have the most to lose. Why do banking systems and government systems have the most to lose?? EVERYONE has a lot to lose. Any PC has a lot to use, and I would bet that the storage on PC systems totalled in the country (all kinds of media) is far greater than the banking and government systems. Also add in the universities and public areas of computers; they, too, have a *lot* to lose. >Viruses have been able to do what other programs cannot, >they sidestep security by entering a computer by way >of an authorized user who doesn't realize that he or >she is carrying the virus. While this is true and I agree with the statement, also remember that many systems crash because of inexperienced users with the authorization. I think most will agree that the person who has no idea how to use a system can do the most damage! >It doesn't matter much if a college LAN loses all its >information (unless someone stores important research >on that LAN), but it is critical if a large banking >institution loses all its records (which happened >recently), or if NASA loses the program which runs >the spaceshuttle just as its blasting off. Why do you assume that a LAN will have backup, but large banking institutions and NASA don't?? A LAN might have just as much information that changes daily, only less humans are involved when the data is corrupted. In a large banking institution, I would assume that and data corruption umbrellas down into a few hundred thousand customers. >> I would hope that 1) only authorized administrators >> use the computer, and 2) none of them want to kill their >> bank files. > >This is absolutely irrelevant. Few people PURPOSELY infect >their computer systems. How many of us go around injecting >bad programs into our own important files? That is rediculous! >When someone's disk is infected by a virus, they generally >don't know it. They spread the virus to their company's >files accidently, they don't realize that they are carrying >something deadly to their records. This is not absolutely irrelevant. A lot of time bombs (and conceivably virus-type time bombs) have been left in systems by disgruntled workers, or system programmers who want an insurance that a company will pay for the software, or as a means of assuring that the system won't be given to anyone else. If you consult the National Security of Computers (?) department under the Department of Defense, I am sure that they will have a lot of cases to share with you. David A. Bader DAB3@LEHIGH ========================================================================= Date: Thu, 18 Aug 88 13:27:09 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Loren K Keim -- Lehigh University Subject: Limited Functionality The first computer virus, Robert, according to Fred Cohen was done at a computer security meeting in 1983. (I think it was October, but I am not 100% certain of that). However, the Navy had been working with virus-like programs for a long time before that. As one member of this list mentioned to me before, there were writings on viruses as far back as the 40's. As for Limited Functionality, since there is still a problem with it, I will define it one last time, and I will define it slowly. A virus cannot infiltrate a good computer system that is completely isolated if it does not already have one built in to the software that it came with. When I mean isolated, I mean we can use NO other software on it other than that which it came with, and have no modem, nothing connected to it. It is isolated. It has been proven over and over again... a virus cannot infect this machine, because there is no way for a virus to enter it. The government back in the 70's came up with a whole slew of ideas about isolating computers, but a computer cannot easily be completely isolated. So they came up with two alternatives: Limit the access to the machine as completely as possible, or Limit the functionality of the computer. What they meant by Limit the Functionality of the computer, later redone by Fred Cohen, was that if a computer had all its programs BUILT IN to the computer, and if it could not run an outside program, and if it had some specific function. Then there really isn't a way for a computer to enter the system. Memory is reserved for data. A special bank is for the program and that is unable to be written to. In later talks, Fred Cohen described computers which were designed for special purposes, like opening doors for people and feeding the fish. If there isn't anything connected to these computers, ie: no I/O ports and no outside access, then there really is no way for a virus to enter. Likewise, its pretty hard for a virus to propogate if it doesn't have a lot of similar connected boxes. > Don't we already have these things?? How about security > doors where you need to punch in a code to open the > door? Yes, we do. And you have just fried your own theories. You stated that viruses could propogate across single function boxes, and then you say that these boxes exist. Isn't there a security system around? Yes, there is. Have you ever seen a virus attack one? I haven't. Also, yes a single-function computer MAY be able to "get" a virus, but its not good for spreading viruses. Many single function boxes which are unlike are VERY hard to write ANY virus for. By this point, we would have made it so difficult to write a virus that one could not easily exist. > Why do banking systems and government systems have the most > to lose?? EVERYONE has a lot to lose. Again, I never said that banking systems and government systems ALONE had the most to lose. I said that it would be very dangerous for these and LIKE systems to be destroyed. If a major bank lost all its records. WE would be in trouble. Our economy may feel the damage. If the government's nuclear device-controlling computer was set off by a virus... WE would all be in trouble. This is much more serious than YOU losing a few games and a research paper for one of your professors, don't you think? > Why do you assume that a LAN will have backup, but large > banking institutions and NASA don't? Nowhere did I say anything about backup. Quit putting words in my mouth. That is wonderful to fuel an argument, but we're trying to have rational discussions, not scream at each other. Backups are, as always, important. One problem we've run across is a virus that will delete all the files on a system, but before doing this, it lies in weight for several months. When you load the last system, it destroys this as well because its after a certain date. People don't quite understand, so they load the second oldest, which they lost also. By this point they get the picture, fix the problem when they load the next time... but its too late... we've lost 2 months worth of work. Backups are NECESSARY though. Loren ========================================================================= Date: Thu, 18 Aug 88 14:47:00 MDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Kent Cearley - UMS - 492-5262 Subject: Debate >As for Limited Functionality, since there is still a problem >with it, I will define it one last time, and I will define >it slowly. Loren, I sense some unnecessary antagonism here. Without putting words in your mouth, it appeared to me the concept of limited functionality was adequitely understood, I believe its utility as a practical solution to infection was being questioned. Certainly it follows that if a system accepts no input, and originally contains no contaminated code it will not acquire any, it really doesn't require much 'proof'. Limiting functionality would seem to simplify management of the dedicated machine, but, I believe in most instances the utility of such an arrangement would be in its interconnectivity to other specialized processors. This connectivity or network could be viewed as, and is in fact becoming, a 'virtual computer' in its own right, with all the attendent complexities of a general purpose system. Has anyone explored the concept of expert systems regulating security? Perhaps implemented like regression testing in software engineering, i.e. it familiarizes itself with the 'typical' activity of a system... quantitatively e.g. avg disk writes for program 'x', free memory, non-data sector reads/writes, maybe feature analysis techniques, suspending activity in anomalous situations: Threshold for disk writes exceeds typical average: memory map =.... continue Y or N, Attempted write to .COM or .EXE file continue Y or N, programmed in ROM and supplied as a plug in board? Who knows, just free falling to explore different directions and maybe trigger other associations. *-----------------------------------------------------------------------* | Kent Cearley | CEARLEY_K@COLORADO.BITNET | | Management Systems | | | University of Colorado | "All truth contains its own | | Campus Box 50 | contradiction" | | Boulder, CO 80309 | | | | | *-----------------------------------------------------------------------* ========================================================================= Date: Fri, 19 Aug 88 06:19:53 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Amanda B Rosen Subject: Limited functionality, definition of 'computer', etc. I'm a little concerned about butting into an argument that seems to be getting personal, but here goes... (I don't know _anybody_ on this list personally, so I'm not taking any sides...) David Bader's most recent lengthy article made many statements. I disagree with every one. Maybe he had a bad day (I know I'm having one), but I'll try to go over a couple that seemed to stand out. First, David asks how to define a computer, and why the definition of Limited Functionality is useful (I'm paraphrasing, so if I read it wrong, sorry...). In general, and without getting into any CS theory, I would say that a useful definition of 'computer' would be the turing machine. Modify that by looking at the PCs, Macs, Vaxen, and 4381s of today for a more bounded but useful definition. This is not what you would call a strict definition, but it's useful because we all understand it. In particular, a calculator or television don't qualify as (general-purpose) computers for obvious reasons. On the other hand, there are limited-functionality machines. Another intuitive definition is useful here: they are machines which, whatever the underlying capabilities of the component hardware, are NOT turing machines. Two good examples- 1) a security device, as described in David's article. It does not have a general-purpose CPU. It is inherently incapable of many things, such as arithmetic. 2) A building-directory computer. It is based (for example) on a 68000 machine, with lots of ROM and almost no RAM. While the hardware is, inherently, a turing machine, this actualization will never be capable of adding two numbers, either. Both of the limited-functionality devices described have the same chance of being infected by a virus: none. It's just not possible. This directly contra- dicts David's statement "ANY one-function computer can get a virus if the correct input is applied." On another topic, while novice users can be dangerous, there is no way a novice, no matter how clumsy or careless, can cause your data to become corrupt a month after his/her use of the machine, after the backups have been contaminated... Novices are also incapable of inflicting serious damage on mainframes or minis (or PCs with protection in the OS). Fianlly, it is always the institutions with the most at stake that have the most to lose (simple truism). What some people fail to see is that banks, defense systems, and the like, are the most likely to draw sophisticated viral attacks. While I'm not hugely fond of Cyberpunk stuff, read Gibson's Neuromancer. I hate to say it, but Gibson is probably very accurate in his portrayal of what computer security is going to be like in the not-too- distant future (although I have my doubts about his "Cyberspace matrix"). If you're a crack programmer worth $250 an hour, are you going to spend a month writing a virus to bring down a campus LAN? Or are you going to write one that redirects funds from bank networks to a numbered bank account? The other thing that people forget is that the real viruses of tomorrow won't be acts of vandalism, mostly. They'll have a purpose. Sorry for rambling, but it's 5:30 AM... I sure hope this makes as much sense tomorrow as it does now :-) /a ========================================================================= Date: Fri, 19 Aug 88 10:39:25 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Loren K Keim -- Lehigh University Subject: The First Virus Quite a few people wrote to me to tell me that I was incorrect in my definition of the first virus. That there have been viruses around for years. I quite agree. What I meant was that Fred Cohen, in his famous article describing viruses back in Computers and Security (No 6, 1987?) he told us that the first virus was conceived "of as an experiment to be presented at a weekly seminar on scomputer security" on November 3, 1983. He goes on to explain how this was the first virus and the very first virus experiment. I disagree with Fred on many point, and this is a maojor one. If anyone has had experience with viruses before this point in time, I would be VERYa happy to hear about them. I've documented a few minor comments in the past, but nothing concreit with the exception of some government work studying poropogating programs. Also, I'm looking for a copy of "Communications of ACM" from way back in March, 1982. Pages 172-180 contain information about the Xerox Worm program which got out of hand a few years back. Loren Keim ========================================================================= Date: Fri, 19 Aug 88 12:59:23 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Ken van Wyk Subject: Limited Functionality Granted, limited functionality can certainly reduce the risk of a machine being infected by a virus. I wouldn't go so far as to say eliminate the risk, though. At least in the case of a machine in which a CPU is getting instructions from ROM. After all, where did the instructions for the ROM come from? Unless you can insure that the ROM itself is free from contamination, then you cannot say that there is no virus in that machine. At some point, the ROM had to be written to. It is true, however, that an existing uninfected ROM device cannot be written to by a virus, assuming that the ROM is, indeed, unwritable. Nonetheless, such a limited functionality machine certainly does have limited application, as the name would imply. An arcade video game is a good example of one. There aren't too many applications in which a limited functionality machine would be too useful, or at least practical. I certainly wouldn't want all of the applications on my PC burned into ROM, never to be altered. It would make life on the computer very difficult. Ken Kenneth R. van Wyk Calvin: Dad, can I have a flame thrower? User Services Senior Consultant Dad: Of course not! Lehigh University Computing Center Calvin: Even if I don't use it in the Internet: house?!!! BITNET: ========================================================================= Date: Fri, 19 Aug 88 17:45:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: WHMurray@DOCKMASTER.ARPA Subject: Re: Protecting Command.com In-Reply-To: Message of 16 Aug 88 21:20 EDT from "Art Larky " >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. But of course, a virus that did that would not be very clever would it? A truly clever virus attempts to exploit similarities among its potential targets. The beauty of your scheme is that it makes you just sufficiently different from your peers to remove you from the target population. Viruses exploit similarity; they do not need to attempt to accomdate themselves to differences. If you are the only target, any Trojan Horse attack will do. A virus is redundant. If you are not the specific target, then the success of the virus does not depend upon infecting you. All of those who have not taken steps to remove themselves from the target population, are sufficient. The virus does not need you. Thus, to F. Cohen's list of sharing, generality, and transitivity, we can add "similarity." 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: Fri, 19 Aug 88 19:38:00 EST Reply-To: Virus Discussion List Sender: Virus Discussion List From: ZDABADE@VAX1.CC.LEHIGH.EDU Subject: Hiding a virus between disk sectors I have a simple question regarding viruses in between disk sectors. I can play arount with all the timing and sector markings in between disk sectors with my Central Point Options board. I know how to make copy protections with this, and other little tricks. What would the theory be behind putting a virus in between sectors? (Anything is possible, I am just curious on how that would make viruses any different or any other spew about a virus like that. Also, how would virus detection have to change?) 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! | \________________________________________________________________________/ ========================================================================= Date: Sat, 20 Aug 88 14:13:18 +0100 Reply-To: Virus Discussion List Sender: Virus Discussion List From: Stefan Parmark Subject: Can't get log8805 Ken! I am having trouble getting log8805. Your list server has confirmed that it has been sent, but I haven't received it yet. That was two weeks ago, and two more attempts have given the same result. I guess it is the file size that is the trouble. Splitting it in two halves would probably work. /Stefan Parmark ========================================================================= Date: Sat, 20 Aug 88 14:14:34 +0100 Reply-To: Virus Discussion List Sender: Virus Discussion List From: Stefan Parmark Subject: Moving to new site After the 26th of August I can no longer be reached at tmpspa@eua4.ericsson.se. That account will probably be removed, so any mail will probably bounce. I will of course unsubscribe to this list before I leave. My new address will probably be something like d84spa@.lth.se, but I will let you know. Oh, by the way, before I leave I will send my report to Ken like I promised. It won't contain anything revolutionary, although it will summarize what has been said about infections here. /Stefan Parmark ========================================================================= Date: Sat, 20 Aug 88 14:12:24 +0100 Reply-To: Virus Discussion List Sender: Virus Discussion List From: Stefan Parmark Subject: Re: Mainframe viruses Joe and Loren! My mail to you doesn't seem to get through, so I will put this on Virus-l instead, which I know both of you read. Joe, you say that you have tracked down several viruses. As I say in my inquiry, I am not interested in *where* it happened, but *what* happened, what it did, how you found it and restored the machine, etc. I will be quite satisfied with a couple of lines describing the major events. Details are interesting, but not really necessary, if you aren't in your best writing mood. If you don't think this means leaking too much information, then please tell me! Refer to the different companies/universities as company A, university B, and so on, if you don't want their names to be known. I am interested in information about the Innoculator. If you have a brochure describing it, please send me one. If you can't e-mail it, please telefax it to +46 8 7490594. The reason is that the surface mail takes a little while, and I don't have more than one week until my report must be finished. If the Innoculator seems safe, we will consider buying it. If you have references from satisfied customers, please include them too. The department of Ellemtel at which I am working has a high security classification, class 2 I think. Therefore a virus protection is highly desirable. Their VAX was earlier connected to UseNet, but the risk for infections made them "cut" the wire. They will restore the connection whenever they feel safe, which I am supposed to make them. In case you wonder, I am using another department's computer to mail you. Loren, I have mentioned your idea about a conference to some people working with me. They, and I too, are interested in such a conference. I will inquire how interested they are. When I know, I or they will get back to you. /Stefan Parmark P.S. You know about the pubkey mailing list, don't you? They're discussing Lee Kemp's public key encryption to protect from viruses. If you are interested, send a mail to Doug Thompson at doug@isishq.math.waterloo.edu. ========================================================================= Date: Sat, 20 Aug 88 14:16:15 +0100 Reply-To: Virus Discussion List Sender: Virus Discussion List From: Stefan Parmark Subject: Nomenclature needed I feel that the term 'virus' is being used too often when one really means something else. I think it is important that there is a term which will cover worms, viruses, Trojan horses and bacteria. As a general term I would like to propose 'infection'. I am not a biological expert, so perhaps some other word would be better. The important thing is that when anyone says 'virus' we know what he means. /Stefan Parmark ========================================================================= Date: Sat, 20 Aug 88 09:03:14 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Joe Sieczkowski Subject: RE: Hiding a virus between disk sectors In-Reply-To: ZDABADE@VAX1.CC.LEHIGH.EDU's message of Fri, 19 Aug 88 19:38:00 EST <8808192346.AA26896@scarecrow.csee.lehigh.edu> I really can see the practicality of viruses hiding in between sectors. For one there isn't much room, maybe space for several bytes, no more. The virus would have to be careful not to overwrite the following sync mark or make the next sector unreadable by DOS. Finally, there would have to be a sophisticated program to read the data between sectors, concatenate the information (ie the virus), and then execute it in memory. Since this sopisticated program is not a part of DOS, and since it itself could not be hidden between sectors, the point of putting a virus in between sectors is moot. Joes ========================================================================= Date: Sat, 20 Aug 88 09:20:16 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Joe Sieczkowski In-Reply-To: Kent Cearley - UMS - 492-5262 's message of Thu, 18 Aug 88 14:47:00 MDT <8808182056.AA24237@scarecrow.csee.lehigh.edu> Subject: Debate >Has anyone explored the concept of expert systems regulating security? >Perhaps implemented like regression testing in software engineering, >i.e. it familiarizes itself with the 'typical' activity of a system... >quantitatively e.g. avg disk writes for program 'x', free memory, >non-data sector reads/writes, maybe feature analysis techniques, >suspending activity in anomalous situations I beleive AT&T's new version of secure Unix will do somthing like this. Although I am not affiliated with the company perhaps someone reading this is and can confirm and expand on this. Joes ========================================================================= Date: Sat, 20 Aug 88 18:12:15 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Jim Marks Subject: Re: Can't get log8805 In-Reply-To: Message of Sat, 20 Aug 88 14:13:18 +0100 from Ken, Stefan is not the only one who has had this problem with log8805. I requested it and haven't received it also. I've been reading back through the old logs and have successfully received all the other ones. Jim Marks ========================================================================= Date: Sat, 20 Aug 88 18:31:34 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Jim Marks Subject: LOG8805 retraction I spoke too soon about not being able to receive the 8805 log. After sending my previous reply, I found the subject log waiting in my reader list. It WAS quite large; that is probably why it takes quite a while to move through the network. Jim Marks ========================================================================= Date: Sun, 21 Aug 88 15:20:00 EST Reply-To: Virus Discussion List Sender: Virus Discussion List From: ZDABADE@VAX1.CC.LEHIGH.EDU Subject: RE: Hiding a virus between disk sectors > >I really can see the practicality of viruses hiding in between >sectors. For one there isn't much room, maybe space for several >bytes, no more. The virus would have to be careful not to >overwrite the following sync mark or make the next sector unreadable >by DOS. Finally, there would have to be a sophisticated program >to read the data between sectors, concatenate the information (ie >the virus), and then execute it in memory. Since this sopisticated >program is not a part of DOS, and since it itself could >not be hidden between sectors, the point of putting a virus >in between sectors is moot. > >Joes I've been playing around with my Options board and found that there is at least 50K of characters that I can string together between sectors on the 40 tracks of a 360K IBM floppy. (There is probably twice that much data room available, but then it might interfere with the buffers of data on the physical disk for marking where a sector begins and ends and the sector type bytes(good, bad, etc.). Would it not be trivial for someone to write a small useful utility (or take an already existing one) that a lot of people might use, and tack on the data to propogate this type of virus? How would the detection of this virus have to change from already existing techniques? File size changes wouldn't be that evident because the virus would be hidden on a non-counted part of a dsik, and the virus carrier program would still be the same general size with just a jump to the virus code... Any ideas out there? David /-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-\ | From: David A. Bader, Studentis Maximus | | | | DAB3@LEHIGH SloNet: 1402 Lorain Avenue | | ZDABADE@VAX1.CC.LEHIGH.EDU Bethlehem, Pa. 18018 | | HACK!DAB@SCARECROW.CSEE.LEHIGH.EDU | | | | SchoolNet: Box 914, -On a mostly harmless | | Lehigh University, blue green planet... | | Bethlehem, Pa. 18015 -And loving it! | \________________________________________________________________________/ ========================================================================= Date: Sun, 21 Aug 88 17:06:50 PDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Robert Slade Subject: Viral information file Regarding the request for an archive of virus message information, I have been collecting and distributing such for some time, predating the existence of VIRUS-L. As explanation, herewith (and I appologize for the length) a recent submission to RISKS-FORUM. (Also, regarding the recent request for the first virus, I seem to recall one person mentioning that he wrote one for the Apple in about 1979. It's in the file somewhere.) One other thing. The file has now passed 700K. Multiple floppies would be a good idea. =================== Following my recent reposting of the directions for the "Virus file" (and pursuant to Chip Copper's attempt to establish a "Center for Virus Control"), I received the following message: Subject: Virus collection??? From: JKILLY@BINGVMB Hello--I saw your posting of a set of collected virus messages in RISKS, and I just had to respond. Please forgive, but are you for real? This sounds like you're dispensing hellish little packages of unadulterated evil! If the "collection" is so interesting, why don't you upload it and distribute it in a format that is not so inherently threatening? A person would have to be nuts to put your 5.25" diskette in any micro (I guess some clean shop that destroys units on a good day might find it acceptable). I'm not mad, just curious: What *is* the point of distributing this stuff on diskette? Thanks very much for your response. --Jake There seem to be two issues to address here. One is the already well addressed theme of whether or not you talk about matters relating to security. I generally come down on the "let-the-users-know,-and-chance-it- on-the-hackers" side of the discussion. In the case of viri, the users are everywhere, and (as has been ably pointed out by others) society in general is going to be affected by the mere *existence* of virus programs. So, I am compiling and distributing the material. Second issue: *what* am I compiling. First off, I am not collecting and distributing virus programs themselves (so you can give up on the requests "Ultimate_Hacker", and sorry, Chip, I wish I *could* help.) The file is a collection of messages from RISKS-FORUM, INFO-MAC, INFO- IBMPC, VIRUS-L, Computers and Society Digest and various text postings on private bulletin boards. *All* the material is therefore readily accessible; I am simply trying to save time for those who are trying to work in this area. Simply collating all the material is taking several hours per week, and I have not yet had time to edit it all. The bulk of the material is from RISKS. The topics I select for are those announcing or analysing new viri, those suggesting virus protection schemes (and critiques of those suggestions), opinion pieces on the implications of viri and some messages on related security matters (such as the recent discussion of "block mode" on terminals.) The total size of the file is now in excess of 700K, and is being sent out in archived form. (The current archive breaks out into two files, MASTER1.VIR and MASTER2.VIR.) I suspect that by the time you read this, the total file will no longer fit on a single disk, even archived. FTP is not available from UBC, and I am not going to send out a 700K+ file out as one or more message(s) on a daily basis. Future editions of this file can be obtained by sending a PC formatted disk in a (Canadian) stamped, self addressed mailer to: Robert M. Slade, 3118 Baird Road, North Vancouver, B. C. Canada V7K 2G6 I hope this goes some way to allaying Jake's fears. Prudent caution would appear to be very healthy in our current environment (although I would think you could find *some* way of testing what you receive from unknown sources.) Disclaimer: ... ah, what's the point. Nobody'd believe it anyway ... P. S. - Herewith a local virus warning from a ways back ... --------------------- From: Greg Slade Rec'd To: All Msg #55, 13-May-88 12:17pm Subject: *** Warning *** From: Steve Fairbairn To: All Msg #162, 29-Apr-88 03:14pm Subject: TROJAN **** ALERT **** * Original: FROM.....Tom Sirianni (153/4) * Original: TO.......All Sysops (153/102) * Forwarded by.......OPUS 153/703 * Original: FROM.....Tom Sirianni (105/301) * Original: TO.......All (105/301) * Forwarded by.......OPUS 105/301 To All: New TROJAN has hit Portland, Oregon. Two CONSULTANTS who use TURBO PASCAL were using a program called: D-XREF60.COM the program was originally from a PC-SIG library in California but it may show up on the local BBS's. **** BEWARE **** This program is supposed to be a cross reference program for Pascal programmers it does what it says PLUS it randomly deletes file names from the DIR then it all at once scrambles the FAT. Authors name? The infamous DORN STICKLE! Poor boy is really getting blamed for a bunch of stuff. At any rate be careful of this one. I repeat this is a verified TROJAN. This messaage maybe TRANSPOSED to the PUBLIC to help the average User defend him/her self. Tom Sirianni of 105/301 --- ConfMail V3.31 * Origin: SCP Business BBS * This WOC's PC-Pursuitable 1-503-648-6687 (1:105/301) From: Charles Howes To: All Msg #184, 06-May-88 10:48pm Subject: novirus.arc I suspect, after having my system quit, that NOVIRUS.ARC is in fact a virus. My hard disk just wouldn't boot. I couldn't figure out what was wrong, so I copied off only necessary files and then reformatted in dos 3.3. About the only good thing I can say about the program is that it got me to upgrade to 3.3 from 3.1. Whoopee. The above were posted on Dial-A-File. I cannot comment on the content as I have never used either program, but I would advise caution on the part of those who come into contact with them. Greg? 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