Return-Path: XPUM04@prime-a.central-services.umist.ac.uk Received: from G.SEI.CMU.EDU by ubu.cert.sei.cmu.edu (5.61/2.3) id AA25891; Tue, 12 Jun 90 06:48:24 -0400 Received: from SEI.CMU.EDU by g.sei.cmu.edu (5.61/2.5) id AA12987; Tue, 12 Jun 90 06:48:21 -0400 Received: from nsfnet-relay.ac.uk by sei.cmu.edu (5.61/2.3) id AA04279; Tue, 12 Jun 90 06:48:06 -0400 Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK via Janet with NIFTP id aa09678; 12 Jun 90 11:14 BST From: Anthony Appleyard To: KRVW <@NSFnet-Relay.AC.UK:KRVW@sei.cmu.edu> Date: Tue, 12 Jun 90 11:08:24 BST Message-Id: <$TGVTCZHTCBVV at UMPA> Subject: Virus-L vol 0 issue #0814 Virus-L Digest Sun, 14 Aug 88, Volume 0 : Issue #0814 Today's Topics Re: VM mainframe viruses VM Mainframe Infiltration VM Mainframe Problems Virus Writers ------------------------------ Date: Sun, 14 Aug 88 11:42:11 P Reply-To: Virus Discussion List Sender: Virus Discussion List From: Hank Nussbacher Subject: Re: VM mainframe viruses >From: Loren K Keim -- Lehigh University >Subject: Mainframe problems >Date: Thu, 11 Aug 88 16:59:23 EDT > >company as well. It is possible for someone to write a program which >attacks your companies modem program and gets itself to the mainframe >through it. Because there is a large number of users of M, this >virus-modem program can spread from user to user and affect each part of >the mainframe, not just the parts a particular user has access to. > >We have demonstrated this possible problem with Unix computers in >the past, having the virus "pick-up" privilages until it was able >to attack the entire machine. This is a dangerous problem, and one >we cannot take lightly. 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. Your example of a virus-modem program might well work in Unix but it would have to work quite differently in VM. Viruses are basically introduced to a mainframe VM user - simply by their executing a program that has a virus. It is not passed by modem nor in any other method. >From: Joe Sieczkowski >Date: Thu, 11 Aug 88 20:52:25 EDT > >Let's go over a quick example of how a virus might climb the ladder. >Suppose there are several users on a mainframe: Prof Smith, John, >Mary, Jim, System, and The_Rest. Let's say that John, Mary and Jim >are in the professor's programming class and that Prof Smith has >priveledge over their accounts. The user System has priveledge over >all accounts. John decides to upload this great game to the system >(it happens to contain a virus). He executes it and all his files >are subject to infection. Mary executes the program too and >all her files become subject to infection. The Professor >decides to check on Mary's work, so he executes one of her >programming assignments. Well, this assignment was infected >so not only does the Prof. files become subject to infection >but Jim's files become infected as well. Finally, the professor >just finished a software package. He tells System that it's >ready to be installed. System puts it in with the other system >files and executes it to make sure it was installed properly. >Now The_Rest of the system is subject to infection and the virus >has system priveledge. It can do anything it wants! Let us use Joe's example. Notice how we are under the assumption that each user will 'execute' the infected program. One major difference between VM and PC's is that in PCs all the files on disk are accessible by anyone using the PC. In VM, all files are not available - until someone allows you access to his or her files. Unix works in reverse - all files are accessible until you impose some sort of password on it. In VM - all files are not accessible until you impose a password on your individual files. In VM, there are systems disks which only systems people can write to. You are now implying that a systems account has become infected. How does that happen? By running some infected program. How does that infected program get to him? Either via his virtual rdr or via a link to a non-systems disk. Any systems programmer who does either of these is not a professional systems programmer who is responsible for the maintenance of a multi-million dollar computer and thousands of users. The two rules are: 1) Never execute any program that arrives in your virtual reader that you don't know anything about. You can receive it to disk - which will not infect you, but under no circumstance should you execute it. 2) Never link to a disk of a non-systems account. All the programs a systems programmer needs are on systems maintained disks and he/she should not go scavanaging for all sorts of "other" pgms (i.e. games, utilities) that reside on privately maintained minidisks. By doing so, he/she is compromising the operating system he was entrusted to maintain. I remember one systems programmer who violated that rule and a clever kid imbedded a nucleus extension in the systems programmer virtual machine that informed the kid when it was installed via a MSG, then proceeded to set MSG IUCV and SM IUCV and let the systems programmer continue working while all the while everything he was typing appeared on the console of the kid as well as the fact that the kid had set the nucleus extension to accept cmds via IUCV and be executed silently. Imagine the suprise of the systems programmer as one minute he browses PROFILE EXEC and the next instant the kid issues an ERASE PROFILE EXEC via IUCV and the systems programmer never sees it happening. NUCXMAP did not reveal anything, since the kid called his stub NAMEFIND which replaced the original NAMEFIND. Only tracing the virtual machine and finally finding that the NAMEFIND nucleus extension was larger than the one everyone else had made the systems programmer suspicious. But as soon as the systems programmer was close to debugging it - the kid issued a 'NUCXDROP NAMEFIND' and the virtual machine virus disappeared for good. Only by executing the trojan horse game/program would it reappear in the systems programmer virtual machine. The trojan horse program happened to be called RECEIVE MODULE and was located on a users private disk that the systems programmer had accessed ahead of the standard S-disk. Hank -------------------- Date: Sun, 14 Aug 88 14:51:21 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Loren K Keim -- Lehigh University Subject: VM Mainframe Infiltration Hank, I have to disagree with you. You say that a modem-mainframe virus would never work in a VM environment, but we have demonstrated such problems in the past. 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. If properly edited, a program of this kind (this is theoretical, because I don't want to be blamed for such a virus if one comes down the pike) can help you log onto a system and look for standard Rexx files found in certain college systems. It can then append some text to the Rexx program. I don't know how easy it would be to append to an executable file. I have not done any work with that as of yet, but inserting a line or 20 of code into a Rexx program isn't that difficult, particularly if the modem program is set up to help you with editing features and so on. We had a problem here with that particular program a short time ago, in that someone wrote a bogus version which would write passwords to the system out onto a file on the public disks. Any network is in danger, any mainframe is in danger at this time. The difference is how hard a system is to infiltrate, and that is what we have been studying the last several months. As we learn exactly how a system may be infiltrated, we're basically plugging up the holes. Most of our anti-viral programs for mainframes are simply plugging up any holes we can find, and running checks to watch for propogation that isn't warrented. This is difficult to do, but until someone can figure out a design that is very hard to break, we have to do something. Actually, I quite enjoy trying to find a new way of keeping computers clean. Its much like a puzzle, and we have to put the pieces together correctly. Only time will tell... (now where have I heard that before?) Loren -------------------- Date: Sun, 14 Aug 88 15:01:41 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Loren K Keim -- Lehigh University Subject: VM Mainframe Problems Hank, 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. You ask how systems accounts can become infected. What I was implying by the modem senario (and the modem situation is by no means the only way to propogate a virus), the program copies itself from floppy disk to floppy disk, and in public sites with user consultants on hand who have system account privilages, its possible for one of their floppies to become infected. When this happens, unknown to them, a virus can be transferred into a system program which people run. Then we're in big trouble. Or perhaps a user has a program in Fortran he's compiled on the system. A system person runs the program (as some do) and infects his own files. As far as I've seen in my research so far, VM systems are somewhat harder to propogate viruses on FOR ME. I am not that experienced yet with a VM system. I prefer Unix and VMS. Comments? Loren -------------------- Date: Sun, 14 Aug 88 15:06:23 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Loren K Keim -- Lehigh University Subject: Virus Writers One problem with specifically saying how viruses are designed for different systems: Several people have commented to me that those who are responsible for present and possibly future viruses are right here on this list. I don't like telling people how to hard my machines. I like the idea of having a virus conference because when I discuss things with people I have a much better idea of who I'm talking to. Loren -------------------- *** end of Virus-L issue ***