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 AA19269; Wed, 6 Jun 90 09:38:32 -0400 Received: from SEI.CMU.EDU by g.sei.cmu.edu (5.61/2.5) id AA02414; Wed, 6 Jun 90 09:38:26 -0400 Received: from nsfnet-relay.ac.uk by sei.cmu.edu (5.61/2.3) id AA12478; Wed, 6 Jun 90 09:37:24 -0400 Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK via Janet with NIFTP id aa15358; 6 Jun 90 13:56 BST From: Anthony Appleyard To: KRVW <@NSFnet-Relay.AC.UK:KRVW@sei.cmu.edu> Date: Tue, 05 Jun 90 14:09:16 BST Message-Id: <$TGVGDBVHCQBN at UMPA> Subject: Virus-L vol 0 issue #0629 Virus-L Digest Wed, 29 Jun 88, Volume 0 : Issue #0629 Today's Topics Re: Hide in plain view Forwarded comments on freedom of speech Forwarded comments on worms from Joseph Beckman Re: Hide in plain view Re:Re: NO constructive viruses please Re:Re: NO constructive viruses please re:re: hide in plain sight re: Hide in plain view Missing the forest for the trees in your way Re: say NO to constructive viruses :-) Re:Re: NO constructive viruses please OS/2 Re: Re:Re: NO constructive viruses please ------------------------------ Date: Wed, 29 Jun 88 05:43:57 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: me! Jefferson Ogata Subject: Re: Hide in plain view > From: Woody > Jefferson Ogata says that "it is difficult to hide... in plain view". > I'm not convinced. If I recieve source for a neato-keeno chess > program, say 10K lines, I'm going to compile and run it once or twice > before I've completed my examination of it. (Bad hygiene, perhaps, but > I'm a sloppy human.) Once I've been hit, *if* I detect it before > someone borrows a program of mine, I still have to search through ALL > of my pascal sources to find the virus. Its in plain view, but there > is just too much to examine, and it is too difficult to know which > source is contaminated and which is not. > Comments? Yup. You misunderstand me. I didn't say it would be hard to PUT a virus in source code; I said it would be hard to HIDE it there. The virus you describe would be pretty easy to track down, once you found out about it. And there are simple ways of protecting yourself from such viruses. One is never to run new code as yourself; maintain a separate login for code under test. As for figuring out which source is contaminated, that's easy -- Unix main- tains last access date information for each file; just look and see how recently it's been changed. Or use grep to find the virus, and write a sed script to fix the change automatically. Besides, most program trading over Arpanet is traceable. If you get a viral program from someone, you know who it was; people don't just send you programs all the time without being asked. And if you send a program to someone, you've probably tried it, and would most likely know if it were a virus. - Jeff -------------------- Date: Wed, 29 Jun 88 08:32:32 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: Forwarded comments on freedom of speech This just in from ALLES@YALEMED. (Bill - VIRUS-L won't distribute files which have been submitted, you must send submissions in via MAIL. Ken) - -------------------- Begin included file ------------------------- >On the issue of laws against even benign viruses, the freedom of >speech guarantee in the US constitution may be invoked by some >authors in defense of their actions. This is probably a weak >defense, since viruses are propagated on private machines. However, >a benevolent virus on a public network may be protected. The constitution may, indeed, be invoked in defense of even *benign* viruses, based upon freedom of speech, or even freedom of the press. However, this is not a case of freedom of speech (or even freedom of the press). Viruses CAN AND DO cause "physical" harm to others, which is where the law of ANY land normally draws the line. Things that would be covered under freedom of speech/the press can not cuase harm or do damage to others if they choose not to listen or read...viruses offer you no choice. >We need to be able to talk about viruses and create them. Granted we need to be able to talk about viruses. But when you say we need to be able to create them, one wonders about your objectivity. * NO ONE * "needs" to be able to create a virus. To recognize and deal with one, yes. But to create one, * NEVER*. Bill Alles Kenneth R. van Wyk Hobbes: Wow, buried treasure right User Services Senior Consultant where you said it'd be! A Lehigh University Computing Center wallet full of money! Internet: Calvin: Yeah, it's Dad's. I buried it BITNET: here last week! -------------------- Date: Wed, 29 Jun 88 08:34:44 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: Forwarded comments on worms from Joseph Beckman Date: Tue, 28 Jun 88 16:14 EDT From: "Joseph M. Beckman" Subject: Worms The definitive paper on "Worms" was published in the Communications of the ACM, Vol. 25, No. 3 March 1982 by John F. Shoch & Jon A. Hupp, both then of Xerox Palo Alto Research Center (PARC). They define and describe worms as: "a program or computation that can move from machine to machine, harnassing resources as needed, and replicating itself when necessary." "...programs which span machine boundaries or distributed computations." "The programs on individual computers are described as segments...segments in a worm remain in communication with each other..." They also described a problem they had with their worm: "We...speculated that a copy of the program became corrupted...so that the initialization code would not run properly...some...worm segments were...desperately trying to replicate; every machine they touched, however, would crash. ...we had included an emergency escape within the worm mechanism. Using an independent control program, we were able to inject a very special packet into the network, whose sole job was to tell every running worm to stop no matter what else it was doing. All worm behavior ceased." This is a very good paper they talks about the different actions they had the worms do while executing. I hope you will be stimulated by the notes and intrigued by what I have left out to read it. Please note that this was not designed to be malicious. Personally, I feel that classifying code as a virus or worm based on the perception of maliciousness is misleading. By so doing, you are "divining" the intent of the creator (always a dangerous thing to do). Joseph Kenneth R. van Wyk Hobbes: Wow, buried treasure right User Services Senior Consultant where you said it'd be! A Lehigh University Computing Center wallet full of money! Internet: Calvin: Yeah, it's Dad's. I buried it BITNET: here last week! -------------------- Date: Wed, 29 Jun 88 10:16:42 CDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Sam Huntsman Subject: Re: Hide in plain view In-Reply-To: Message of Tue, 28 Jun 88 21:50:00 EDT from >If I receive a Neato-keeno chess program of 10k lines The best place to hide a tree is in a forest. (\|# Sam Huntsman #|/) SH06078@UAFSYSB | | /\ |=== Computer Science Major | | /==\ |=== University of Arkansas \__/ | | | At Fayetteville Founder and President of the Sam Huntsman Institute of Technology... (better known by it's initials...) "If we took the bones out it wouldn't be 'Crunchy' now would it..." -------------------- Date: Wed, 29 Jun 88 17:56:00 URZ Reply-To: Virus Discussion List Sender: Virus Discussion List From: BG0@DHDURZ2 Subject: Re:Re: NO constructive viruses please Jeff (OGATA@UMDD) writes: >> From: BG0@DHDURZ2 > >> I don't agree that there are "constructive viruses". All things >> these viruses are supposed to do can be done (more easily) by >> using normal programs or extensions of the operating system (e.g. >> data compression,...). The fact is that a virus has to *alter* >> existing executables even if it is a "good" virus. I don't want >> other persons to alter my programs (via viruses) because they may >> cause side effects on my software. I something went wrong with my >> programs *I* want to be responsable for the errors... >> Some people say: 'The virus should ask the user if he wants his >> program to be infected by this "good" virus.' I don't want to be >> asked silly questions all the time either. > >The constructive virus I have been talking about (which was mentioned >initially by someone else, I forget whom) is a method of updating an >operating system. It can NOT be done "more easily" by using "normal >programs", whatever that means. The only side effects are an updated >version of the operating system. If this wreaks havoc in your software, >the operating system was not upward compatible. It only asks you "silly >questions" when you warm boot from a disk whose version of the >operating system hasn't been updated. > O.K. Let's consider that the only task of the virus is to update the OS. (You never said if this "update virus" should infect all executables or only the OS itself. I suppose you mean the first because in the other case you have no virus but just a propagating trojan horse or an expansion of the operating system itself.) Some remarks on doing this job with a virus: . The time between two releases of an OS is typically 6 - 12 month, right? Is it neccessary to write a virus and to infect all execu- tables just to update the OS? Just note the disk space: If the virus is 1000 bytes in size and you have 200 executables on your hard disk, you waste 200,000 bytes !! You can also use a "normal program": Write a memory-resident program (you may call it UPDATE) that looks for operating systems with a lower version number on all accessable drives and performs an update if you want an update. . If it is a real virus (infects all executables) it *CAN* cause havoc on my software because it alters my program. >> By the way: . If you buy a software package and you have problems >> with it, I think the software house can refuse to >> give support if the software is altered by an (even) >> "good" virus. > >The virus under discussion is DISTRIBUTED by the software house. > But what happens if you buy software from another software house and *their* software gets infected by the virus?? > >> I do believe the tale of "constructive viruses" is spread by virus >> programmers who want to legitimate their doing. > >What are you trying to say? Hmm? > Oh, I thought my remark was obvious: You have to write viruses (on a virtual -simulated- machine) to learn how viruses really work and how they propagate and HOW TO DEFEAT THEM. From my point of view this should be the only motivation for people to write viruses. But if people say: "Oh, lets use viruses to do this or that useful work", I can only reply: You are playing with things you *CANT* control because your creation is out of your reach if it spreads on other systems. So how can you say that your virus will not cause harm on one of these other systems you never seen before? Thats why I dont trust in some scientists in biology. They say: 'Bacteriae can cause harm on people. But we can change the DNA/RNA sequence of these so they will "eat" plastic and this is a very useful thing because it helps us to get rid of the plastic pollution.' Did they never thought what harm these creations can cause on systems (natural systems) different from their laboratory system?? (This might be a bad analogy but thats what I mean.) All the best to you, Bernd. -------------------- Date: Wed, 29 Jun 88 18:20:00 URZ Reply-To: Virus Discussion List Sender: Virus Discussion List From: BG0@DHDURZ2 Subject: Re:Re: NO constructive viruses please Jeff (OGATA@UMDD) writes: >> From: BG0@DHDURZ2 > >> I don't agree that there are "constructive viruses". All things >> these viruses are supposed to do can be done (more easily) by >> using normal programs or extensions of the operating system (e.g. >> data compression,...). The fact is that a virus has to *alter* >> existing executables even if it is a "good" virus. I don't want >> other persons to alter my programs (via viruses) because they may >> cause side effects on my software. I something went wrong with my >> programs *I* want to be responsable for the errors... >> Some people say: 'The virus should ask the user if he wants his >> program to be infected by this "good" virus.' I don't want to be >> asked silly questions all the time either. > >The constructive virus I have been talking about (which was mentioned >initially by someone else, I forget whom) is a method of updating an >operating system. It can NOT be done "more easily" by using "normal >programs", whatever that means. The only side effects are an updated >version of the operating system. If this wreaks havoc in your software, >the operating system was not upward compatible. It only asks you "silly >questions" when you warm boot from a disk whose version of the >operating system hasn't been updated. > O.K. Let's consider that the only task of the virus is to update the OS. (You never said if this "update virus" should infect all executables or only the OS itself. I suppose you mean the first because in the other case you have no virus but just a propagating trojan horse or an expansion of the operating system itself.) Some remarks on doing this job with a virus: . The time between two releases of an OS is typically 6 - 12 month, right? Is it neccessary to write a virus and to infect all execu- tables just to update the OS? Just note the disk space: If the virus is 1000 bytes in size and you have 200 executables on your hard disk, you waste 200,000 bytes !! You can also use a "normal program": Write a memory-resident program (you may call it UPDATE) that looks for operating systems with a lower version number on all accessable drives and performs an update if you want an update. . If it is a real virus (infects all executables) it *CAN* cause havoc on my software because it alters my program. >> By the way: . If you buy a software package and you have problems >> with it, I think the software house can refuse to >> give support if the software is altered by an (even) >> "good" virus. > >The virus under discussion is DISTRIBUTED by the software house. > But what happens if you buy software from another software house and *their* software gets infected by the virus?? > >> I do believe the tale of "constructive viruses" is spread by virus >> programmers who want to legitimate their doing. > >What are you trying to say? Hmm? > Oh, I thought my remark was obvious: You have to write viruses (on a virtual -simulated- machine) to learn how viruses really work and how they propagate and HOW TO DEFEAT THEM. From my point of view this should be the only motivation for people to write viruses. But if people say: "Oh, lets use viruses to do this or that useful work", I can only reply: You are playing with things you *CANT* control because your creation is out of your reach if it spreads on other systems. So how can you say that your virus will not cause harm on one of these other systems you never seen before? Thats why I dont trust in some scientists in biology. They say: 'Bacteriae can cause harm on people. But we can change the DNA/RNA sequence of these so they will "eat" plastic and this is a very useful thing because it helps us to get rid of the plastic pollution.' Did they never thought what harm these creations can cause on systems (natural systems) different from their laboratory system?? (This might be a bad analogy but thats what I mean.) All the best to you, Bernd. -------------------- Date: Wed, 29 Jun 88 13:42:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Woody Subject: re:re: hide in plain sight >From: me! Jefferson Ogata > >> From: Woody > >> Jefferson Ogata says that "it is difficult to hide...in plain view". >> I'm not convinced. If I recieve source for a neato-keeno chess >> program, say 10K lines, I'm going to compile and run it once or twice >> before I've completed my examination of it. (Bad hygiene, perhaps, but >> I'm a sloppy human.) Once I've been hit, *if* I detect it before >> someone borrows a program of mine, I still have to search through ALL >> of my pascal sources to find the virus. Its in plain view, but there >> is just too much to examine, and it is too difficult to know which >> source is contaminated and which is not. > >> Comments? > >Yup. You misunderstand me. I didn't say it would be hard to PUT >a virus in source code; I said it would be hard to HIDE it there. >The virus you describe would be pretty easy to track down, once you >found out about it. And there are simple ways of protecting >yourself from such viruses. One is never to run new code as >yourself; maintain a separate login for code under test. As for >figuring out which source is contaminated, that's easy -- Unix main- >tains last access date information for each file; just look and see >how recently it's been changed. Or use grep to find the virus, >and write a sed script to fix the change automatically. > >Besides, most program trading over Arpanet is traceable. If you >get a viral program from someone, you know who it was; people don't >just send you programs all the time without being asked. And if >you send a program to someone, you've probably tried it, and would >most likely know if it were a virus. > Sorry, I wasn't clear. Hide, here, is in a relative sense. And my penultimate sentence in the quoted paragraph is clearly wrong. I suppose what really matters here is rate of infection. The virus modifies a procedure to insert itself into other code. Once the virus is detected, well, as you point out, it is fairly easy to eradicate. > As for >figuring out which source is contaminated, that's easy -- Unix main- >tains last access date information for each file; just look and see >how recently it's been changed. Or use grep to find the virus, >and write a sed script to fix the change automatically. > Again, I'm not convinced that a last-access date would serve to identify all the files contaminated - we'd have to know exactly when the infection occurred (yeah, files three years old are ok, but what about a month?) and you'd also end up looking at a lot of recent but probably clean files. However, grep would detect it (unless the virus itself randomized its typography...) and if grep didn't a utility of some sort would. In particular, all that we've hashed out before on using a variety of CRC polynomial schemes to detect changes apply here. However, without suspicion, the means of detection are (1) noticing the source itself has been changed [-and this is what I really meant by "hiding"] (2) noticing the program is malfunctioning [problematic in a large program, and only detected during the act of transmission] (3) being told by a collegue that you've infected them. If I don't suspect the existence of the virus, (1) is doubtful, unless the virus is unlucky or I happen to be especially awake that day. Since the source code has been modified to create a trojan, (2) suffers from the usual problems of detection. (3) is the most likely - nets like this will put us on our guard ("We found a source-altering virus in Pascal programs from the Northeast United States... check for source recieved from that area..."). So, unless an infestation becomes widespread, it will take some time for a site to detect the virus. This is where rate of transmission is important. If you recieve programs from only one source, things are different. Then > >Besides, most program trading over Arpanet is traceable. If you >get a viral program from someone, you know who it was; people don't >just send you programs all the time without being asked... > is clearly useful: we didn't have the virus before, we do now, ergo it came from the one source. But if we get code from many sources, and are not able to detect that the code contains a trojan type virus immediately after the transmission of the contaminated source, the virus may infest itself into several "recieved source" copies. So you might not know exactly who sent you this viral program. If history is any indication, the number of transmitted code files and number of locations a particular site is recieving code from will increase. So the virus has a potentially rapid spread. The place where I see this really happening is among the students. Drew is a BITNET node. Here, we have something called the "Computer Initiative" - nothing exceptional, just that each undergrad has a computer bundled into the price of tuition. Last year, it included a modem. And last year, from about 6PM to 2AM, our modem lines were saturated with undergrads talking to undergrads via BITNET. This year, we are initiating something called the "Knowledge Initiative" - in part, this means that every undergrad, staff, and faculty memeber has a direct line to our mainframe, and thence to the nets. I would expect a very large fraction of the student body to investigate BITNET, and use its communication facilities. Some reasonable fraction of them will take introductory Pascal, and in discussing it with their friends, recieve source code from many different sites. Jefferson Ogata notes > And there are simple ways of protecting >yourself from such viruses. One is never to run new code as >yourself; maintain a separate login for code under test.[...] Well, I don't have multiple accounts for running test code - I make do with a complicated directory structure. The students certainly don't, and are unlikely to take even the simplest hygienic measures. The student body is a large breeding ground for viruses. So, it is my opinion, that virii are going to be a natural part of computer life, just as they are a natural part of biological life. As our connectivity increases, their rates of transmission will increase. As our sophistication in detecting them in time and space increases, the virii will be forced to evolve into smarter forms. Our best weapons are the watchfulness of certain of our members, and information groups like this forum. woody WWEAVER@DREW :disclaimer - Drew's "Knowledge Initiative" is a great idea; I wish I had had a hand in it.: -------------------- Date: Wed, 29 Jun 88 14:57:28 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Mark W. Eichin" Subject: re: Hide in plain view In-Reply-To: me! Jefferson Ogata's message of Wed, 29 Jun 88 05:43:57 EDT <8806291736.AA06360@ATHENA.MIT.EDU> JO>From: me! Jefferson Ogata JO>One is never to run new code as JO>yourself; maintain a separate login for code under test. As for JO>figuring out which source is contaminated, that's easy -- Unix main- JO>tains last access date information for each file; just look and see JO>how recently it's been changed. A system was described at last week's USENIX conference whereby non-"trusted" programs could only write (or read?) files explicitly mentioned on their command lines. Not perfect, but a good heuristic... also certain rules about /tmp being ok as long as you didn't write over some existing file. Of course, this wouldn't apply to micros (without a distinction between user and supervisor mode, you *CAN'T* make them use your driver; without a powerful user mode and decent drivers, you *CAN'T* make them use your machine/OS :-) Mark Eichin SIPB Member & Project Athena ``Watchmaker'' -------------------- Date: Wed, 29 Jun 88 17:22:24 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: me! Jefferson Ogata Subject: Missing the forest for the trees in your way Actually, the BEST place to hide a tree is probably the far side of the moon. At least for the next few years. Woody: I agree such a virus is potentially harmful. But whether it has been done has nothing to do with Unix. My point was simply that it is more difficult to distribute effective viruses via source code, for a number of reasons, including the fact that it's source, and the fact that they could probably be traced. I regard these factors as significant in the apparent lack of viruses in Unix systems. As for tracing the virus you were talking about, it is still possible. Since most Unix mainframes have frequent backups, it would be a simple enough (tedious but simple) problem to find out when the infection occurred. Then the original culprit could be detected and the virus traced to its source. On the other hand, nothing is as easy as it sounds. - Jeff -------------------- Date: Wed, 29 Jun 88 17:03:05 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: me! Jefferson Ogata Subject: Re: say NO to constructive viruses :-) >From: BG0@DHDURZ2 >O.K. Let's consider that the only task of the virus is to update the OS. >(You never said if this "update virus" should infect all executables >or only the OS itself. I suppose you mean the first because in the >other case you have no virus but just a propagating trojan horse or an >expansion of the operating system itself.) What? First of all, I mean the second, because that's all the virus is supposed to do. Second of all, the OS IS an executable, or you wouldn't be able to use it; therefore, I don't understand why you think this wouldn't qualify as a virus. I don't know of any viruses that infect ALL executables. >Some remarks on doing this job with a virus: > . The time between two releases of an OS is typically 6 - 12 month, > right? Is it neccessary to write a virus and to infect all execu- > tables just to update the OS? Just note the disk space: If the > virus is 1000 bytes in size and you have 200 executables on your > hard disk, you waste 200,000 bytes !! > You can also use a "normal program": Write a memory-resident > program (you may call it UPDATE) that looks for operating systems > with a lower version number on all accessable drives and performs > an update if you want an update. Sure, you can write a memory resident program. Then the difference is that the program is no longer a part of the operating system, so you have to run it explicitly. It STILL changes your operating system. I no longer understand what your objection to the viral update system was in the first place. Here is a re-post of your initial remarks: >I don't agree that there are "constructive viruses". All things >these viruses are supposed to do can be done (more easily) by >using normal programs or extensions of the operating system (e.g. >data compression,...). The fact is that a virus has to *alter* >existing executables even if it is a "good" virus. I don't want >other persons to alter my programs (via viruses) because they may >cause side effects on my software. I something went wrong with my >programs *I* want to be responsable for the errors... >Some people say: 'The virus should ask the user if he wants his >program to be infected by this "good" virus.' I don't want to be >asked silly questions all the time either. >By the way: . If you buy a software package and you have problems > with it, I think the software house can refuse to > give support if the software is altered by an (even) > "good" virus. > . At least here in Germany it is a crime (Para. 303a,b > StGB - computer sabotage) to spread a (constructive) > virus *BECAUSE* it alters existing programs. >I do believe the tale of "constructive viruses" is spread by virus >programmers who want to legitimate their doing. If you're objecting to altering the OS, that will be done by your memory-resident program as well. Neither will alter other existing executables. If you don't like silly questions, will your UPDATE program prompt you before it updates old versions of the OS? What objections did you have to the viral approach that are invalid in the memory-resident approach. And I must emphasize that the viral approach is "more easily" done, since you don't have to run any other programs explicitly. > . If it is a real virus (infects all executables) it *CAN* cause > havoc on my software because it alters my program. It IS a real virus, and it doesn't alter your program; it alters theirs. >But what happens if you buy software from another software house and >*their* software gets infected by the virus?? How? Wouldn't any update method be just as dangerous? >Oh, I thought my remark was obvious: You have to write viruses (on >a virtual -simulated- machine) to learn how viruses really work >and how they propagate and HOW TO DEFEAT THEM. From my point of >view this should be the only motivation for people to write viruses. >But if people say: "Oh, lets use viruses to do this or that useful >work", I can only reply: You are playing with things you *CANT* >control because your creation is out of your reach if it spreads >on other systems. So how can you say that your virus will not cause >harm on one of these other systems you never seen before? Thats why I >dont trust in some scientists in biology. They say: 'Bacteriae >can cause harm on people. But we can change the DNA/RNA sequence >of these so they will "eat" plastic and this is a very useful >thing because it helps us to get rid of the plastic pollution.' >Did they never thought what harm these creations can cause on >systems (natural systems) different from their laboratory system?? >(This might be a bad analogy but thats what I mean.) I see. I didn't get any of that from your initial remark. I think most virus-fighting tactics currently under investigation are working towards eradicating existing viruses. I see no need to create other new viruses for this work. And viruses CAN be used for useful work; the existence of the virus under discussion is proof of that. Viruses are programs like any program. There is no reason why such programs should be any more suspect than others as far as potential for damage goes. If you write a program carefully enough and test it appropriately to make sure it does ONLY what you WANT it to do, fine. These programs are fairly simple, so that's not much of a problem. Bacteria are a very different subject; they can exist in billions of environments. Computer viruses have a very clearly defined area of possible propagation. As for genetic engineers, yes they HAVE thought about the possible harm such experiments could cause. So did the people who designed the hydrogen bomb. And people who designed cars and airplanes and suspension bridges. There are people who believe (I'm not one of them) that the AIDS virus was the result of a genetic engineering experiment targeted for biological warfare, which was released accidentally (?). (See Frank Zappa's album "Thing Fish" for a discussion of this topic.) If this is true, it's pretty bad news for the scientific community. But consider a world where trash is no longer a problem, because we have ways of disposing of it easily, and using the by-products. Incidentally, the experiments I've heard of use bacteria that are NOT harmful to people. - Jeff -------------------- Date: Wed, 29 Jun 88 22:12:26 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: David.Slonosky@QueensU.CA Subject: Re:Re: NO constructive viruses please In-Reply-To: The fact is that you CAN easily tailor biological virii and such to have zero chance of suriving outside of a very restricted environment. Whether you can do so with a computer virus is another question to which I do not have the answer. -------------------- Date: Wed, 29 Jun 88 22:14:33 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: David.Slonosky@QueensU.CA Subject: OS/2 In the latest (July 88) issue of BYTE I see that the "Extended Edition" of OS/2 is being released this month. I quote from Rich Malloy: "The ultimate goal of the EE is to allow you to access several databases at several locations at the same time, and to have the whole process appear as if you were browsing through a single database on your own hard disk." He then goes on to say that this is at this time only a "Planned Enhancement" which will be released at some indeterminate future date. Boy, what an environment for virus writers... -------------------- Date: Wed, 29 Jun 88 12:31:16 PDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: S John Banner Subject: Re: Re:Re: NO constructive viruses please In-Reply-To: Message of Wed, 29 Jun 88 17:56:00 URZ from >Jeff (OGATA@UMDD) writes: >>> From: BG0@DHDURZ2 >> >>> I don't agree that there are "constructive viruses". All things >>> these viruses are supposed to do can be done (more easily) by >>> using normal programs or extensions of the operating system (e.g. >> >>The constructive virus I have been talking about (which was mentioned >>initially by someone else, I forget whom) is a method of updating an >>operating system. It can NOT be done "more easily" by using "normal >O.K. Let's consider that the only task of the virus is to update the OS. >(You never said if this "update virus" should infect all executables >or only the OS itself. I suppose you mean the first because in the >other case you have no virus but just a propagating trojan horse or an >expansion of the operating system itself.) Either way (the virus infecting all ececutables, or just the OS), the virus is still a virus. The thing that makes it so is the way in which it spreads, NOT specificly what it does (though in many cases, the two are pretty much the same thing). Further, I would disagree, with your assumption that the virus would have to infect all the executables, as you always have to run the OS at some time, so that should be sufficent. If the virus were to check the version of the OS on any disk it comes in contact with, and only infect bootable disks, with a lesser version of the OS, if the user wants it, then every thing would go just fine, and all you should have to worry about is accidentally updating a copy of the OS that you didn't want to update, or OS version incompatablities. Further more, if I were writing such a beast (and no, I am not), I would also include in the disk format some way to inform the virus never to update a given disk. >Some remarks on doing this job with a virus: > > . The time between two releases of an OS is typically 6 - 12 month, > right? Is it neccessary to write a virus and to infect all execu- > tables just to update the OS? Just note the disk space: If the > virus is 1000 bytes in size and you have 200 executables on your > hard disk, you waste 200,000 bytes !! > You can also use a "normal program": Write a memory-resident > program (you may call it UPDATE) that looks for operating systems > with a lower version number on all accessable drives and performs > an update if you want an update. The first half of that, I have addressed above, and the second, is pretty much the same thing as what I am talking about, execept that it is started automagicly by the OS (much as if you were to call the TSR you suggest from your AUTOEXEC.BAT. Then if you also have your virus kill older versions of itself, as new versions of the OS come along (ie. reusing the space used by the old one), we would both be using much the same program, but just invoking it differently... > > . If it is a real virus (infects all executables) it *CAN* cause ~~~~~~~~~~~~~~~~~~~~~~~~~ > havoc on my software because it alters my program. And why can't a virus be selective?? Their biological counterparts are... (sort of anyhow.... :-) > >>> By the way: . If you buy a software package and you have problems >>> with it, I think the software house can refuse to >>> give support if the software is altered by an (even) >>> "good" virus. >> >>The virus under discussion is DISTRIBUTED by the software house. >> >But what happens if you buy software from another software house and >*their* software gets infected by the virus?? But in my scenario, it only affects THEIR software... > From my point of >view this should be the only motivation for people to write viruses. >But if people say: "Oh, lets use viruses to do this or that useful >work", I can only reply: You are playing with things you *CANT* >control because your creation is out of your reach if it spreads >on other systems. So how can you say that your virus will not cause But if you are satisfied you can control it (and by writting the operating system, you are accepting the responsibility for the users data anyhow, in a round about way), what then?? This argument is like the argument against the "GOTO". There are uses. Granted they are few and far between, and if you are not carefull, they can be dangerous, but they DO have their uses. >All the best to you, >Bernd. And all the best to you too. I do hope I havn't offended anyone inadvertantly, I was not intending to if I did, Have Fun, sjb. -------------------- *** end of Virus-L issue ***