========================================================================= Date: Mon, 8 Aug 88 00:59:40 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Amanda B Rosen Subject: Re: Virii and Screen Output In-Reply-To: Your message of Fri, 5 Aug 88 21:22:18 EDT David Slonosky's idea of a virus concealing itself is quite interesting, but there is a reason I don't think it could work. To really hide, the virus would have to remember the code it was overwriting. Otherwise, finding a chunk of $00s or No-ops in the middle of your code would be pretty suspicious (unless you're looking at COMMAND.COM :-) Anyway, while we all know of the CS1001 problem "write a program that prints itself", this is not that simple. It can't easily print (what's supposed to be) itself since it has no place to put it. It could of course find some spare sectors on the disk, but how is it going to keep from overwriting info kept by another copy of itself? It would have to keep its own directory. How can it prevent DOS from using its sectors (which are free, as far as DOS knows)? It would have to infect DOS. Etc. Etc. Etc. The point is, this virus rapidly grows so complex that it couldn't hide. The original copy would be huge, and it would have a significant effect on the system. Of course, this brings up the nightmareish possibility of a program like this running on a mainframe with enough power that its overhead wouldn't be noticed (or it could doctor CPU usage tables while it was at it...). The only protection against this is the fact that the innards of the OS are protected on mainframes. However, if a superuser (or whatever) was dumb enough to run the necessary trojan... Yuck. ========================================================================= Date: Mon, 8 Aug 88 09:12:05 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: Forwarded info on U.S. virus legislation For everyone who's been interested in computer virus legislation, here's a proposed U.S. bill on just that. This was sent in by Joseph Beckman (thank you!). Ken From: "Joseph M. Beckman" Subject: Virus Bill "Computer Virus Eradication Act of 1988" (a) Whoever knowingly -- (1) inserts into a program for a computer information or commands, knowing or having reason to believe that such information or commands will cause loss to users of a computer on which such program is run or to those who rely on information processed on such computer; and (2) provides such program to others in circumstances in which those others do not know of the insertion or its effects; or attempts to do so, shall, if any of such conduct affects interstate or foreign commerce, be fined under this title or imprisoned not more than 10 years, or both. Entered July 14th 1988 by Mr. Herger (congressman from CA) for himself and Mr. Carr; referred to Committee on the Judiciary, to amend title 18. Joseph Kenneth R. van Wyk Milo: We're out of helium for the User Services Senior Consultant balloons! Who's been suckin' Lehigh University Computing Center the helium?! Internet: Gang: Not me! Not me! ... BITNET: Opus: Eeeeeep! Eeeeeep! ========================================================================= Date: Mon, 8 Aug 88 09:13:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: the Preserver Subject: Washing your hands Someone recently advocated the teaching of "viral hygiene" to joe average computer user while keeping "virus writing" to the experts ( a poor paraphrase, but it gets the point across). This is the wrong attitude. Viruses are a part of the current computing environment, so are worms, trojans, etc... Educating users in prevention is necessary to stem the amount of damage done by these destructive programs. However, if the future computing environments are going to be better, computer diseases 101 had best be taught. The field of computing is growing at an incredible rate and in this growth, nowhere do we see a system completely foolproof. Why not? Because the system designers didnt know about the various kinds of computer diseases. The CIS students of today will be tommorows programmers, educating them now about how virii work, detection schemes, security controls and pitfalls, will in the long run make virus writing something undertaken only by a few experts, instead of the situation we have now where combatting viruses is undertaken by only a few experts and every joe hacker on the street can create a virus for the expert virus hunters to track down. Les Hill vishnu@pine.circa.ufl.edu vishnu@ufpine ========================================================================= Date: Mon, 8 Aug 88 10:44:09 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "David A. Bader" Subject: Flushot Plus 1.4 I have not been subscribing to the Virus List lately, but since I had a question concerning Ross Greenberg's Flushot Plus 1.4, I figured someone here might have an answer for me. Please carbon replies to me. I have an AT-clone and have always tried the Flushot programs (and as I figured out by losing my CMOS memory) - they did me no good. Anyway, I've been using version 1.4 (which was released July 13, 1988) and haven't had any problems (fatal) until today. While using Procomm Plus Test Drive v.1.1 my computer rebooted without me touching any keys. I wondered what was going on, and it rebooted several times. The only change in my system is that now I have FSP14 running. Has anyone else experienced similar problems? (I am unsure that FSP is the culprit, but have eliminated all other possibilities.) One other question that I have concerns my CMOS memory. I have FSP checking my CMOS, and it doesn't erase it like the last version, but WHY when I boot off my hard disk and try to read a floppy does it warn me that "CMOS IS BEING WRITTEN TO"??? Should reading a floppy disk have any effect on CMOS, or is this another annoying bug in Ross's program? Please forward any comments to DAB3@LEHIGH. Thank you, David Bader ========================================================================= Date: Mon, 8 Aug 88 10:08:00 MDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: CEARLEY_K%wizard@VAXF.COLORADO.EDU Subject: Last Reply Art, just a couple of points... > It's not all that easy. DOS (and BIOS) are not re-entrant, so you >would not be able to use any DOS or BIOS calls in your program since >you would not know who was doing what where when you got the tick. >Of course, like all other TSR's you'd have contention problems with >the timer tick. What about all the other people (including DOS) >who expect that tick to be at 18.2? BIOS is, in fact, reentrant. The TSR would not need to rely on any of these services, however, it would merely check interrupt vectors in memory for modifications. You are right about the clock ticks; if you reset the value time might get a little twisted, however, I believe you can also employ Channel 2, normally used for the speaker, but maybe 18.2 would be the resolution you are stuck with. This tactic was really another approach to intercepting a virus which relies on obtaining control from system interrupts. Its utility would be its function in a more comprehensive strategy. *-----------------------------------------------------------------------* | Kent Cearley | CEARLEY_K@COLORADO.BITNET | | Management Systems | | | University of Colorado | "All truth contains its own | | Campus Box 50 | contradiction" | | Boulder, CO 80309 | | | | | *-----------------------------------------------------------------------* ========================================================================= Date: Mon, 8 Aug 88 12:53:18 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Christian J. Haller" Subject: Re: Washing your hands In reply to Les Hill (the Preserver ): >Someone recently advocated the teaching of "viral hygiene" to joe average >computer user while keeping "virus writing" to the experts ( a poor paraphrase, >but it gets the point across). This is the wrong attitude. I think it's the most practical approach we can advocate, in general. > Viruses are a >part of the current computing environment, so are worms, trojans, etc... Only if you expose yourself to them. If you don't try out stuff from uncertain origins, they are not part of YOUR computing environment. >Educating users in prevention is necessary to stem the amount of damage done >by these destructive programs. However, if the future computing environments >are going to be better, computer diseases 101 had best be taught. But not every user has to take it! Give us a break. How much does even a Medical College graduate know about the life cycle of Rift Valley Fever? How much does the average person need to know about how colds operate? Sure, thay should know what viruses are, and how you can't treat a virus with antibiotics, but they shouldn't have to be taught in detail about each of the 127 or more diseases we call colds. It would be useless information to the average person, and a waste of time. Similarly with computer viruses and Trojan Horses, etc.: most users should be aware that such things exist, and know enough about how they work to have a chance of recognizing one when they see its tracks. They should learn some simple rules of hygiene, like using write protect tabs and using a floppy-based system to fool with some RUNME.EXE they just downloaded, if they must try such things at all. Anyone who likes to try out new stuff, to be a pioneer, should know more, like how to install and use some virus detection software. Only a few people should have to learn the nitty, gritty details of how nasty programs accomplish their nefarious tasks, and how to write countering programs. THE REST OF US HAVE BETTER THINGS TO DO! Don't get me wrong. I'm fawningly grateful to you good guys on this list who have chosen (?) to get involved deeply in the struggle. But the computer work of the world is not going to slow down much because of viruses. Susceptible machines, networks, and personal habits will gradually be replaced by safer ones, as a direct result of temporarily "successful" attacks on our software integrity. The average computer user can almost go right on doing what she's doing now. > The field >of computing is growing at an incredible rate and in this growth, nowhere do >we see a system completely foolproof. Why not? Because the system designers >didnt know about the various kinds of computer diseases. Now that they know, I still don't see any completely foolproof systems. > The CIS students >of today will be tommorows programmers, educating them now about how virii >work, detection schemes, security controls and pitfalls, will in the long >run make virus writing something undertaken only by a few experts, instead >of the situation we have now where combatting viruses is undertaken by only >a few experts and every joe hacker on the street can create a virus for >the expert virus hunters to track down. Let's not confuse the average user with either CIS students or system designers. CIS students should learn what you say they should learn, yes, but not more than that. They should also know that it is relatively easy to write a virus, that it is a rotten, unethical thing to do, that it can get you ten years in jail and a ruined financial life, that most viruses can be detected and traced back to their origins if some Sherlock gets on the trail in time. Those who like the idea of being Sherlocks can be encouraged to learn more if they want. Most of us think it more fun and challenge to be on this side of the contest, anyway. Average users should hardly have to learn or do anything but run the one to three applications they want to use. They have work to do. Most of them have a friend who knows about systems and software, whom they trust to let them know when something useful comes along. This is the way things are, and should be. Those of you closely involved with this list--I love you, but don't overstate the need for everyone to join in your enthusiasm. Virus etc. outbreaks have not affected the average user yet, and may not ever. (Thanks to you!) --Chris Haller ========================================================================= Date: Mon, 8 Aug 88 17:56:00 CDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: John Stewart Subject: re: Campus Virus Letter I recently posted a message to the list in reply to Len Levine's paper on Viruses. In it I attempted to define a virus. I received several replies, but then we had a problem at our site causing all our incoming Network mail to be refused, and outgoing mail to be deleted. If anyone attempted to contact me during the period of 08/04/88 and 08/08/88 your mail was lost. I would appreciate any re-transmittal of any replies. Thanks for your understanding! +-------------------------------------------------------------------+ : John Stewart : : Technical/Academic Support Programmer Office (409) 568-1020 : : Stephen F. Austin State University Modem (409) 568-1334 : : Nacogdoches, Tx 75962 : +-------------------------------------------------------------------+ ========================================================================= Date: Mon, 8 Aug 88 18:27:18 PLT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Andrew Vaught <29284843@WSUVM1> Subject: Hiding viruses The solution is simple. Just print data from another sector, or, possibly a small random-number generator. Binary files look all the same.... Does anyone seriously believe that a virus writer is going to bother with such an esoteric scheme to hide their code? We haven't seen any so far. The reason is that your joe blow computer user just doesn't look at his boot sectors very often, and the only reason anyone else would is if strange things started happening. Viruses have to be small to avoid being obvious. If COMMAND.COM suddenly grows by 30k due to all of the CRC foolers and other wild schemes, even joe blow may notice it. On another tack, anyone have any ideas on the possible future of viruses? The other I got ahold of a book called ``Advanced 80386 Programming'' (sorry, author's name is gone). At very least, Intel has designed one heck of a complicated microprocessor. Since the beast is designed specifically for multi-tasking, there are all kinds of wierd things like ``call-gates'' that allow use of privileged subroutines by low-privilege processes, without giving privileges. I suppose a virus could still call the dos's ``FORMAT HARD DISK'' command, but it seems kind of stupid to provide such an easily accessible command in the first place. Andy Vaught <29284843%WSUVM1.bitnet@cunyvm.cuny.edu> ``I'm on the case, can't be fooled, any objection is overruled.'' ========================================================================= Date: Tue, 9 Aug 88 01:48:49 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Loren K Keim -- Lehigh University Subject: Gerbil / Virus Course Well, I was away from my computer for all of two days (my wife is trying to make me cut down) and 200 messages built up on various systems. Thank you for all your responses on the conference, and please keep them coming. First, the Gerbil virus. These viruses have been the source of a lot of confusion over the past few months. I believe someone stated a while back on this list something about an MS-DOS virus that prints little feet across the bottom of the screen and a message that goes along with it. I have not seen hide nor foot of this virus. A friend out at the University of California, however, was able to send me a similar program which they found on someone ELSE's computer system. Its a set of two programs that runs on Vax systems running the VMS operating system. The version I saw was appended at the end of the system login file, so anyone logging in ran the program, unknown to them. This program would count the number of commands a user would type in and after 35 of them (and every multiple thereafter), would call a second program (also written in the DCL command language) that would print very crude "feet" across the bottom of the screen in five lines. They would use a variety of greater than, less than signs and / \ marks. No message was printed. Whether or not this program had a third program which would copy itself into the system login file is unknown to me. I doubt it. It was most likely a prank by someone at that company. But this was the closest thing I could find to the elusive gerbil virus talked about on this system. What I DID find however, was a cute PC "virus" or "bacterium" as I'm told they now call them, that when ran would print a picture of Jerry Pentacoli (I have no idea how to spell that) and a Gerbil jumping from an end-table into him. It then looked for (as do most of these picture viruses) any other disks on the system (including a hard disk C:, D: and so on) and copied itself to them. I would suspect that all of these picture viruses are written by the same person or group of people. They are interesting, but not damaging. Les, Chris, as for a course on viruses, I think that is a bit too specialized for undergraduates, but I would like to see a course given on computer security measures and theories. I don't know whether or not it should be mandatory, because judging by some college's requirements for a BS in computer science, many wouldn't know what computer security WAS much less how to implement protection schemes. Unfortunately, "Computer Security" covers a very broad range of ideas. And perusing the books in our library pertaining to computer security, each has an entirely different subject in them. I'd like to see courses provided to computer science students that overview some of the needs for computer security, including banks, government agencies, the need for secrecy and so on, what computer system administrators need to know, and possibly some protection schemes, how banks are protected, future developements in the field of limited transitivity and limited usefulness, and touching on the problems viruses pose as an advanced way around most protection schemes and how we might slow down or stop their spread. Actually, I think it would be a challenging course to teach... one I wouldn't mind teaching at all. Loren Keim ========================================================================= Date: Tue, 9 Aug 88 08:23:32 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: Forwarded comments on virus education from J.D. Abolins Forwarded from J.D. Abolins: Re: Should computerists be told about computer viruses? I believe the they should be told ENOUGH so they know that hazards exist and that they know what to do to minimize risks. Tell them that there are problem programs out in the world. Tell them about the need for accountability of programs, the need for good backup procedures, and how to recognize a damaged system. This type of instruction shouldn't be viewed as VIRUS PREVENTION, rather it should be given as holistic review of good computing practices. After all, it is not just viruses that cause problems (although their replication makes them particularly troublesome); there are Trojan Horses and genral bug-ridden programs. So many of the practices to protect a system from viruses overlap with preventatives for other problems. One of the big dangers in not mentioning viruses at all is that the "innocent" computerist will face getting hurt without even knowing tht the danger exists. One of the big pitfalls they should know about, after being told simply that replicating malicous code- viruses- do exist, is that programs they have considered to be safe, such as commercial software they have bought, can become an agent of damage if they are not careful in their use of the program. "Borrow-ware", the practice of borrowing and lending out "known to be reliable" programs, can catch the unwary. The copy of QDOS bought by a computerist starts out being safe. But the computerist uses it on different machines and over the useage, the copy of QDOS gets a virus code replicated into it. If the computerist is not even aware of viruses, he/she will have no idea that their "trusted program, bought with their own money" can be the carrier of trouble. Tell them, yes. Tell them just enough to know it is rough world out there and tell them how to minimize their risks. Beyond that, the average computerist need not hear how to make a viruse, their modes of attack, etc. As for the debate about Fred Cohen's mention of viruses causing the virus case at Lehigh, I agree with Ken that the issue is moot. (Anyway, it would have probably someplace just as well without any course on viruses. After all others have mentioned the concept and if Fred Cohen could conceive of the possibility, so can many other people. But enough said.) J.D. Abolins If this message made it OK to VIRUS-L, then TRANSMIT with the SEQ option worked. In that case, Sylvia, you were right. Thank you. Kenneth R. van Wyk Overheard in a Thai restaurant: User Services Senior Consultant Lehigh University Computing Center "I don't know what you're having, Internet: but my nose is running!" BITNET: ========================================================================= Date: Tue, 9 Aug 88 08:30:43 MDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Chris McDonald STEWS-SD 678-2814 Subject: Re: "2600" Quarterly, Summer, 1988 In-Reply-To: Your message of Mon, 1 Aug 88 22:45:00 MDT You may address subscription correspondence to: 2600 Subscription Dept PO Box 752 Middle Island, NY 11953-0099 Yearly Subscription: $15 individual $40 corporate I subscribe to the quarterly--am not on their payroll. Chris McDonald White Sands Missile Range ========================================================================= Date: Tue, 9 Aug 88 09:14:54 CST Reply-To: Virus Discussion List Sender: Virus Discussion List From: Claudia Lynch Subject: Re: Gerbil / Virus Course In-Reply-To: Message of Tue, 9 Aug 88 01:48:49 EDT from Who is Jerry Penticoli? ========================================================================= Date: Tue, 9 Aug 88 14:57:31 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: Re: Gerbil / Virus Course In-Reply-To: Message of Tue, 9 Aug 88 09:14:54 CST from >Who is Jerry Penticoli? He's a local (Philly) tv newscaster who is *alleged* to have a somewhat, er, non-humane association with gerbils. But, please *PLEASE*, lets not get into a discussion of this here! The only possible viruses stemming from any such alleged acts are certainly not computer related... Ken Kenneth R. van Wyk Overheard in a Thai restaurant: User Services Senior Consultant Lehigh University Computing Center "I don't know what you're having, Internet: but my nose is running!" BITNET: ========================================================================= Date: Tue, 9 Aug 88 14:08:00 PDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Ed Sakabu Subject: Re: Re: "2600" Quarterly, Summer, 1988 If you are subscribing for work (i.e. you're a security officer) you may want to subscribe in the name of the company (2600 claims that they will NOT EVER release the names of companies that subscribe). If you subscribe using your own name there is a possibility that you may get on some lists that you don't want to be on (this is PURE SPECULATION and is based on my own paranoia, but being on such a list (i.e. "cracker list") may not be very good if you are a security consultant and are looking for work, the FBI has been known to keep such lists before and I don't think there gona stop now.) --Ed > You may address subscription correspondence to: > > 2600 Subscription Dept > PO Box 752 > Middle Island, NY 11953-0099 > > Yearly Subscription: $15 individual > $40 corporate > > I subscribe to the quarterly--am not on their payroll. > > Chris McDonald > White Sands Missile Range ========================================================================= Date: Tue, 9 Aug 88 23:18:00 MDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: LYPOWY@UNCAMULT Subject: Re: Re: "2600" Quarterly, Summer, 1988 In-Reply-To: Message of 9 Aug 88 15:08 MDT from "Ed Sakabu" Is 2600 magazine anything like the TAP issues of Old?? Greg. ========================================================================= Date: Wed, 10 Aug 88 09:20:00 PDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Ed Sakabu Subject: Re: Re: Re: "2600" Quarterly, Summer, 1988 I think (correct me but please don't flame me if I'm wrong) TAP went under (financially that is) and some of the staff brought it back as 2600. --Ed > Is 2600 magazine anything like the TAP issues of Old?? > > Greg. ========================================================================= Date: Wed, 10 Aug 88 14:03:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: WHMurray@DOCKMASTER.ARPA Subject: "Computers and Security," Virus Supplement The current issue (April?) Volume 7, number 2, of the subject journal has a special supplement on computer viruses. It may be of interest to the readers of this forum. regards, Bill ========================================================================= Date: Wed, 10 Aug 88 18:49:58 CDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Len Levine Subject: Re: Trapping Disk Calls In-Reply-To: Message from "Art Larky" of Aug 2, 88 at 3:28 pm > >You won't catch my virus by watching for DOS calls, because I won't use >them. >... > Command.com is a great place to hide a virus, not only because it has >room for it, but also because it gets executed immediately after your >autoexec, so your chances of catching the virus depend upon what you do >in autoexec. Also, everyone has command.com and everyone uses it all >the time, so it has lots of chances of spreading an infection. Just a slight correction, command.com is executed *before* autoexec.bat + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + | 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, 10 Aug 88 19:00:27 CDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Len Levine Subject: Re: Virii and Screen Output In-Reply-To: Message from "Amanda B Rosen" of Aug 8, 88 at 12:59 (midnight) > >David Slonosky's idea of a virus concealing itself is quite interesting, but >there is a reason I don't think it could work. > >To really hide, the virus would have to remember the code it was overwriting. >Otherwise, finding a chunk of $00s or No-ops in the middle of your code would >be pretty suspicious (unless you're looking at COMMAND.COM :-) > ... >The point is, this virus rapidly grows so complex that it couldn't hide. The >original copy would be huge, and it would have a significant effect on the >system. > not so. There is lots of room, just declare a few disk blocks to be unavailable in the FAT, and use that space. Noone looks to see what happens to the bad block space, even of a floppy. + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + | 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, 10 Aug 88 23:29:00 -0500 Reply-To: Virus Discussion List Sender: Virus Discussion List Comments: converted from NETDATA format at UOFMCC From: Steve Morrison Subject: Re: Trapping Disk Calls In-Reply-To: <428*b1morri@ccu.UManitoba.CA> Can you not adjust your CONFIG.SYS to hide almost anything within your RAM? Stevo ========================================================================= Date: Thu, 11 Aug 88 10:53:08 +0100 Reply-To: Virus Discussion List Sender: Virus Discussion List From: Stefan Parmark Subject: Question about virus attacks I have been reading your discussions with great interest. However, I feel that very little has been said about viruses on VAX-11, Sun and other generally-not-owned-by-private-persons computers. I am writing a report on viruses here at Ellemtel in Sweden. I think it should contain something about the viruses having hit a little larger machines. My report will mostly contain a summation of what has been said about viruses on this and other lists. It will not concentrate on PC viruses and specific PC solutions. Instead it will be about viruses and protections for the *general* micro/mini computer. Of special interest here is the Unix environment, which is used in an increasing number of mini computers today. I would like to know about viruses, which have struck company computers. I will respect that you don't want the name of your company to leak out if you have been hit, but I would like to know what happened. Just tell me it was some other company you can't recall the name of. I don't mind. If you still aren't sure if you dare trust me with virus information, I can let my superiors contact you. I would also like to know what software there is to protect against viruses. So far I have only run across TCELL. Has anyone had any experience with this? When finished, I will make my report available to Kenneth R. van Wyk, so you all can download it. Please e-mail all answers. I appreciate all the help I can get. Stefan Parmark tmpspa@eua4.ericsson.se Ellemtel Sweden ========================================================================= Date: Thu, 11 Aug 88 15:17:45 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Loren K Keim -- Lehigh University Subject: Mainframe Viruses Stephan, We've been doing detailed work on mainframe viruses for some time. Most of the original work on viruses done by Fred Cohen, etc was done on a variety of Unix machines and Vax's if I remember correctly. There have been a few virus attacks on mainframes. One in particular, a banking institution in northern New Jersey was hit only 5 or 6 weeks ago. Their name cannot be released however. The problem with most corporate attacks and mainframe attacks is that they are sworen to secrecy. IBM being hit by the Christmas Tree virus was one publicized virus. Most mainframe security systems are worthless against viruses I am VERY sorry to say. Again, not to plug myself, but Lehigh Valley Innovative Technologies' Innoculator package is available for VM/CMS, VMS, Unix boxes (most including Sun's). And I believe there is another such package out there, but I'l have to check on the name again. It is very hard to attempt to stop virus attacks on mainframes, but we're working on various ways of stopping them. Loren Keim LKK0@LEHIGH ========================================================================= Date: Thu, 11 Aug 88 16:05:32 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "David M. Chess" Subject: Mainframe Viruses and whatnot I hate to be such a nitpicker, but CHRISTMA wasn't really a virus in the usual sense, since it didn't insert itself into any executable files, but just sent itself (CHRISTMA EXEC) around the net. I think the distinction is rather important, since it's Real Easy to write a filter that just zaps anything of the right size called CHRISTMA EXEC, whereas it's typically much harder to deal with a real, spreading, arbitrary-program- altering, virusy virus. (A word that seems to fit CHRISTMA well is "bacterium".) (The hacked FLUSHOT wasn't really a virus, either, as far as I know; it was just a Trojan Horse that did bad things to your system when you ran it. It didn't spread itself. I'd hate to see "virus" come to mean "something that does something bad to something". Let's reserve it for, as Fred Cohen said, "a program that can 'infect' other programs by modifying them to include a possibly evolved copy of itself".) Back to the subject: I think it'd be interesting if Loren (or anyone else) could tell us some of the things that make virus-fighting on mainframes harder than on micros (if I'm reading Loren's item aright). Anything you can tell us without exposing anyone's dirty laundry? DC ========================================================================= Date: Thu, 11 Aug 88 16:59:23 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Loren K Keim -- Lehigh University Subject: Mainframe problems Well Dave, The easiest thing for me to say is "The more complex the machine, the harder it is to protect", but its more than that. A micro, all by itself is easier to protect than a network or than a lot of computers in one room used by many people, and so on. One of the problems with mainframes is the number of users, and the possibility of very remote computer sites accessing the system. Let say, for example, that those using our example mainframe M get onto the system by way of microcomputers. Lets say someone "has it in" for this 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. If a virus "blows up" on a mainframe, realize that we have the possibility of losing data from many users, not just a single disk as is the case with a single micro. The problem, also, is that we cannot just CRC the entire machine. People may be developing, someone is always changing around files, and there are many places for viruses to hide on the system. We have to find a way to stop viruses from spreading on these machines without limiting the machine to those programs "okay'd" by the administrator of M. We have looked at DER one-way-encryption protection of libraries of machines, or creating a shell around the mainframe to "write protect" files, or protecting certain programs and not others, or even limited transitivity of the machine... breaking it down into blocks that users can access certain things but not everyone can get things from everyone else. Its a difficult problem. We don't have the ease of making sure DOS checking all writes before they write and watching for direct writing. With each mainframe, we must check carefully what is changing and whether or not the user wants it to change. Loren ========================================================================= Date: Thu, 11 Aug 88 17:40:43 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Loren K Keim -- Lehigh University Subject: Mainframe Woe's continues One other thing that some collegues of mine just mentioned to me: 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. 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. Loren ========================================================================= Date: Thu, 11 Aug 88 20:52:25 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Joe Sieczkowski Subject: Mainframe I wouldn't consider mainframes "harder" to protect than PC's just "different". A mainframe gives you a lot of advantages that you don't have on a PC. On the other hand, there is greater sharing of resources on mainframes which makes viral spread more dangerous. First of all, a mainframe (or mini for that matter) has a secure Operating System. You cannot address REAL memory and you cannot access the I/O ports directly like on a PC. Moreover, a virus has no more priveledge over the OS than the invocing user. Granted a virus can climb the ladder, but it must do so through ordinary means; ie it can't immediately write itself to the disk, or to the command processor until it has priveledge to do so. So a mainframe virus must link itself to an ordinary executable to be able to get itself into memory, replicate to other executables, and test to see if it has enough priveledge to accomplish its pre-determined task. Of course, depending on the OS, a mainframe virus might be able to modify a users local command processor so as to stay totally active during the entire session (or even after the user logs out). But the virus only has the priveledge of the user. 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! There are ways to use mainframes security features to their maximum advantage to try to prevent the above senario. You could isolate the system from the outside world; however, this is inadvisable since an ordinary user could write the virus anyway. You could isolate the users from one another but this probably wouldn't be advisable especially considering users often need to work together to complete a project. The best method is probably to look for footprints that indicate a possible virus about the system. In a program I wrote a short time ago to protect a UNIX OS I did the following: * Set up a CRC table of system programs (ie those owned by root, bin and uucp) The CRC table can only be modified by root and re-asks for his password during any modification. * sh (the command processor) was modifyied to check the CRC table for system files being executed. If it changed it didn't execute. As a matter of fact it was quarentined and mail was automatically sent to root about it. * A daemon was run in backround to periodically check system files for change. If changed they were quarintined ...especially if the "set-uid" bit was on. This method left users with total freedom while it protected system stuff. There were other smaller features as well and various other optional checks. Joes joes@scarecrow.csee.lehigh.edu ========================================================================= Date: Thu, 11 Aug 88 19:23:00 PDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: SUE@UWAV1.ACS.WASHINGTON.EDU Subject: QUESTION ABOUT MAINFRAME, VMS VIRUS WHERE CAN I GET DETAILS ABOUT MAINFRAME (VMS) VIRUSES?? HOW THEY WORK, PROPAGATE, ETC.? SUE@UWAV1.ACS.WASHINGTON.EDU SUE@TOBY.ACS.WASHINGTON.EDU ========================================================================= Date: Thu, 11 Aug 88 20:32:05 pst Reply-To: Virus Discussion List Sender: Virus Discussion List From: Bill Meyer -- x36039 SIGNOFF VIRUS-L ========================================================================= Date: Fri, 12 Aug 88 09:00:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Joseph M. Beckman" Subject: Re: Mainframe Viruses and whatnot In-Reply-To: Message of 11 Aug 88 16:05 EDT from "David M. Chess" > Christma wasn't really a virus in the usual sense, since it didn't >insert itself into any executable files, ... a real, spreading, >arbitrary-program altering, virusy virus. I suppose the "Lehigh virus" wasn't a virus then, since it didn't insert itself into "arbitrary programs"? Of course, we will also have to excuse the "Brain virus" since it propagated to the boot sector, not an arbitrary program. > ...it's Real Easy to write a filter that just zaps anything of the >right size called CHRISTMA EXEC... Sure! And I can write a filter that zaps Command.Com & zeros out the boot block too! That'll stop those beasties! > Let's reserve it for ... a program that can 'infect' other programs >by modifying them to include a possibly evolved copy of itself. Closer. The question is, what distinguishes an ordinary Trojan Horse from the virus variant? The answer is, the virus has a more-automated distribution mechanism. If I infect WORD PERFECT or WORDSTAR (trademarks of some company) with an ordinary Trojan Horse, it will end up in zillions of places. The distribution, though is at human speeds. Someone has to learn about the package order it, have it shipped, etc. (In the government it is 'bureaucratic speed', an oxymoron). A virus speeds that distribution up by propagating itself electronically. Focusing on "programs" is a little misleading; the distinction between "data" and "programs" in the general sense is very difficult to make cleanly. For instance, the CHRISTMA EXEC existed within each user's VM space. Now VM is just another program, so since the virus existed within it, it had "infected" that user's VM "program." Joseph ========================================================================= Date: Fri, 12 Aug 88 13:07:43 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: me! Jefferson Ogata Subject: What's the latest on the conference thing Hey folks. This list has been pretty quiet lately. What's new? - Jeff Ogata ========================================================================= Date: Fri, 12 Aug 88 16:42:31 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Loren K Keim -- Lehigh University Subject: Conference Notes We have MANY replies in on the virus conference. Right now, we are trying to set upa conference for October 21-23. We are trying to contact possible speakers, and making certain we can get rooms. We will have most of the major details worked ou by the end of the weekend. I'll write about it then. Thank you for all the respones! Loren ========================================================================= Date: Thu, 11 Aug 88 23:53:00 MDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: LYPOWY@UNCAMULT Subject: Re: QUESTION ABOUT MAINFRAME, VMS VIRUS In-Reply-To: Message of 11 Aug 88 20:23 MDT from "SUE at UWAV1.ACS.WASHINGTON.E One of the professors in our faculty here at the U of C wrote a paper oriented more toward mainframes than micros. Here is the biblio for it: Witten, Ian H., Computer (In)security: Infiltrating Open Systems, Abacus (Magazine) Vol. 4, No. 4, (Summer 1987) If you have any questions for Dr. Witten I may be able to pass them on to him, r even give you his E-Mail address. The article covers what a virus cna do, and in fact gives you an idea of how to write one. Greg Lypowy ========================================================================= Date: Sat, 13 Aug 88 09:29:00 MDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Bernie Subject: History Being a new user to this service, I am not too sure yet what has/has not been discussed. Please forgive any repetition. I recently got into a discussion about the origins of trojan horses and viruses. I believe that it was the industry itself which propagated the idea of time bombs and such so as to protect shareware and non copyprotected software. Being a hacker, I don't believe hackers in general are innately evil. My colleague believes that it is the mischievous hacker trying to get at his enemies which propagated this 'wave' of problems. Does anyone know anything in depth about the history of such stuff? The main point is who is to blame! :) BSW ========================================================================= Date: Sat, 13 Aug 88 09:29:00 MDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Bernie Subject: History Being a new user to this service, I am not too sure yet what has/has not been discussed. Please forgive any repetition. I recently got into a discussion about the origins of trojan horses and viruses. I believe that it was the industry itself which propagated the idea of time bombs and such so as to protect shareware and non copyprotected software. Being a hacker, I don't believe hackers in general are innately evil. My colleague believes that it is the mischievous hacker trying to get at his enemies which propagated this 'wave' of problems. Does anyone know anything in depth about the history of such stuff? The main point is who is to blame! :) BSW ========================================================================= Date: Sat, 13 Aug 88 16:18:21 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "David A. Bader" Subject: PK36 and PK361 Here is an interesting set of documents that I found concerning the validity of Phil Katz's archive makers and extractors. The first document concerns the court case between SEA and PK: ------------------------------------------------------------------------ FOR RELEASE ON AUGUST 1, 1988 From: System Enhancement Associates, Inc. (SEA) and PKWARE, Inc. and Phillip W. Katz (PK) August 1, 1988 - Milwaukee, WI In the first known "Shareware" litigation, pending in the local United States District Court, the parties System En- hancement Associates, Inc. (Plaintiff - SEA) and PKWARE, Inc. / Phillip W. Katz (Defendants - PK), after reaching agreement, consented to the entry of the attached Judgment for Plaintiff on Consent. That Judgment was entered by Judge Myron L. Gordon, effective on August 1, 1988. Part of the agreement reached by the parties included a Confidential Cross-License Agreement under which SEA licensed PK for all the ARC compatible programs published by PK during the period beginning with the first release of PKXARC in late 1985 through July 31, 1988 in return for the payment of an agreed upon sum which was not disclosed. Additionally, PK was licensed, for an agreed upon royalty payment, to distribute its existing versions of PK's ARC compatible programs until January 31, 1989, after which PK is not licensed and agreed not to pub- lish or distribute any ARC compatible programs or utilities that process ARC compatible files. In exchange, PK licensed SEA to use its source code for PK's ARC compatible programs. PK agreed to cease any use of SEA's trademark "ARC" and to change the names or marks used with PK's programs to non-confusing designations. The Judgment provided for the standard copyright, trademark and unfair competition injunctive relief for SEA a- gainst PK, as well as damages and litigation expenses to be paid by PK to SEA. Both parties agreed to refrain from any comment concerning the settlement of the disputes, other than the text of this press release. Also, the parties instructed all of their representatives to refrain from any such activity. Any other details of the Cross-License Agreement were agreed to be maintained in confidence and under seal of the Court. In reaching the agreement to dispose of the pending litigation and to settle the disputes that are covered thereby, PK did not admit any fault or wrongdoing. ------------------------------------------------------------------------ The next document is a few memos downloaded from a BBS and deals with problems in PK36: ------------------------------------------------------------------------ ******************* ALERT! WARNING! ALERT ****************************** Downloaded from ACOM I BBS -- HOUSTON, TX 7-14-88 LATEST IMPORTANT NEWS...!!! ---------------------------------- . - Msg # 2339 Dated 07-08-88 01:07:49 Security: 0 - From: PAT FORBES - To: ALL - Re: WARNING !!! PKARC V3.6 Last read at 18:59:36 on 07/08/88 - - WARNING !!! There is something fishy going on with PKARC Version 3.6. - It is doing some weird things in memory that it should not be... - BBS-Chess also plays in memory... vectors... interupts... etc and it - will flat abort if it sees something weird... it does whenever PKARC - version 3.6 is run. Previous versions of PKARC are ok... its just 3.6 - that goes places in memory it should not be... - - We are calling the authors on 7-8-88 to confirm that there is such a - version. This may be more than just an "unarcer". It may be an honest - mistake... a bug... but be safe... not sorry!!! Remove it and use the - older version until we can get in touch with the author. - - This "messin in memory" was confirmed by a sysop in Georgia and another - in Southern California... both discovered the same thing. PKARC 3.6 is - Going places in memory... and leaving things in memory that it should not - be ... - -------------------------------------------------------- - Msg # 2344 Dated 07-08-88 16:41:09 Security: 0 - From: PAT FORBES - To: SARA JONES - Re: (R)THANKS Last read at 19:01:15 on 07/08/88 - - I talked to the author of PKARC today. It is confirmed... he is doing - some weird things in memory to.... "keep people from seeing his code". - He said he did not think it was necessary to put everything back to - normal when the code exited.... he now sees the err of his ways... - A lesson here.... mess with DOS all you want but.... put EVERYTHING back - to normal (the way it was) when you are done... - - Expect a new release very shortly but for the time.... DO NOT USE - version 3.6 unless you don't mind an occasional reboot or system lockup. - Use version 3.5 or less... - - ------------------------------------------------------------------------ Ok, and finally, this next session is some kind of warning chat that was also available: ------------------------------------------------------------------------ These are some interesting tidbits I discovered on GT-Net. Read 'em and form your own opinions.... Dave Williams 07/20/88 ############################################################################### #### first, some bulletins from Rick Kunz' NW Pacific GT-Net... ############################################################################### 7-15 Pulled PK3.6 and put a short version of the .COM files from PK 3.5 back up, temporarily, until bug fix is out. GT14.02 files will bw up in GENERAL file dir shortly; new install program also. 7-12 ===> The following was received from a fellow GT Sysop today; a word to the wise-- I did reinstall PK version 3.5 on both systems. --- --- --- --- I hope you have gotten the word by now, but in case you haven't there is A BIG PROBLEM with PKXARC/PKARC Ver. 3.6...has to do with the way Katz modifies vectors ( and then doesn't reset them)....it has caused me some real pain with BBSCHESS and some other programs.....just wanted you to know! ############################################################################### ##### and in CHAT mode with the sysop...... ############################################################################### @DDDDDDDDDDDDDDDDDDDDDDDY 3 GT NET/NODE 007/000 3 @DDDDDDDDDDCDDDDDDDDDDDDY @DDDDDDDDDDDDDDDDDDDDDY 59 Minutes left. Enter command (? for help): p ................ Dave Williams, Sorry if I broke in-- you're chatting with Rick Kunz! Yep...! Sorry to bother you..what's this about PK36? PK36 grabs some ints and doesn't let go of them. It's an attempt to foil hackers, to avoid another PKX35B35 debacle. The problem occurs as far as I know, only if you access PK36 from a shell, such as in viewarc utils, etc. It causes some real unpredictable results with those. No wonder!!!!! I run shelled out of Qmodem or PC-Write half the time, and I've been having some radical hard disk problems - CRC errors all over the place. I thought it was just the disk dying, but it started getting bad when I got PK36. Haven't lost anything, but it sure makes some torturous moises. Well, go back to 3.5, if you don't have it around, I put the .COM files in a little arc in the general directory. I think I have them laying around on an odd disk - I can get 'em locally if I need 'em. Sort of a surprise, finding problems in PKARC...... For sure! Phil has his share of problems lately, the 3.6 thing, I noticed it affecting serial communications on both machines as well as some frazzed disk stuff, and a couple days after reverting to 3.5, my highspeed xfers are back again. So if anyone gripes abouut file xfers, see if they've been using 3.6. Yeah. !?! OK, thanks a lot. I'll let ya go.... Sure-have a good one! ############################################################################### #### and finally, some dumps of the SOFTWARE echo on GT-Net ############################################################################### FILE SECTION: #1 - GENERAL - Miscellany, open access, ALLFILE.ARC Msg Base: #28 - SOFTWARE TECH; Chris Smith's GT Echo Msg No: 473. 7-08-88 19:59.01 From: Fred Horner To: Rusty Stone Subject: PK36.EXE I have unpacked and use pk36 with no trouble, however I have seen reports that it may have a problem with using int 3 and not releasing it when its through. Might want to stick with the 35 ver until we know for sure. .ORIGIN: 001/001 - THE PROGRAMMER'S WORKSHOP - SEND MAIL TO 001/003. Msg Base: #28 - SOFTWARE TECH; Chris Smith's GT Echo Msg No: 505. 7-13-88 23:09.18 From: Mike Schmieg To: Rusty Stone Subject: PK36.EXE Based on the latest report, just do away with PK36 files and return to 3.5. Wait until the 3.61 release comes out. I've already found problems with the board with 3.6. .ORIGIN: 006/006 - THE NOOK-CINCINNATI,OHIO (GEOFF MANDEVILLE, SYSOP) Msg Base: #28 - SOFTWARE TECH; Chris Smith's GT Echo Msg No: 511. 7-15-88 18:35.28 From: James Gaas To: Tony Locicero Subject: PK36.EXE Have you seen the recent "warnings" about using PK36? Seems it will cause lock ups. The current suggestion is to go back to PKX35A35 until the author releases PK36.1 .ORIGIN: 001/025 - J & J'S CASTLE - JAMES GAAS - HOUSTON << (713) 988-1922 >> Msg Base: #28 - SOFTWARE TECH; Chris Smith's GT Echo Msg No: 516. 7-16-88 8:39.43 From: John Dunham To: Mike Schmieg Subject: PK36.EXE I had problems with cross-linked clusters and damaged fat's. I started backing out programs from the lastest obtained. When I backed out PK36.EXE, the above disk problems stopped. I am now staying on 3.5 until a bug fix for 3.6 is released. .ORIGIN: 031/000 - THE LONG BEACH GT - LONG BEACH, CA - (213) 422-3986 Msg Base: #28 - SOFTWARE TECH; Chris Smith's GT Echo Msg No: 517. 7-17-88 13:32.29 From: Tony Locicero To: James Gaas Subject: PK36.EXE Have seen no problem on my system related to the PK36. Seems to affect only a few programs such as BBSCHESS as described by the author. Since I don't run this program and since EVERYTHING that I use seem to run well with it, I will continue to use it. It seems to run well on a wide variety of my machines on a wide variety of applications. Might be specific to that one application. .ORIGIN: 001/009 - THE BLACK ORCHID - HOUSTON, TX. - (713) 527-8719 Msg Base: #28 - SOFTWARE TECH; Chris Smith's GT Echo Msg No: 522. 7-17-88 6:36.22 From: Rusty Stone To: Fred Horner Subject: PK36.EXE Fred, Thanks for the warning. I will watch for more information on the Pk36 problem. Rusty .ORIGIN: 001/018 - SYSTEM ENVIRONMENT - SYSOP RUSTY STONE - 713/672-8318 ------------------------------------------------------------------------ I have heard many discussions on local BBS's as to whether or not PKXXX is real or a trojan/virus/whatever... But hopefully this will shed some more light on the situation with PK's software. Incidentally, I have a copy of PK361.EXE, and all the filenames have been changed from PK36.EXE (obviously due to the litigation with SEA). David A. Bader DAB3@LEHIGH ========================================================================= Date: Sat, 13 Aug 88 16:49:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: WHMurray@DOCKMASTER.ARPA Subject: Re: History In-Reply-To: Message of 13 Aug 88 11:29 EDT from Bernie >My colleague believes that it is the mischievous hacker trying to >get at his enemies which propagated this 'wave' of problems. Does anyone >know anything in depth about the history of such stuff? The main point is >who is to blame! I would argue that that is not the main point at all. This is not the six o'clock news, or even TV. There are no good guys or bad guys here. There is nothing to be gained by finger pointing. "We have seen the enemy and he is us." Viruses and Trojan Horses are simply special cases of lies. Under most circumstances, lying is considered bad form, even immoral. In the case of these programs, they are destructive of other peoples resources and of the community's trust. That seems adequate reason to condemn them and the behavior of their authors in perpetrating them. However, with the current spate of PC viruses, it seems reasonable to say that they belong in the category of mischief, rather than that of evil. While their authors could predict how they would behave in a given system, there is evidence to suggest that they did not know how, or even if, they would spread, or how destructive they might be. Indeed, it seems clear that these acts were not motivated by vengeance or even greed. Rather, they were motivated, to the extent that they were motivated at all, by idle curiousity. The essentially gratuitous nature of these acts is mitigated only by the fact that the perpetrators were also ignorant of how much damage they might do. Some have suggested intellectual curiousity as a motive. However, while it is possible to write a clever virus, one need not be clever to do so. Writing a destructive virus is not a demonstration of skill. Perhaps it was simply the novelty of the thing. Or it may be, that having assayed the power, the perpetrators were not sufficiently mature to resist the temptation to use it. And the rest of us, those of us with an interest in the honest labelling and orderly behavior of programs, what has motivated us? Clearly that has been some greed and fear peddling. There has been a certain amount of grudging admiration. Certainly there has been identification and sympathy, for we know that the biggest difference between them and us is that they coded theirs' and let them go. We have reacted from incredulity (What do you mean, it could take over my system?!), and from hubris ("I have a 100% defense against viruses!" (when what he really meant was he could protect your hard disk from updates). Mostly we have reacted from fear; not the rational fear of a destructive and mindless lie, but rather the fear that someone might try to keep the truth from us. Not the fear of the damage that could be done by a virus, but the fear that in dealing with them someone else might infringe some cherished privilege (What do you mean, I can't require my students to write a virus?!). We have reacted from almost every motive but enlightened self-interest. So you see, the point is not who is to blame. There is plenty of blame to go around. Please do not start pointing fingers. The issue is not where have we been, but where do we go. The novelty is gone forever. It is now clear how much damage can be done. It only remains to be seen whether or not we can resist the temptation of the power and bring ourselve to censure and sanction those who cannot. 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: 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 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