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 AA21262; Thu, 7 Jun 90 13:10:35 -0400 Received: from SEI.CMU.EDU by g.sei.cmu.edu (5.61/2.5) id AA13739; Thu, 7 Jun 90 13:10:31 -0400 Received: from nsfnet-relay.ac.uk by sei.cmu.edu (5.61/2.3) id AA00861; Thu, 7 Jun 90 13:09:36 -0400 Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK via Janet with NIFTP id aa15534; 7 Jun 90 15:46 BST From: Anthony Appleyard To: KRVW <@NSFnet-Relay.AC.UK:KRVW@sei.cmu.edu> Date: Tue, 05 Jun 90 14:08:48 BST Message-Id: <$TGVGDBVHCQBG at UMPA> Subject: Virus-L vol 0 issue #0628 Virus-L Digest Tue, 28 Jun 88, Volume 0 : Issue #0628 Today's Topics re: OS/2 and virii automatic software updates Re: Authentication of programs Re: Authentication of programs Re: automatic software updates OS/2 and virii Monthly greeting from Ken OS/2 and virii Re: OS/2 and virii DOS update, constructive viruses, and Unix viruses Re: NO constructive viruses please Re: VM/CMS viruses Re: automatic software updates Hide in plain view ------------------------------ 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: 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? -------------------- *** end of Virus-L issue ***