========================================================================= Date: Wed, 22 Jun 88 08:44:39 EST Reply-To: Virus Discussion List Sender: Virus Discussion List From: Neil Goldman I have seen the term 'worm' defined as: "originally developed by systems programmers to tap unused network resources to run large computer programs. The worm would search the network for idle computing resources and use them to execute a program in small segments. Built in mechanisms would be responsible for maintaining the worm, finding free machines, and replicating the program. Worms can tie up all the computing resources on a network and essentially shut it down. A worm is normally activated every time the system is booted up." - from COMPUTER SECURITY, March/April, 1988 Question: Is anyone aware of this type of virus in a PC environment? Neil Goldman NG44SPEL@MIAMIU.BITNET Ernst & Whinney National Computer Audit Group ========================================================================= Date: Wed, 22 Jun 88 09:23:53 PDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: S John Banner In-Reply-To: Message of Wed, 22 Jun 88 08:44:39 EST from >I have seen the term 'worm' defined as: "originally developed by systems >programmers to tap unused network resources to run large computer programs. >The worm would search the network for idle computing resources and use them to >execute a program in small segments. Built in mechanisms would be responsible >for maintaining the worm, finding free machines, and replicating the program. >Worms can tie up all the computing resources on a network and essentially shut >it down. A worm is normally activated every time the system is booted up." > > - from COMPUTER SECURITY, March/April, 1988 > >Question: Is anyone aware of this type of virus in a PC environment? > >Neil Goldman NG44SPEL@MIAMIU.BITNET >Ernst & Whinney >National Computer Audit Group What would be the point? As I understand it, the worm is supposed to use otherwise unused computing resources to do a time consuming computation, AND return the result when you are done. In a PC environment however, how would the programmer ever be assured of getting the result back (and for that matter, keep getting the results back in various states of completion for the next twenty years, due to copies, etc). You may want to note here, that I cannot understand the idea of writing a virus (I can understand logic bombs, worms, etc., but viri are just plain malignant, and I can't understand that one at all), where as a worm actually has (can potentially have, and don't tell me viri can too, I read the discussion a week or two back on the virus that updated the OS on the disks, and I loved the idea), a constructive purpose, so my view may be just a touch slanted... :-). sjb. ========================================================================= Date: Wed, 22 Jun 88 12:12:41 CDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Len Levine Subject: Re: your mail In-Reply-To: Message from "S John Banner" of Jun 22, 88 at 9:23 am > > You may want to note here, that I cannot understand the idea of >writing a virus (I can understand logic bombs, worms, etc., but viri are >just plain malignant, and I can't understand that one at all), where as >a worm actually has (can potentially have, and don't tell me viri can >too, I read the discussion a week or two back on the virus that updated >the OS on the disks, and I loved the idea), a constructive purpose, so >my view may be just a touch slanted... :-). > > sjb. > there is NO good reason to use a virus to update a disk/disks. Maybe I want to keep a copy of the earlier version of whatever, such a virus would update or change stuff for me without my permission. Maybe the update is worse than the original. Why must I change? len@evax.milw.wisc.edu ========================================================================= Date: Wed, 22 Jun 88 14:47:30 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: me! Jefferson Ogata Subject: constructive viruses Maybe you don't recall the details of the constructive virus sjb was referring to. It contained self-replicating code and patches for the operating system it ran on. When it encountered an old version of the operating system, it would execute the patches and install itself on the fixed version. I believe it asked the user before altering the boot disk. I, for one, hate updating software on all the disks it might be living on, and I love the idea of software that updates itself. - Jeff Ogata ========================================================================= Date: Wed, 22 Jun 88 14:00:00 CDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Jeff Hayward Subject: RE: worms [ description of a worm omitted ] >Question: Is anyone aware of this type of virus in a PC environment? There was a paper by Metcalfe and Boggs of Xerox PARC written back in the early days of Ethernet that described a worm program they built using ALTOS pcs. In the experiments they describe, willing PC owners left their systems running a memory diagnostic at night. The worm program could recognize such systems, and acquire them via a network bootstrap. One incarnation of the worm used its' segments to break the computation of a graphic image into pieces, compute the image in a parallel fashion, and display it at some location. All was very above board, useful, and non-destructive. I believe they even found some unexpected benefits, such as locating malfunctioning hardware by the exercise given it at night. If I can find the paper I'll post a reference. Jeff Hayward The University of Houston ========================================================================= Date: Wed, 22 Jun 88 17:10:15 EST Reply-To: Virus Discussion List Sender: Virus Discussion List From: Neil Goldman The reason I posted the request for information on PC-based worms is that I am preparing a paper on viruses for distribution to our computer audit executives. It will provide them with the background to help clients when they ask them about viruses. The glossary will include a definition of 'worm'. S. John Banner writes that a worm is designed to use otherwise unused computing resources. I view Computer Security's definition as implying that a worm would monopolize resources, thereby slowing down the entire system's throughput. I again ask for comment, with this in mind. Neil A. Goldman Ernst & Whinney National Computer Audit Group ========================================================================= Date: Wed, 22 Jun 88 13:06:00 CST Reply-To: Virus Discussion List Sender: Virus Discussion List From: LOWEY@SASK Subject: delete me from mailing list please I tried sending SIGN-OFF VIRUSL to the list server, but I'm still receiving the messages. Please remove my name from the list. Kevin Lowey ========================================================================= Date: Wed, 22 Jun 88 12:58:23 CST Reply-To: Virus Discussion List Sender: Virus Discussion List From: David Camp In-Reply-To: Message of Wed, 22 Jun 88 08:44:39 EST from >I have seen the term 'worm' defined as: "originally developed by systems >programmers to tap unused network resources to run large computer programs. >The worm would search the network for idle computing resources and use them to >execute a program in small segments. Built in mechanisms would be responsible >for maintaining the worm, finding free machines, and replicating the program. >Worms can tie up all the computing resources on a network and essentially shut >it down. A worm is normally activated every time the system is booted up." > > - from COMPUTER SECURITY, March/April, 1988 > >Question: Is anyone aware of this type of virus in a PC environment? > >Neil Goldman NG44SPEL@MIAMIU.BITNET >Ernst & Whinney >National Computer Audit Group I have heard of something along this line. I went to a seminar about it, but I cannot remember the name of the researcher or his university. Perhaps I could be persuaded to look it up if anyone is interested. Anyway, the system is a replacement for Ultrix on Vax minicomputers. A specialized kernel allows jobs to be submitted for remote processing. The site in question has many Vaxes, which all look the same at the machine language level. Any machine that has been idle for 15 minutes is made to run one of the submitted jobs. When the user starts to use the Vax again, the job is breakpointed and swapped out, to be restarted when another processor becomes free. They have supposedly recovered hundreds of hours of computer time per month with this system. -David- *----------------------------------------------------------------------* | (314) 362-3635 Mr. David J. Camp | | Room 1108D ^ Division of Biostatistics, Box 8067 | | 706 South Euclid < * > Washington University Medical School | | v 660 South Euclid | | david@wubios.wustl.edu Saint Louis, MO 63110 | *----------------------------------------------------------------------* ========================================================================= Date: Wed, 22 Jun 88 21:18:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Jim Shaffer, Jr." Subject: RE: delete me from mailing list please >I tried sending SIGN-OFF VIRUSL to the list server, but I'm still >receiving the messages. Please remove my name from the list. Since the list owner is very active on this list, he'll probably remove you. However, for future reference the command is SIGNOFF VIRUS-L. You should have received some sort of error message from ListServ, though. Please note that I am not in charge of the list, nor the server. I'm merely supplying information. ========================================================================= Date: Wed, 22 Jun 88 16:11:26 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Mark W. Eichin" Subject: Are Tandy 1??? vulnerable? I just saw over someone's shoulder an ad for a Tandy 1000HX (I think...) with one of the features being "MSDOS in ROM". Does anyone know if this is done in such a way that makes the Tandy machines invulnerable to many viruses, or does (for example) COMMAND.COM still come off of floppy disk? Mark Eichin SIPB Member & Project Athena ``Watchmaker'' ========================================================================= Date: Thu, 23 Jun 88 08:42:38 EST Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Neil Goldman (216) 861-5000" >QI just saw over someone's shoulder an ad for a Tandy 1000HX (I >think...) with one of the features being "MSDOS in ROM". Does anyone >know if this is done in such a way that makes the Tandy machines >invulnerable to many viruses, or does (for example) COMMAND.COM still >come off of floppy disk? > > Mark Eichin > > SIPB Member & Project Athena ``Watchmaker'' What would happen when a new verions of DOS is released? Perhaps a replacement board? Sounds expensive. ========================================================================= Date: Thu, 23 Jun 88 09:20:00 CDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: GREENY Subject: re: constructive viruses as long as the virus is not harmful, and its only function in life is to update old copies of software *AND* it requests my specific permission before doing so, then it seems like a fantastic idea to me. Perhaps such a virus could have a specified life...i.e. If they can wake up at a specific time (like a time bomb..) then why not die after a specific time as well, say six months or so, basing this on the assumption that all of the software has been updated. Or failing the scheduled time of destruction, how aobut a Destruct option? I firmly believe that viruses can be used constructively, both in human bioengineering, and on computers as well...All that needs to be done is for some of the immature computer jerks to start living by the medical communitys ethical standards....(yes I know, the unattainable utopia :-> ) bye for now but not for long... Greeny Bitnet: miss026@ecncdc Internet: miss026%ecncdc.bitnet@cunyvm.cuny.edu Disclaimer: I didn't do it, whatever it was, unless it was good? Agreed?! ========================================================================= Date: Thu, 23 Jun 88 10:53:19 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Joe McMahon In-Reply-To: Message of Wed, 22 Jun 88 17:10:15 EST from >...a worm is designed to use otherwise *unused* computing resources... Italics are mine. If the worm is designed to truly use unused resources, one of the things it would have to do to be "friendly" would be automatic load checking. If it found it was actually cutting into someone's time, it would delete that segment of itself. --- Joe M. ========================================================================= Date: Thu, 23 Jun 88 08:10:24 PST Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Tim Streater (415) 926-2743" Subject: Byte Magazine (July 1988). If you look in this comic you find a 2-page Toshiba ad, in particular for the T1000 which has MS-DOS in ROM. Very handy for travelling to have it boot up immediately (one less floppy to lose or spill gin on). Of perhaps more relevance to the list in the same mag is an expose written by Jerry Pournells about viruses and vaccines, a couple of pages long (P. 197). Quite a cogent and well written summary. Nothing we don't already know I suspect but useful for the computer-literate who may only have seen accounts in the popular press. Cliff Stoll gave a talk at SLAC yesterday, entitled "What to feed a Trojan Horse", the same I think as he gave at Decus last December. At that time he held 1000 or so people spellbound and definitely raised the conciousness of those people about the problem. He told the story of a grad student who had lost several months of his work because a hacker had changed ONE STATEMENT of his program, giving pi a value of 6.0 instead of 3.1415.... (Cliff was credited with months of patient work to unmask the Chaos hackers). ========================================================================= Date: Thu, 23 Jun 88 12:37:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: WHMurray@DOCKMASTER.ARPA Subject: Re: Are Tandy 1??? vulnerable? In-Reply-To: Message of 22 Jun 88 16:11 EDT from "Mark W. Eichin" >Are Tandy 1??? vulnerable? In general, the more fixed the media, the more difficult to infect. Therefore, copies of the operating system on ROM will be more difficult to infect than copies stored in other media. However, making the operating system more difficult to infect does not make the machine immune. Perpetrators of viruses are attracted to the operating system in general, and COMMAND.COM in particular, because it it is an easy solution to the problem of getting their code executed. However, there are a number of solutions to that problem. Therefore, the answer to your question is that yes, Tandy 1??? are vulnerable, but perhaps marginally less so to viruses that are specific to COMMAND.COM. 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: Thu, 23 Jun 88 14:24:47 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: me! Jefferson Ogata Subject: MSDOS in ROM Replacement board? More likely replacement ROMs. - Jeff ========================================================================= Date: Thu, 23 Jun 88 20:51:00 N Reply-To: Virus Discussion List Sender: Virus Discussion List From: DEGROOT@HWALHW5 Subject: Don't trust CRC as a virus-indication Subject: CRC as a virus-indicator. Don't trust CRC-calculation or parity-calculations as a virus-indicator! It is very easy to change a file or program in such a way that the CRC or parity of the changed file remains the same. Tel. +31-8370- .KeesdeGroot (DEGROOT@HWALHW50.BITNET) o\/o THERE AINT NO (8)3557/ Wageningen Agricultural University [] SUCH THING AS 4030 Computer-centre, the Netherlands .==. A FREE LUNCH! X25: PSI%(+204)18370060638::DEGROOT DISCLAIMER: My opinions are my own alone and do not represent any official position of my employer. - if you go too far to the east, you find yourself in the west .. - ========================================================================= Date: Thu, 23 Jun 88 16:15:04 CDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Mark R. Williamson" Subject: Re: Don't trust CRC as a virus-indication In-Reply-To: Message of Thu, 23 Jun 88 20:51:00 N from >Subject: CRC as a virus-indicator. > >Don't trust CRC-calculation or parity-calculations as a virus-indicator! >It is very easy to change a file or program in such a way that the CRC or >parity of the changed file remains the same. True, if the changer knows what polynomial is being used for the CRC. However, use of two or more independent polynomials should make it much more difficult. The more independent virus checkers with different polynomials there are, the harder it will be for the virus builders. Note: The above is an unverified assertion. ========================================================================= Date: Thu, 23 Jun 88 17:51:46 CST Reply-To: Virus Discussion List Sender: Virus Discussion List From: David Camp Subject: Re: Are Tandy 1??? vulnerable? In-Reply-To: Message of Wed, 22 Jun 88 16:11:26 EDT from >I just saw over someone's shoulder an ad for a Tandy 1000HX (I >think...) with one of the features being "MSDOS in ROM". Does anyone >know if this is done in such a way that makes the Tandy machines >invulnerable to many viruses, or does (for example) COMMAND.COM still >come off of floppy disk? If not, I would never buy such a machine. One could not take advantage of upgrades to Dos. I suppose it may allow either the Rom version or a diskette version, which would be okay. That would speed up booting (when you do not need the later versions). I wonder if all the commands on the Dos disk are in Rom too. Maybe they were just referring to the normal Rom-Bios, in which case their advertisement may be misleading. -David- > > Mark Eichin > > SIPB Member & Project Athena ``Watchmaker'' ========================================================================= Date: Thu, 23 Jun 88 17:38:27 PST Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Tim Streater (415) 926-2743" Subject: Dos in ROM The T1000 (from Toshiba) has everything in ROM (the whole OS), as well as all the standard commands. In fact, it has a ROM-disk (the A-disk as I recall) as well that you can DIR and see all the normal files you would see when DIR-ing any standard system disk. This frees up your floppy on a one-drive machine to be all data. I think it keeps COMMAND.COM in CMOS or something. You can also boot from floppy if you really wish to. ========================================================================= Date: Thu, 23 Jun 88 22:53:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Woody Subject: re: Re: Don't trust CRC as a virus-indication Mark R. Williamson writes >>Subject: CRC as a virus-indicator. >> >>Don't trust CRC-calculation or parity-calculations as a virus-indicator! >>It is very easy to change a file or program in such a way that the CRC or >>parity of the changed file remains the same. > >True, if the changer knows what polynomial is being used for the CRC. >However, use of two or more independent polynomials should make it much >more difficult. The more independent virus checkers with different >polynomials there are, the harder it will be for the virus builders. > >Note: The above is an unverified assertion. This has all been hashed out once in the logs. See them for a verification. ========================================================================= Date: Thu, 23 Jun 88 19:45:14 PLT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Andrew Vaught <29284843@WSUVM1> Subject: Operating System in ROM The operating system in ROM? Boy, Microsoft had better get the OS right the first time, as bug fixes would be somewhat difficult. Actually, Tandy's Color Computer has a 3-Level ROM BASIC/DOS. The first level is a bare-bones BASIC interpreter, the second level adds many features to BASIC (graphics, sound, etc) and the third level adds Disk commands and file management (also in ROM). Each of these levels is another ROM to plug in. How is this possible? Bare-bones BASIC defines a whole slough of vectors in RAM that are initialized to RETurns. These vectors are placed in stategic routines (like character input/output, parsing) so that higher levels can reset these vectors to their own handlers. Another thing about the Coco is that is possible to switch off the ROM and use the RAM underneath-- this can be used to make radical changes to the operating system, or possible to use a totally different operating system like OS-9 or FLEX. Upgrading a ROM-based system is possible. The key thing that makes virus transmission difficult is the lack of bootstrapping-- the virus does not have a sure way of getting into the machine in the first place- the operator has to specifically execute the infected program. Andy ========================================================================= Date: Fri, 24 Jun 88 10:07:00 URZ Reply-To: Virus Discussion List Sender: Virus Discussion List From: BG0@DHDURZ2 Subject: VM/CMS viruses Hi folks, some of you may think that writing viruses for a IBM mainframe running VM/CMS requires access to the mainframe for testing the code. Failed!! A potential virus-writer has (at least) two possibilities to develop VM viruses at his PC at home: . Buy a XT/AT/370 computer (price approx. $5000). Throw away the VM/PC operating system IBM offers for this system. Get (means *steel*) a copy of VM/SP 4.0 (or even 5.0) and put it onto your own system (This really works: I *konw* a person who did exactly this!!). Copy the ASMH and all MACLIBs from the mainframe and develop you own VM virus. ========================================================================= Date: Fri, 24 Jun 88 10:13:00 URZ Reply-To: Virus Discussion List Sender: Virus Discussion List From: BG0@DHDURZ2 Subject: VM/CMS viruses (cont.) ( Sorry that this message was split but I hit the wrong key...) . Get the (ShareWare) package called PC370 (from PC-SIG disk#402) written by Don Higgins (a former IBM'er? He wrote a lot of macros for the IBM/370 system as I found out when I looked at the MACLIBs available at our mainframe). Expand the program to handle macro-expansion and adapt all macros you need for the virus to run under MS-DOS. Develop your virus. Of course the first option is the better one - all you need is to buy a XT/AT/370 and to steel a VM/CMS to develop a virus that can cause *MUCH MORE* harm than PC viruses. How can we face this problem ???? All the best, Bernd. ========================================================================= Date: Fri, 24 Jun 88 08:15:59 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: OS in ROM The idea of putting the operating system (and perhaps other important executables) in ROM is interesting, although not a new one. I saw a product a while back for IBM PC (or compats) that would allow the user to do exactly that - burn a ROM with whatever file(s) (s)he wishes, and use them as if they were coming from a floppy disk. I can't remember the name of the product, but I recall that it came in a couple of different capacity configurations of approx. 360k up to about 1/2 Meg. This idea would appear to be functionally equivalent to what Disk Defender does - recall that Disk Defender is a commercial product that allows the user to physically lock part or all of his/her hard disk from all write attempts. In all of these instances, there are a couple things that we must remember. First, a virus need not limit itself to infecting the operating system; it could easily infect any executable file. Second, if there is a way for the user to update the software in the write-protected storage, then there *is* a way for a virus to get there as well. With Disk Defender, for example, there is a switch which toggles the write protection. During the time that you're updating any software in the read-only portion of the disk, a virus could conceivably be copied as well. In the case of Tandy's ROM DOS (if this is the case), only Tandy, or a person with access to a ROM burner, would be able to alter the contents of the ROM. This could be seen as good and bad, for obvious reasons. I'd see a product like a ROM disk as being useful primarily for its speed and convenience because, unlike a RAM disk, the software is always there. It ought not be viewed as a sole virus protection scheme due to the fact that other files may be infected. It probably does, however, reduce the chance of becoming infected somewhat. The Brain virus would probably have a real tough time getting onto the ROM... :-) Ken Kenneth R. van Wyk Calvin: When I take a bath, I always User Services Senior Consultant put my rubber ducky in the Lehigh University Computing Center water first. Internet: Hobbes: For companionship? BITNET: Calvin: No, to test for sharks! ========================================================================= Date: Fri, 24 Jun 88 10:28:36 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "David M. Chess" Subject: Viruses and COMMAND.COM Various contributors have talked about having the operating system in ROM, and how this might help deter viruses. Remember, though, that most viruses don't live in the operating system at all! The Lehigh virus (that started all this discussion) does, but none of the other PC-DOS/MS-DOS viruses that I know of do. They live either in the boot records of floppies, or in normal executable files (COM and EXE). DC ========================================================================= Date: Fri, 24 Jun 88 10:23:01 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "David M. Chess" Subject: VM/CMS viruses Bernd Fix asks > How can we face this problem ???? I think the answer is "about the same way we're facing the problem for microcomputers". That is, identify the executable objects in the VM/CMS environment, and write programs that do the best we can to detect unauthorized changes in them. Since the typical VM/CMS machine is a bit faster than the typical micro, a good CRC-check (preferably with a nice long user-chosen polynomial) of every vulnerable executable becomes a more attractive option. The outline of a virus-detector that I suggested above could easily be modified for VM/CMS. The main difficulty that I see is that there's no counterpart to keeping the checker, and the database, in a locked file cabinet between runs. Perhaps keep them DES encrypted instead? (And of course re-IPL and "ACC ( NOPROF" before using the detector.) Viruses on mainframes are not very different in kind from viruses on micros (somewhat oversimplified statement offered as a basis for discussion!). DC ========================================================================= Date: Fri, 24 Jun 88 08:18:13 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Stephen SSM Clark In response to Mr. Goldman's inquiry on definition of worm.... The National Computer Security Center, in its poster 86-3, defines worm as: "Worm" or "Virus" - A self propogating computer program which, in addition to performing a desired function, causes a malicious side effect. ========================================================================= Date: Fri, 24 Jun 88 15:30:19 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: David.Slonosky@QueensU.CA Subject: ROM BIOS and CHK4BOMB Message-Id: 153:David Slonosky/QueensU/CA,"",CA From: David Slonosky/QueensU/CA,"",CA To: Subject: ROM BIOS and CHK4BOMB This probably will demonstrate my lack of knowledge about DOS more than anything, but here goes...I used CHK4BOMB on a file I received from a friend which draws a picture of a naked female on the screen. It is called MISS-DV.COM. CHK4BOMB gave the message that the program uses ROM BIOS routines and should not be run until I consulted an expert. Is there any reason that a program which supposedly uses a digitized image (from 5 data files labelled SCR0...SCR4.SCR) would need to access ROM BIOS? The program also lists the BBSs from which you can supposedly get more. I know the Macintosh has a ROM toolbox which users can access to draw graphics, and I was just wondering whether DOS has the same sort of setup. (P.S. I am getting Peter Norton's books on MS/PC-DOS and Assembly language so I won't have to ask questions like this any more!) ========================================================================= Date: Fri, 24 Jun 88 16:43:00 LCL Reply-To: Virus Discussion List Sender: Virus Discussion List From: Michael Wagner +49 228 8199645 Subject: Re: VM/SP Release 5 doesn't RECEIVE hidden files; Rats. I ran out of time today and didn't get to send you this file. If it will still be helpful monday, send me a note and I'll do it then. Greetings Michael ========================================================================= Date: Sat, 25 Jun 88 05:11:44 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: me! Jefferson Ogata Subject: DOS in ROM et al. As for infecting boot sectors, that IS infecting the DOS, since the DOS is normally loaded off the boot tracks. It's really not much harder to send out a ROM chip set update than it is to send out floppies. Really. So I don't think DOSes in ROMs are any kind of problem as far as updates and bug fixes go; that is, any more problem than MS-DOS computers already inflict by having BIOS in ROM -- a primitive and annoying feature. Anybody out there ever use CP/M? BIOS gets loaded with OS off boot tracks. This allows you to FIX your BIOS if you don't like it. And boy have I ever disliked some BIOSes in the past. - Jeff ========================================================================= Date: Fri, 24 Jun 88 14:20:44 CDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Len Levine Subject: Re: constructive viruses In-Reply-To: Message from "me! Jefferson Ogata" of Jun 22, 88 at 2:47 pm > >Maybe you don't recall the details of the constructive virus sjb was >referring to. It contained self-replicating code and patches for the >... >boot disk. I, for one, hate updating software on all the disks it might >be living on, and I love the idea of software that updates itself. > >- Jeff Ogata > so would we all, until something failed and we would change our ideas with GREAT suddenness and gusto. - Len Levine ========================================================================= Date: Fri, 24 Jun 88 14:32:08 CDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Len Levine Subject: Re: Don't trust CRC as a virus-indication In-Reply-To: Message from "Mark R. Williamson" of Jun 23, 88 at 4:15 pm > >>Subject: CRC as a virus-indicator. >> >>Don't trust CRC-calculation or parity-calculations as a virus-indicator! >>It is very easy to change a file or program in such a way that the CRC or >>parity of the changed file remains the same. > >True, if the changer knows what polynomial is being used for the CRC. >However, use of two or more independent polynomials should make it much >more difficult. The more independent virus checkers with different >polynomials there are, the harder it will be for the virus builders. > >Note: The above is an unverified assertion. > It truly works. The use of a user-chosen polynomial will make the defeat of the virus very likely. There is no way for the writer of the virus to know what polynomial the user is working with, and therefore no way to know just what to put in his code to compromise the calculation. As long as we agree to disagree, that is to all use arbitrary polynomials, there is good chance of catching this sort of virus. I recently (april?) posted a package called filetest that ran CRC on selected files. I can permit the user to enter his/her own CRC formula and can also check the boot block of the default disk. This does correctly find changes in any desired exec or com files, or the system files. It should be effective, but only reports after the fact. Any takers? len levine len@evax.milw.wisc.edu ========================================================================= Date: Thu, 23 Jun 88 16:42:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: WHMurray@DOCKMASTER.ARPA Subject: re: constructive viruses In-Reply-To: Message of 23 Jun 88 10:20 EDT from GREENY >as long as the virus is not harmful, and its only function in life is >to update old copies of software *AND* it requests my specific >permission before doing so, then it seems like a fantastic idea to me. Be careful what you ask for; you might get it. 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: Thu, 23 Jun 88 18:31:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: WHMurray@DOCKMASTER.ARPA Subject: Authentication of programs I have just received a new program from RSA Data Security, Inc. The following note was attached: TO: MAILSAFE COMMAND LINE Users FROM: RSA Data Security Inc. SUBJECT: Authentication of MSCL executable program DATE: 11 May 1988 In order to insure protection from viruses and integrity of data we have added a Digital Signature to the end of MSCL.EXE, the MAILSAFE COMMAND LINE executable program. The appended signature does not interfere in any way with the loading or execution of the MSCL program and therefore need not be removed in order to use the product. The signature was produced using the RSADATA7 private key and should be easily verifiable using the RSADATA7 public key that was included with your standard MAILSAFE product. If you are using an older version of MAILSAFE or you do not have access to this public key please contact RSA Data Security for a copy. To verify the authenticity of the MAILSAFE COMMAND LINE executable program MSCL.EXE, simply verify the appended signature using the VERIFY option in MAILSAFE COMMAND LINE or the standard MAILSAFE product. If you have not already done so, you should CERTIFY the RSADATA7 public key in order to consider the signature VALID and CERTIFIED. If, after certifying the RSADATA7 pubilc key, the signature on the end of the file MSCL.EXE is not VALID and CERTIFIED, do not use the MAILSAFE COMMAND LINE product and contact RSA Data Security Inc. for further assistance. [end of attachment] The seal is computed by encrypting the file under the Data Encryption Standard, taking the 128 bit residue and encrypting that under the private key. There has not yet been sufficient time since the big bang to find another file of that length, that will do anything at all as a program and yield the same 128 bit DES residue, much less anything in particular. While this mechanism cannot protect you from accepting a virus from a trusted source, it will permit you to know exactly where it came from. Incidentally, RSA is negotiating with some INTERNET committee to make their product standard and available on the net. 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: Mon, 27 Jun 88 15:50:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Woody Subject: Tamper proof packaging\ I found this on an old USENET digest (dealing with the macintosh). If has some interesting comments about commercial firms preventing the dissemination of viruses and bootleg versions of their products. ---- < forwarded message begins here > --- From: letovsky-stanley@yale.UUCP Subject: Viruses and Tamper-Proof Packaging Date: 19 May 88 15:57:46 GMT Organization: (none) >From: Stanley Letovsky Re: Atul Butte's proposal for "tamper-proof packaging" for software to prevent dissemination of software viruses (Comp.sys.mac Sun, 08 May 88): Butte proposes a variation on the one-way encryption functions of public key cryptography schemes which could encrypt software in a way that ensures that the software actually came straight from the vendor. He also suggests that the decryption key could somehow be provided along with the encrypted software. His proposal is interesting, and seems viable in its overall framework, but one detail is problematic. One cannot distribute the decryption key with the encrypted software: any evil hacker could create such a package, encrypting virus-infected software and supplying his own key. The decryption keys must be publicly posted in such a way that the consumer could have absolute confidence that they belong to a reputable firm, while the firm is responsible for ensuring that they alone know how to encrypt for their publicly posted decryption key. Incidentally, Butte's scheme would seem to have implications for preventing software bootlegging. The vendor could supply the decryption key only to customers with proof of purchase. Bootleggers would have to risk virus infection. Vendors might even be motivated to distribute infected bootleg copies around the marketplace, so as to heighten demand for the genuine article. Of course, they could do that even without tamper-proof packaging... Stan Letovsky letovsky@yale.edu David Littman littman-david@yale.edu ---- < forwarded message ends here > ---- I find Letovsky and Littman's final paragraph rather interesting. Reminiscent of recent SF literature! woody WWEAVER@DREW ========================================================================= Date: Mon, 27 Jun 88 17:10:18 CST Reply-To: Virus Discussion List Sender: Virus Discussion List From: David Camp Subject: Re: constructive viruses In-Reply-To: Message of Fri, 24 Jun 88 14:20:44 CDT from >> >>Maybe you don't recall the details of the constructive virus sjb was >>referring to. It contained self-replicating code and patches for the >>... >>boot disk. I, for one, hate updating software on all the disks it might >>be living on, and I love the idea of software that updates itself. >> >>- Jeff Ogata >> > >so would we all, until something failed and we would change our ideas >with GREAT suddenness and gusto. > >- Len Levine > > Sometimes I have reason to use an old version of Dos. Not only would I not want it to be automatically replaced, but I would not want it in Rom, either. -David- ========================================================================= Date: Mon, 27 Jun 88 19:15:48 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: David.Slonosky@QueensU.CA Subject: OS/2 and virii Assuming OS/2 is released, does anyone have a feeling for whether multitasking will have an enhanced impact of the viruses? That is, the virus in your WordPerfect program sees the Microsoft Windows program and enters it then goes dormant until April 1, 1992... ========================================================================= Date: Tue, 28 Jun 88 01:54:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Woody Subject: re: OS/2 and virii David Slonosky writes >Assuming OS/2 is released, does anyone have a feeling for whether >multitasking will have an enhanced impact of the viruses? That is, >the virus in your WordPerfect program sees the Microsoft Windows >program and enters it then goes dormant until April 1, 1992... My feeling is that it will enhance the transmission of virii. I've been using the quasi-multitasking environment of Multifinder for the mac for some time now, and even though I'm using floppies, the mac is rarely shut off. This means that extra CPU time can be stolen from processes to other, unauthorized processes. Hey, personally, there are a couple of worms (not the destructive kind) I'd like to be running -- and on the vaxes at work I burn about 40 cpu-hours a day on my state space searches. Anyway, as someone on virus-l has already pointed out (I think in reference to the amiga multitasking environment) when you have extra CPU time running around more-or-less undetectibly, a virus suddenly has the resources to do incredible CRC computations or the like. The advantage is not 'goes dormant until April 1, 1992'; you can do that today with a counter. But multitasking means the environment has 24 CPU-hours resource per day to play with, and if the virus steals just 1% of that it is enough to for the virus to be quite clever. What it seems to boil down to is this: virii are a fact of life. If we are going to detect them and prevent their transmission, we have to observe them in either time or space. If you use a hard disk environment, without some sophisticated data verification processes (maybe a DAEMON that records changes to data?) it is not easy to detect the virii in space. With multitasking, it is not easy to detect the virii in time. So, yes, expect more ubiquitous and virulent virii as environments become more sophisticated and powerful. woody WWEAVER@DREW "The pessimism expressed above is in no sense reflected by my employers - they believe in a naive Knowledge Initiative. So what do I know." ========================================================================= Date: Tue, 28 Jun 88 06:33:11 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: me! Jefferson Ogata Subject: automatic software updates > From: David Camp > Sometimes I have reason to use an old version of Dos. Not only would > I not want it to be automatically replaced, but I would not want it > in Rom, either. Well, assuming it had the option of software update with user prompt- ing, you wouldn't have to worry about it being automatically replaced. This was already discussed. Also discussed was the ability to boot from a disk instead of ROM, if so desired. So whatsa prob? Anyway, DOS is not subject to this situation, since it doesn't have warm boots (as far as I know). The only boot is a full operating system reload procedure. - Jeff ========================================================================= Date: Tue, 28 Jun 88 08:36:03 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: Re: Authentication of programs In-Reply-To: Message of Thu, 23 Jun 88 18:31:00 EDT from Sounds like that could be an effective way of ensuring mail integrity. How about all data transfers on the Internet? I assume that the scheme which you pointed out is just for SMTP. That leaves FTPs up for grabs. It'll also be interesting to see how they'll implement that on dissimilar machines with dissimilar mail interfaces. VMS MAIL, for example, uses non-ASCII format mail files which can get real annoying. Regards, Ken 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: Tue, 28 Jun 88 10:52:30 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Russ_Housley.XOSMAR@Xerox.COM Subject: Re: Authentication of programs In-Reply-To: LUKEN@LEHIIBM1's message of 28-June-88 (Tuesday) 8:55:10 EDT Ken: Many of the questions you raise about "privacy enhanced mail" are answered in RFC-1040. The RFC can be obtained via FTP from SRI-NIC.ARPA with the pathname RFC:RFC1040.TXT. Log in with FTP username ANONYMOUS and password GUEST. The NIC also provides an automatic mail service for those sites which cannot use FTP. Address the request to SERVICE@SRI-NIC.ARPA and in the subject field of the message indicate the RFC number, as in "Subject: RFC 1040". Russ ========================================================================= Date: Tue, 28 Jun 88 08:47:10 CST Reply-To: Virus Discussion List Sender: Virus Discussion List From: David Camp Subject: Re: automatic software updates In-Reply-To: Message of Tue, 28 Jun 88 06:33:11 EDT from >> From: David Camp > >> Sometimes I have reason to use an old version of Dos. Not only would >> I not want it to be automatically replaced, but I would not want it >> in Rom, either. > >Well, assuming it had the option of software update with user prompt- >ing, you wouldn't have to worry about it being automatically replaced. I do not like being prompted during my boot sequence. I have a 'nightime' boot sequence which parks the disk should the machine lose power when I am away. A prompt would definitely cause problems in that case, and generally slow me down while rebooting, which sometimes occurs frequently. >This was already discussed. Also discussed was the ability to boot >from a disk instead of ROM, if so desired. So whatsa prob? > >Anyway, DOS is not subject to this situation, since it doesn't have >warm boots (as far as I know). The only boot is a full operating >system reload procedure. I do not understand the signifigance of having a warm boot, as it affects this discussion. -David- > >- Jeff ========================================================================= Date: Tue, 28 Jun 88 11:04:52 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Russell Nelson Subject: OS/2 and virii In-Reply-To: Woody's message of Tue, 28 Jun 88 01:54:00 EDT <8806281410.AA00395@ clutx.clarkson.edu> >>Assuming OS/2 is released, does anyone have a feeling for whether >>multitasking will have an enhanced impact of the viruses? >What it seems to boil down to is this: virii are a fact of life. Nonsense. Virii are only a problem because we insist upon running programs that pretend that the whole machine is theirs to use. These programs wouldn't have been written if Microsoft didn't have their heads up their collective asses. Why do people write directly to the communication ports? Because Microsoft didn't provide a real driver. Why do people write directly to the screen? Because Microsoft didn't provide a capable interface. Why do people write directly to the disk? Because Microsoft didn't provide a real operating system. There is no hope for the 8088. But Microsoft *could* have written a real operating system for the 80286. Maybe OS 1/2 provides sufficient protection to keep programs like the Norton Utilities from working. But so long as people run programs inside of the compatability box, we will have PC virii. You want protection from virii? Run Unix (or VMS or VM but remember that the only one of the three that you can run right now is Unix). Has anyone noticed the resounding lack of Unix viruses? ========================================================================= Date: Tue, 28 Jun 88 11:20:58 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: Monthly greeting from Ken [ Last modified 28-June-88 - Ken van Wyk ] Welcome! This is the monthly introduction posting for VIRUS-L, primarily for the benefit of any newcomers. Apologies to all subscribers who've already read this in the past (you'll only have to see it once a month and you can, if you're quick, press the purge key...:-). What is VIRUS-L? It is an electronic mail discussion forum for sharing information about computer viruses. Discussions should include (but not necessarily be limited to): current events (virus sightings), virus prevention (practical and theoretical), and virus questions/answers. The list is non-moderated and non-digested. That means that any message coming in goes out immediately. Weekly logs of submissions are kept for those people who prefer digest format lists (see below for details on how to get them). What isn't VIRUS-L? A place to spread hype about computer viruses; we already have the Press for that. :-) A place to sell things, to panhandle, or to flame other subscribers. If anyone *REALLY* feels the need to flame someone else for something that they may have said, then the flame should be sent directly to that person and/or to the list moderator (that'd be me, ). How do I get on the mailing list? Well, if you're reading this, chances are *real good* that you're already on the list. However, perhaps this document was given to you by a friend or colleague... So, to get onto the VIRUS-L mailing list, send a mail message to . In the body of the message, say nothing more than SUB VIRUS-L your name. LISTSERV is a program which automates mailing lists such as VIRUS-L. As long as you're either on BITNET, or any network accessible to BITNET via gateway, this should work. Within a short time, you will be placed on the mailing list, and you will get confirmation via e-mail. How do I get OFF of the list? If, in the unlikely event, you should happen to want to be removed from the VIRUS-L discussion list, just send mail to saying SIGNOFF VIRUS-L. People, such as students, whose accounts are going to be close (like over the summer...) - PLEASE signoff of the list before you leave. Also, be sure to send your signoff request to the LISTSERV and not to the list itself. How do I send a message to the list? Just send electronic mail to and it will automatically be redistributed to everyone on the mailing list. By default, you will NOT receive a copy of your own letters. If you wish to, send mail to saying SET VIRUS-L REPRO What does VIRUS-L have to offer? All submissions to VIRUS-L are stored in weekly log files which can be downloaded by any user on (or off) the mailing list. There is also a small archive of some of the public anti-virus programs which are currently available. This archive, too, can be accessed by any user. All of this is handled automatically by the LISTSERV here at Lehigh University (). How do I get files from the LISTSERV? Well, you'll first want to know what files are available on the LISTSERV. To do this, send mail to saying INDEX VIRUS-L. Note that filenames/extensions are separated by a space, and not by a period. Once you've decided which file(s) you want, send mail to saying GET filename filetype. For example, GET VIRUS-L LOG8804 would get the file called VIRUS-L LOG8804 (which happens to be the monthly log of all messages sent to VIRUS-L during April, 1988). Note that, starting June 6, 1988, the logs are weekly. The new file format is VIRUS-L LOGyymmx where yy is the year (88, 89, etc.), mm is the month, and x is the week (A, B, etc.). Readers who prefer digest format lists should read the weekly logs and sign off of the list itself. Subsequent submissions to the list should be sent to me for forwarding. What is uuencode/uudecode, and why do I need them? Uuencode and uudecode are two programs which convert binary files into text (ASCII) files and back again. This is so binary files can be easily transferred via electronic mail. Many of the files on this LISTSERV are binary files which are stored in uuencoded format (the file types will be UUE). Both uuencode and uudecode are available from the LISTSERV. Uudecode is available in BASIC and in Turbo Pascal here. Uuencode is available in Turbo Pascal. Also, there is a very good binary-only uuencode/uudecode package on the LISTSERV which is stored in uuencoded format. Why have posting guidelines? To keep the discussions on-track with what the list is intended to be; a vehicle for virus discussions. This will keep the network traffic to a minimum and, hopefully, the quality of the content of the mail to a maximum. No one wants to read personal flames ad nausium, or discussions about the pros and cons of digest-format mailing lists, etc. What are the guidelines? As already stated, there will be no flames on the list. Anyone sending flames to the entire list must do so knowing that he/she will be removed from the list immediately. Same goes for any commercial plugs or panhandling. Submissions should be directly or indirectly related to the subject of computer viruses. Responses to queries should be sent to the author of the query, not to the entire list. The author should then send a summary of his/her responses to the list at a later date. "Automatic answering machine" programs (the ones which reply to e-mail for you when you're gone) should be set to *NOT* reply to VIRUS-L. Such responses sent to the entire list are very rude and will be treated as such. When sending in a submission, try to see whether or not someone else may have just said the same thing. This is particularly important when responding to someone else's posting (which should be sent to that person *anyway*). It's very easy to get multiple messages saying the exact same thing. No one wants this to happen. Thank-you for your time and for your adherance to these guidelines. Comments and suggestions, as alway, are invited. Please address them to me, or . Ken van Wyk 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: Tue, 28 Jun 88 12:03:19 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "David M. Chess" Subject: OS/2 and virii Russell Nelson writes: > Virii are only a problem because we insist upon running programs > that pretend that the whole machine is theirs to use. This is a misconception; viruses do not have to talk directly to the hardware to function, and standard access controls (privileges, protected kernals, etc), do little or nothing to slow them down. One reason viruses are so dangerous is that they need do nothing unauthorized; they spread by altering objects that the user is authorized to alter. See Fred Cohen's original paper Fred Cohen, "Computer Viruses: Theory and Experiment", Computers & Security, Vol. 6 (1987) pp. 22-35 if you think Unix(tm) is somehow immune from viruses... This isn't to say anything against Unix; I don't know of -any- general-purpose operating system that has any protection against them. The only reason we've seen so many viruses for micro opsystems is that the typical virus-writer has a micro. DC "Unix" is a trademark of AT&T ========================================================================= Date: Mon, 27 Jun 88 14:05:00 URZ Reply-To: Virus Discussion List Sender: Virus Discussion List From: BG0@DHDURZ2 Subject: NO constructive viruses please Hi folks, 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. All the best, Bernd. ========================================================================= Date: Tue, 28 Jun 88 12:21:40 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Adam Lewis Subject: Re: OS/2 and virii In-Reply-To: Message of Tue, 28 Jun 88 11:04:52 EDT from Things like computer virii(sp?) will not disappear simply because you're running on a operating system that provides some memory protection. Take Unix for instance. Once someone has managed to get superuser priv. then the writing of a virus is within the realm of possibility. Any operating system is going to have security holes which the malicious user will take advantage of. A simple OS means that you will have simple virii to deal with and a complex OS means... What examples can people think of virus type programs on mini- and mainframe Op. systems? If any, how do they differ from the current crop nasties in the PC world? ----------------------------------------------------------------------- Adam Lewis ! I am but an egg. Center of Excellence for Computer Applications! University of Tennessee, Chattanooga ! ----------------------------------------------------------------------- ========================================================================= Date: Tue, 28 Jun 88 16:36:35 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: me! Jefferson Ogata Subject: DOS update, constructive viruses, and Unix viruses > From: David Camp > I do not like being prompted during my boot sequence. I have a > 'nightime' boot sequence which parks the disk should the machine > lose power when I am away. A prompt would definitely cause > problems in that case, and generally slow me down while rebooting, > which sometimes occurs frequently. It would only happen if you were booting from a disk with an old version of the operating system on it. Which is rare, and probably doesn't happen with your nighttime boot sequence. > I do not understand the signifigance of having a warm boot, as it > affects this discussion. The operating system update virus works by living in the RAM-resident version of the operating system. When a warm boot is executed, the operating system looks at the boot tracks on the new disk. If the boot tracks have an old version of the operating system on them, it offers to update it for you. A cold boot would defeat this purpose since it would purge the operating system from RAM and load the new one from disk without looking. Possibly the CRTL-ALT-DEL vector could be modified to check on cold boots as well, but this would be unwise, since a cold boot frequently means a trashed operating system anyway. And who wants to turn off the stupid machine and wait for the idiot memory test to cycle again? (As if your memory chips are real likely to die every time you turn the machine off.) Note that I refer to the normal CRTL-ALT-DEL procedure as a cold boot; it's certainly nothing like a warm boot. To me, the power- up sequence is a frozen boot. > 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. > 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. > 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? One little point about Unix viruses: most code distribution on ARPANET is via source code, not object code, since Unix runs on MANY DIFFERENT MACHINES. Few Unix machines have compatible instruction sets, so it is usually necessary to distribute source. It is difficult to hide viruses in programs if the source code is sitting there in plain view. Micro-users, on the other hand, are always trading object code on disks, or downloading object code from BBSs. - Jeff ========================================================================= Date: Tue, 28 Jun 88 16:39:02 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Ed Nilges Subject: Re: NO constructive viruses please In-Reply-To: Your message of Mon, 27 Jun 88 14:05:00 URZ I concur. The question of whether there can be a constructive virus is similar to whether or not self-altering code (in the sense of the Cobol ALTER verb or assembler code that writes on top of itself) is ever okay. Anything constructive a virus can do can be done by more standardized software. 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 snag is that it is hard to PROVE things about software. The CHRISTMA virus, propagated last year, seemed benevolent to its author. Other programmers may design viruses that they THINK are benevolent, but turn out to be nasty in terms (for example) of network traffic. We need to be able to talk about viruses and create them. The only safe way is the simulated machine, a technique which seems to have fallen into disuse. Olivieri and Rubin's COMPUTERS AND PROGRAMMING: A Neoclassical Approach is the only recent venture in this genre, and it is ten years old. Students, in my experience, hate artificial machines, since they can't tell potential employers about real experience. However, simulated machines teach the real issues of assembler programming and (as I said) provide a safe lab for virus experimentation. ========================================================================= Date: Tue, 28 Jun 88 17:21:46 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Ed Nilges Subject: Re: VM/CMS viruses In-Reply-To: Your message of Fri, 24 Jun 88 10:23:01 EDT Identifying the executable objects in a VM/CMS environment, as David M. Chess recommends in a recent posting, may be difficult. The EXECLOAD command allows you to load a file of any type as an EXEC. Therefore, you must take the text of the file into account. For example, an EXEC is any file starting with &TRACE (EXEC-2 language), any file starting with /* comment */ (REXX), or any file with "a lot of" words starting with ampersands (EXEC-1 language). Similar rules could be cooked up for MODULEs. However, I could conceive of a situation where a compiler writer acts in cahoots with a virus writer. The virus writer distributes an innocuous-looking data file. The vicious compiler wakes up, looks for the data file, and (iff it finds it) interprets the data therein as object code in some artificial language. The analogy to "binary" chemical weapons is obvious: in such weapons, two harmless substances are brought together to create a dangerous substance. The "compiler writer" could be any writer of any sort of generally-useful software. ========================================================================= Date: Tue, 28 Jun 88 09:04:51 PDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: S John Banner Subject: Re: automatic software updates In-Reply-To: Message of Tue, 28 Jun 88 08:47:10 CST from >>> From: David Camp >> >>> Sometimes I have reason to use an old version of Dos. Not only would >>> I not want it to be automatically replaced, but I would not want it >>> in Rom, either. >> >>Well, assuming it had the option of software update with user prompt- >>ing, you wouldn't have to worry about it being automatically replaced. > >I do not like being prompted during my boot sequence. I have a >'nightime' boot sequence which parks the disk should the machine >lose power when I am away. A prompt would definitely cause >problems in that case, and generally slow me down while rebooting, >which sometimes occurs frequently. >-David- >>- Jeff Yes, but in the situation, if your machine reboots, you shouldn't be getting any sort of prompts that you don't expect, as that version of the OS will think that it is the latest, and therefor will have no reason prompt you for anything (unless of course you have some software that will prompt you for some other reason). I too dislike prompts during a boot you see, but having a DOS that would update itself (assuming of course that it prompts you before actually doing anything) would certainly save a lot of time. And as to the person who said that it would be great, untill something went wrong, well, I have had fun installing new versions of DOS (read reformat of harddrive required), but I still install new versions of DOS when they come out; in my opinion the added convniance is well worth the possible hastles... sjb. ========================================================================= Date: Tue, 28 Jun 88 21:50:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Woody Subject: Hide in plain view me! Jefferson Ogata , at the end of a letter dealing with DOS updates, constructive viruses, and Unix viruses, writes > >One little point about Unix viruses: most code distribution on ARPANET >is via source code, not object code, since Unix runs on MANY DIFFERENT >MACHINES. Few Unix machines have compatible instruction sets, so it >is usually necessary to distribute source. It is difficult to hide >viruses in programs if the source code is sitting there in plain view. >Micro-users, on the other hand, are always trading object code on >disks, or downloading object code from BBSs. > >- Jeff > Personally, I don't feel all that secure about source code. On one of my subdirectories dealing with a research project, I've several dozen pascal programs and dozens of include files, each only a dozen K each, but you get the idea. Now suppose I write a procedure that will call upon the system to find me all the text files with extensions of .PAS or .INC that my process has the ability to write to, and then with some low probability search for the key word "procedure". Between the next var and the end of the procedure I edit the file to be this procedure I'm writing... a virus. Guess what? The program still compiles, since the headers match. When it is compiled and executed, the user propagates the virus. Now very few system service calls are made - just a little directory work. All done through the normal operating system, no violation of the "usual" guidelines for programming. My best "Intro to Pascal" students could write this thing. Note that any block comment after the procedure is preserved, so that to a cursory scan, the structure of the program is preserved. Probably, the programming style of the virus writer and the person writing the file would be different, so that an examination based upon reading the file would detect the difference, but... hey, I probably have fifty or so files the program could infect. I don't carefully read things before editing - I get an idea, then make that small change, and recompile and go. I could easily be hit by this sort of virus. 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? 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