========================================================================= Date: Thu, 15 Sep 88 00:02:22 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: me! Jefferson Ogata Subject: Re: crc twiddling I apologize for my previous confusing remarks where I used CRC in place of checksum. The example I gave required adding 257 bytes, not 65535. The reason I discussed only adding bytes to the original file, rather than modifying bytes in the file, is that as far as I know, virus attacks are not effective if they crash the program they infect, which is likely to happen if they twiddle bits in the original program. Any virus attack that crashes your program will be obvious and not very pervasive. In addition, bank data files are well out of the arena of likely virus infection. As far as rearranging bytes in the original program to make the virus, this also is likely to crash the program. - Jeff Ogata ========================================================================= Date: Thu, 15 Sep 88 10:35:38 EST Reply-To: Virus Discussion List Sender: Virus Discussion List From: Neil Goldman Subject: Re: Dual CRCs In-Reply-To: Message of Tue, 13 Sep 88 09:51:00 EDT from > >< It IS possible for two different programs to have the same CRC for >< two different polynmials. > >True, for any reasonable polynomials, but it gets harder very >quickly as you add more polynomials. Esp. to do it on purpose. > >Has anybody seen or heard of any virus designed to pass a CRC >check? Or is this more work than the casual psychopath >is willing to incur? > > EAE114@URIMVS (ERISTIC) Although I have not actually seen a virus which has been designed to pass a CRC check, I am of the school of thought that no virus prevention/detection method is foolproof. If the virus author is able to determine the polynomial used to detect file changes by the detection scheme of a particular detection product (such as disassembling an old version of FluShot which may still be in use), the virus author could calculate the number of NOP (no-operation) instructions which would need to be included the the virus to ensure that the CRC would pass ok. Neil A. Goldman NG44SPEL@MIAMIU.BITNET Replies, Concerns, Disagreements, and Flames expected. Mastercard, Visa, and American Express not accepted. ========================================================================= Date: Thu, 15 Sep 88 10:19:16 CDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Len Levine Subject: Re: CRCs In-Reply-To: Message from "Jerry Leichter" of Sep 14, 88 at 2:46 pm > >The mathematics of CRC's is very simple. The basic idea can be seen more >easily by using a much simpler algorithm: Consider an input file as a very >long binary number B. Choose a some fixed number N, and compute the remainder >of B divided by N. The result is between 0 and N-1, and is your checksum. > >[...] >you can produce any CRC you want by modifying just the trailing deg(Q)+1 bits >of the input. What Rabin pointed out, however, is that if you DON'T know the >polynomial, then your chance of making just the right modification is essen- >tially the same as that of guessing the polynomial, which can be made small >by chosing the polynomial from a suitably large set of candidates. > > -- Jerry > > Thank you jerry, just right. + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + | Leonard P. Levine e-mail len@evax.milw.wisc.edu | | Professor, Computer Science Office (414) 229-5170 | | University of Wisconsin-Milwaukee Home (414) 962-4719 | | Milwaukee, WI 53201 U.S.A. Modem (414) 962-6228 | + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + ========================================================================= Date: Thu, 15 Sep 88 10:23:57 CDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Len Levine Subject: Re: Student paper In-Reply-To: Message from "VIRUS-L@LEHIIBM1.BitNet" of Sep 14, 88 at 3:42 pm > > The paper has one flaw in it that I can see. It claims that Trojan horses >carry viruses in terms that imply that that's *all* Trojans do. This can >clearly not be the case, as I personally know of many Trojans that do not >carry self-replicating programs. Additionally, the term Trojan Horse as it >is used in the computer world was coined long before the term virus. > There are several errors in the paper of that kind. This does not diminish its value however in that is gives one excellent example of the spread of a virus in a "protected" environment, and in that it gives a good list of commercial virus products and their prices. It is a very useful document. + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + | Leonard P. Levine e-mail len@evax.milw.wisc.edu | | Professor, Computer Science Office (414) 229-5170 | | University of Wisconsin-Milwaukee Home (414) 962-4719 | | Milwaukee, WI 53201 U.S.A. Modem (414) 962-6228 | + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + ========================================================================= Date: Thu, 15 Sep 88 10:35:53 CDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Len Levine Subject: Re: Dual CRCs In-Reply-To: Message from "Neil Goldman" of Sep 15, 88 at 10:35 am >Although I have not actually seen a virus which has been designed to pass a >CRC check, I am of the school of thought that no virus prevention/detection >method is foolproof. > >If the virus author is able to determine the polynomial used to detect file >changes by the detection scheme of a particular detection product (such as >disassembling an old version of FluShot which may still be in use), the >virus author could calculate the number of NOP (no-operation) instructions >which would need to be included the the virus to ensure that the CRC would >pass ok. > >Neil A. Goldman NG44SPEL@MIAMIU.BITNET > It does not require a string of NOPs to do this, just a jump around two bytes and the inclusion of the suitable number in those two bytes. + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + | Leonard P. Levine e-mail len@evax.milw.wisc.edu | | Professor, Computer Science Office (414) 229-5170 | | University of Wisconsin-Milwaukee Home (414) 962-4719 | | Milwaukee, WI 53201 U.S.A. Modem (414) 962-6228 | + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + ========================================================================= Date: Thu, 15 Sep 88 11:54:00 EST Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Jerry Leichter (LEICHTER-JERRY@CS.YALE.EDU)" Subject: RE: Re: crc twiddling The example I gave required adding 257 bytes, not 65535. Yes; I came to the same realization shortly after posting my note. The reason I discussed only adding bytes to the original file, rather than modifying bytes in the file, is that as far as I know, virus attacks are not effective if they crash the program they infect, which is likely to happen if they twiddle bits in the original program. Any virus attack that crashes your program will be obvious and not very pervasive. A virus can be a rather small program - a couple of hundred bytes is suffici- ent. Do you really believe I can't find 500 bytes to change in a 300K program that will not result in a crash until you've run the program for weeks? The usual rule is that 10% of the code accounts for 90% of the cycles. This doesn't, of course, mean that the other 90% of the code is never executed, but in practice any large program will contain TONS of code that, for all practical purposes, is never needed. Large operating systems, BTW, often contain more code to deal with error recovery of various sorts than with normal operation. Years might go by before you noticed that that code wasn't working as specified. Finally, any large program is certain to have code in it that can be made smaller, often substantially smaller, especially if you are willing to make it a bit slower and less accurate - properties you'd hardly ever notice in typical operation. Just how much it is possible to crunch code would probably astound anyone who never had to work on the systems of 15 and 20 years ago, when 128K bytes of main memory was almost incomprehensibly huge. These days, few people have to work under memory constraints - it's hard and gains you nothing on systems they use. But people skilled in this art do exist - embedded systems of various sorts are still built with small (cheap) memories, for example - and any serious virus writer could pick up the skills if he so chose. In addition, bank data files are well out of the arena of likely virus infection. Again, be careful that you don't limit the problem you are willing to examine so much that you miss things. A Trojan horse program that scrambled some of your data files by exchanging bytes here and there could do more damage to you than many viruses. If you had a checksum program, you might consider using it to checksum your data files, just to protect against this kind of thing. It had better be harder to fool than the checksums you've proposed, or you'll likely find yourself in worse shape for having trusted in it than if you had never started using it at all! As far as rearranging bytes in the original program to make the virus, this also is likely to crash the program. See above. Again, remember that "I can't think of any way to do X" is not a reasonable measure of how hard X is, unless you are VERY familiar with problems like X - and even then, it's suspect. -- Jerry ========================================================================= Date: Thu, 15 Sep 88 10:29:56 CDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Len Levine Subject: Popular Level Paper Not to be outdone by a couple of mere students, I am submitting my paper that was first entered here in rough form. It was published this week in the UWM campus computing newsletter and is at a lower level than the Keil and Lee paper that I read here this week. It serves a different audience. Thanks to those of you who made suggestions, I took some of them. Potential Virus Attack by L. P. Levine There has been talk recently about the presence of virus programs running on office computers. There now are a significant number of such machines on this campus. If a virus does infect a significant number of machines here it is possible that many office IBM compatible (or Macin- tosh) machines will fail or lose files on the same day. It will be a very unpleasant time and our professional staff will be overwhelmed by requests for help and will take some time (weeks) to get the recovery process under way. Most of us are unaware of how dependent we have become on these desktop machines and how much we will be affected by the loss of data that may ensue. Perhaps we should define some terms here. There are two computer program elements that need definition. First is a Trojan Horse program. This sort of program, like its historical namesake, has two functions. On the "outside" it does some- thing to encourage the user to run it. Typically, Trojan Horse programs may be games, small support programs, such as directory listers, or even, in one case already on record, commercial software packages. On the "inside" however, the program does something unfriendly to the computer on which it runs. Some Trojan Horse programs delete files, some reset clocks, some mark disk areas as unusable and some change the operating system of the computer. The most destructive of them cause other pro- grams to change their nature, usually by adding instructions to those programs that make them Trojan Horse programs as well. These added instructions are often called computer viruses. A computer virus is a portion of a program that does not run alone, but requires another program to support it. In this sense it is like a biological virus, requiring a cell for a host in order to allow it to work. Since it does not run alone, it does not appear in any directory and is never directly executed. It moves from program to program by making each program to which it is attached (infected so to speak) a Trojan Horse program for further software infection. A virus may be programmed to appear to do nothing for a long time (remain dormant), and then, when some trigger event occurs, do whatever it is programmed to do. The movement of a virus program element from machine to machine occurs when a Trojan Horse program is run on that machine. If a virus program element infects our office machines, then not only will the company's office machines be affected, but the home ma- chines that many staff members now have will also have their files af- fected by the very same virus, and at the same time. If you are prepar- ing a paper for publication, writing or working on an exam, or preparing some important correspondence, you may well find that your machine read- able copies of that material will become unusable both at home and at the office. This paper discusses some evasive action that you can do now to prepare for the return of your machine to working order. What I am recommending in this paper is no more than good housekeeping and is a practice that each of us should do anyhow, with or without the threat of some mysterious computer virus. What I will discuss for the next few paragraphs applies to users who have machines with either a floppy disk drive and a hard disk drive or have two floppy disk drives on their computers. Step one: Locate the original source disks for the operating system you are now using on your computer. This may no longer be the system delivered with your machine, you may well have had an upgrade. DO NOT PUT THESE DISKS INTO YOUR FLOPPY DRIVE YET. Secure a few dozen write- lock tabs and put one on each of the delivery system disks. (When you hold a disk upright the right side of the disk has a 1/4" square notch cut into the black paper jacket. The write-lock tabs are black or alumi- num colored gummed paper tags about 3/4" X 1/2" that can be stuck over the edge of the disk covering the front and back of this notch. When that tab is in place it is not possible for the computer to write infor- mation onto a floppy disk.) Only after you have write-locked these disks should you put the disk into the computer and compare the system on that disk with the system you are using. STOP AND READ THE NEXT SENTENCE! The simple act of executing the DIR command on an unlocked disk is enough to infect that disk with a virus if your system is already infected and if the disk is not write- locked. I am not kidding. There is a very small probability that your system is already infected. I recommend that you compare the date and size of the file COMMAND.COM on your original source disks and on your working disk or disks to see that they are the same. For my system the results look like this: ------------------------------------ C> dir a:\command.com Volume in drive A is MS330PP01 Directory of A:\ COMMAND COM 25276 7-24-87 12:00a 1 File(s) 5120 bytes free C> dir c:\command.com Volume in drive C has no label Directory of C:\ COMMAND COM 25276 7-24-87 12:00a 1 File(s) 7391232 bytes free ------------------------------------ Note that both copies of COMMAND.COM have the same date and time of creation (midnight on July 24th 1987) and both are the same size (25,276 bytes). The numbers for your machine may well differ from mine, but both should be the same. When those disks have been found, put them away in a safe place. I recommend that they be put in a plastic storage box not too near your computer. Step two: There are a small number of software packages that you would be lost without. In my case they include WordStar, dBase III, PKARC, Kermit, and Directory Scanner. These packages may well be pur- chased commercial software (WordStar, dBase III), shareware (PKARC, Directory Scanner), and freeware (Kermit). In each case you should have an original source delivery disk for each of these packages. Find those disks, WRITE LOCK THEM, compare them with the copies you are now using, and put them in a safe place. I recommend that they be put with the system disks discussed above. (It is probably true that the creation dates for the running copies of this sort of software will disagree with the creation dates for the delivery disks. Installation of many of these packages entails writing to the program. That is not a problem.) Step three: Using the backup procedure of your choice, perform a backup of the system files on your computer. If I was using a dual floppy based system, I would simply make copies of my working WordStar, dBase III, PKARC, Kermit, and Directory Scanner disks. If I was using a computer with a floppy and a hard disk, I would use backup-restore, or Fastback or some other package to back up the directories C:\WS, C:\DB3, C:\ARK, C:\KERMIT and C:\DS. (Of course these directories have different names on your system.) Write lock these backup disks. Label them with today's date. Using your backup system compare the disks you have just backed up with the disks you are using to ensure that the backup "took". Put the backup disks in a safe place. This will tie up half a dozen disks, but with disks now costing $0.35 each, you will probably find the $2 investment worth while. Step four: (This applies to those users who use hard disk based computers.) Prepare a backup procedure that will permit incremental backups. This will entail backing up the entire system once, and then periodically backing up those files that have changed since the last backup. Perform such incremental backups regularly. After several such incremental backups, the size of the backup set will become quite large. At that time, put the backup set away in a safe place and begin with another set of disks for a full system backup followed by several incre- ments. When the second set is full, put them away and return to the first set. This will afford a very secure set of backup files. I find that 50 disks makes a good backup set. Thus 100 disks would be used for the double backup group. I suspect that most users would need to do a full backup about 4 to 8 times per year, requiring about 1/2 hour of manipulation and should do incremental backups about twice per week, requiring less than 5 minutes. (It is a very good idea to periodically test the backup system with a verification of what you have backed up. Most file backup systems have a Verify command to do this sort of test.) Step five: Go back to your useful work. Recovery from the loss of one or a few files: Sooner or later you will lose some files. They will disappear without apparent cause and you will blame the problem on a virus. It is my experience that in cases like this no virus is involved, the loss of files will be due to an operator error. If you have been doing incremen- tal backups, then the simplest corrective action is to use the recover feature of the backup system that you are using and simply restore the latest copy of the lost file(s) to the hard disk. If you have been conscientious in your backup practice, then the loss of work will entail just a few minutes or, at most, a few hours of rework. Recovery from the loss of the entire system: It may happen that the entire hard disk seems to be lost. This is serious but, in most cases, is likely not the result of a virus. Most failures of the hard disk are due to hardware problems. The best solu- tion is to repair the hardware if the technical people judge that that is the problem, and then, after reformatting the hard disk, restore the system from your latest backup. Almost without fail, this will result in a complete return to a normal system. Really bad news, the restore does not work: This may well be the point of this memo. If a virus has been plant- ed in your system and has been set to trigger on some event, then the only way to recover is to rebuild the system from scratch using the write locked set of disks that I advised you to prepare above. If these disks are not write locked, and if you mount them onto an infected system, then the disks will be infected in turn and you may well be unable to restore from a clean, uninfected source without returning to the system vendor for a fresh copy of each of your executable programs. On the assumption that you first build your system again from scratch, you may restore all of the data files from your backup set. (A data file is one that does not have the extension .com, .exe, or .sys.) Any other file should not be able to carry a virus either between systems or over the backup proc- ess. Some facts: There is no reason ever to boot the system from a foreign disk whose history you are not prepared to trust. (For example, booting from a copy protected version of Lotus 1-2-3 is as secure as the Lotus corporation can make it.) There is no reason why a disk used to transport data between ma- chines should have a copy of the files io.sys, msdos.sys, ibmio.sys, ibmdos.sys or command.com on it. No system to date has been infected by the transport to it of data files. Only executable files (including device drivers and the operating system itself) can be used as Trojan Horse programs. Leonard P. Levine Professor Department of Computer Science College of Engineering and Applied Science University of Wisconsin-Milwaukee Milwaukee, Wisconsin 53201 (414) 229-5170 (414) 962-4719 ========================================================================= Date: Thu, 15 Sep 88 15:30:04 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "David M. Chess 862-2245" Subject: Len Adleman? I notice that Len Adleman is credited with coining the term "virus" in "THE INFECTION OF PC COMPATIBLE COMPUTERS", and in a VIRUS-L posting from Loren. Does anyone have any more details? When and where was the term coined? The earliest use of the term that I have is in 1974, a paper by Gunn referenced in Cohen's "Computer Viruses: Theory and Experiments". DC ========================================================================= Date: Thu, 15 Sep 88 15:52:53 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "David M. Chess" Subject: THE INFECTION OF PC COMPATIBLE COMPUTERS Nice paper! A couple of nits/questions: - Talking about COMMAND.COM, the paper says "a number of viruses have been discovered which infect this file." I believe that that number is in fact "one" (the Lehigh virus). Can anyone cite another COMMAND.COM-targetted virus that probably exists? (Vague rumors need not apply!) - In a similar vein, I would advise being a little less confident when stating things like "four versions of the Israeli virus and seven versions of the Brain virus have been found." It may be true in the most literal sense of "version" (anyone could create a "new version" of one of these by changing a text or no-op byte), but there doesn't seem to be any good evidence that it's *really* true, in the sense of there being that many versions that actually have some difference in their behavior. (Authors, especially in the popular press, always seem to be tempted to exaggerate, if only by implication, the number of different viruses they know of; makes them sound wiser...) - The advice to write-protect COMMAND.COM should probably include a note that this will not in fact do any good against a virus whose author has thought of the possibility (and most probably will). It's still not bad advice, but the user should be aware that it's not a Real Solution to anything. I don't mean to imply in my first two points that I'm one of these folks who doesn't believe viruses exist! I know they do. I just don't think that there are as many different ones loose in the world as some column-writers would like to imply. DC ========================================================================= Date: Thu, 15 Sep 88 17:13:32 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Joe McMahon Subject: "Dukakis" Vaccine (Mac) Well, let's fight fire with fire. If somebody's going to publish a virus, I'm going to publish the matching vaccine. To use this vaccine, cut on the dotted lines, download it to your Mac, paste it into the scrapbook, and then paste it into your Home stack in HyperCard. If that's beyond what you're willing to try with HyperCard, get the newest version of my virus documentation stack from LISTSERV at SCFVM -- it has a button that will do it for you. (Note: that may not be available until tomorrow (9/16)) ---------- CUT LOOSE --------- -- Note: "Duk-akis" contains a dash here to prevent the vaccine from -- detecting itself as a virus. -- Script to detect the spread of the "Duk-akis" virus. It works by -- trapping the "set" command. I haven't seen "Duk-akis", but I should -- think that it works by setting the scripts of various objects to -- whatever they were plus an "on openStack" handler. Well, by trapping -- the "set" command, we can then find out if we are setting a script. -- If we are, then we can sort of work like "Vaccine" does; i.e., we -- prompt the user to see if he or she wants to allow the command to -- continue. If it is stopped, then all scripts are halted. -- Additionally, if the script contains the word "Duk-akis", then no -- option is given Q the script is halted straight away. -- THIS SCRIPT SHOULD BE INSTALLED IN THE "HOME" STACK, -- IN THE STACK SCRIPT. -- You can test this script by making a new stack, then keying the -- following examples into the message box: -- % "Set the script of this stack to empty" -- % "Set the script of this stack to field 1" -- % "set the script of this stack to Duk-akis" (don't type the dash) -- Try it, I think you'll like it! -- This script is free to everyone apart from the person who wrote the -- "Duk-akis" virus. I just hope it affects every single stack he or -- she has or gets in the future! -- Regards to all from a truely devoted HyperCard fan, -- Ian Summerfield -- Technical Support Supervisor -- Apple Computer UK Ltd. -- CIS: 76657, 742 -- "Sysop" - AppleFone HyperCard BBS: Luton, England: 0582 584134 -- Modified slightly 8/22/88 by Joe McMahon to make sure that --"set the scriptI" (vs. "set script") doesn't slip through. -- Modified a bit more 8/29/88 by Joe McMahon to add Ian's fixes -- to prevent the vaccine from detecting itself as a virus. on set put "Duk"&"akis" into duk if the param of 1 is "script" or the param of 2 is "script" then get the params if last word of it is "to" then put it && "empty" into it put it into s if s contains duk then repeat 10 play harpsichord tempo 300 "a b c b a b c b" end repeat answer duk&&"virus detected!" with "Halt scripts" answer "Okay, you're safe now! It didn't spread." exit to HyperCard end if play harpsichord tempo 200 "e c e c e c e" answer "Warning: Script change requested" with "Show me" repeat answer s with "Allow" or "Stop!" or "Show more" if it is "Allow" then pass set else if it is "Stop!" then answer "All scripts halted!" exit to HyperCard else put the userLevel into userSafe set userLevel to 5 doMenu "New Field" get the number of card fields set rect of card field it to 0,19,512,342 set style of card field it to scrolling put the params into card field it choose browse tool wait until not the mouseClick wait until the mouseClick choose field tool click at loc of card field it doMenu "Clear Field" choose browse tool set userLevel to userSafe end if end if end repeat else pass set end set --------- All right, you can stop here --------- --- Joe M. ========================================================================= Date: Thu, 15 Sep 88 19:56:03 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: me! Jefferson Ogata Subject: more twiddling... >A virus can be a rather small program - a couple of hundred bytes is >sufficient. Do you really believe I can't find 500 bytes to change >in a 300K program that will not result in a crash until you've run the >program for weeks? >... >Finally, any large program is certain to have code in it that can be >made smaller, often substantially smaller, especially if you are willing >to make it a bit slower and less accurate - properties you'd hardly ever >notice in typical operation. Sure you can find 500 bytes you can change in many programs. But I'll bet you a Snickers bar you can't write a 500 byte program that can find them. I'll bet you a Mars bar that you can't write a 500 byte code optimizer. To be fair, though, one possibility that might not have occurred to you is this: write a virus that compresses the original code before instal- ling itself; then fills in bytes appropriately to match a checksum. On execution it decompresses the original code and runs it. This allows you to beat checksums, file size checks, and CRCs simultaneously. And the original program won't crash. Such viruses have been discussed, though not with the intention of beating virus detection methods. >A Trojan horse program that scrambled some of your data files by >exchanging bytes here and there could do more damage to you than many >viruses. Perhaps, but this is VIRUS-L. I was discussing methods of protecting against viruses. In addition, I made no claims about the desirability of the checksums I mentioned; I merely discussed some of the associated math. The fact that it's possible to circumvent the checksums is not under investigation. No method is perfectly foolproof. - Jeff Ogata ========================================================================= Date: Fri, 16 Sep 88 08:37:49 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: Virus hits Japan (from RISKS forum) The following is a report on a so-called virus that has hit Japan. I thought that it was particularly interesting because it steals user passwords via a network. The information is somewhat sketchy, but it doesn't appear (to me) to propogate, so doesn't seem to be a virus, but a clever password snatcher, even though the article refers to it as a virus (reprinted from RISKS forum). Ken Date: Wed, 14 Sep 88 13:35:04+0900 From: Yoshio Oyanagi Subject: The First "Virus" on Japanese PC PC-VAN, the biggest Japanese personal computer network operated by NEC, was found to be contaminated by a kind of virus, several newspapers reported today (September 14). This is, as far as I know, the first virus reported on a Japanese PC. The viruses so far reported in Japan were all on American PC or WS. PC-VAN is a telephone based network between NEC PC9800 personal computers, the best sold PC (> one million) in Japan. This virus does not destroy programs or data unlike those in US, but it automatically posts the user's password on the BBS in crypto- graphic form. The offender will later read the BBS and obtain the password. Several members of PC-VAN claim that they are charged for the access to PC-VAN which they do not know. This virus seems not to be contagious by its own power. The PC9800's OS was contaminated when the user carelessly run a anonymously distributed program on the PC. Kenneth R. van Wyk Calvin: Ever consider the end of the User Services Senior Consultant world as we know it? Lehigh University Computing Center Hobbes: You mean nuclear war? Internet: Calvin: I think Mom was referring to if I BITNET: let the air out of the car tires again. ========================================================================= Date: Fri, 16 Sep 88 08:41:50 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: a hole (and cure) in GNU EMACS, from RISKS The following (also from RISKS) is a report on a security hole in GNU EMACS, along with a cure. Does anyone know of any viruses that have used this EMACS "feature"? GNU EMACS users should (imho) read this carefully, and add the fix listed below in the .emacs file. Ken Date: Thu, 15 Sep 88 08:32:45 PDT From: the terminal of Geoff Goodfellow Subject: GNU Emacs & Security (A.Gaynor via Eliot Lear) Return-Path: Date: Wed, 14 Sep 1988 11:48:10 PDT From: Eliot Lear To: hackers_guild@ucbvax.Berkeley.EDU Usmail: 700 East El Camino Real, Mtn View, California 94040 Phone: (415) 962-7323 Subject: [gaynor@aramis.rutgers.edu (Silver) : GNU Emacs & Security ] [The following was discovered by one of the Rutgers systems programmers. It is similar to the old "vi:" bug in that visiting a file may cause execution of an arbitrary set of commands including shell escapes... I am told that this has not been brought up on hg before.-eliot] From: gaynor@aramis.rutgers.edu (Silver) Subject: GNU Emacs & Security This message is being sent to everyone in group slide. I've wandered across an application of a feature of GNU Emacs that may allow sliders to fall victim to trojan horses arbitrarily stuck in files. The feature in question is the `file variables' section of a file. Upon reading the file, portions of text may be evaluated, with perhaps profound results. For example, using this feature I was able to create a file that copied /bin/sh to my home directory, and chmod it to run setuid root. It wasn't hard at all. With a little effort, I'm sure I could have made its effects totally transparant. So, protect yourself by inserting the following at the root level of your .emacs: ;; Protect thine arse from the Trojan file-variables section. (setq inhibit-local-variables t) The pertinent portion of this variable's documentation reads, "Non-nil means query before obeying a file's local-variables list.". So, from now on, it's going to ask you if you want to process the variables if they are present. Only answer `y' if you trust this file not to put you through a blender. If you answer `n', you can always look at the variables somewhere within the last 3000 characters of the end of the file, and, if they appear reasonable, say `M-x normal-mode' to process them. Regards, [Ag] gaynor@rutgers.edu Kenneth R. van Wyk Calvin: Ever consider the end of the User Services Senior Consultant world as we know it? Lehigh University Computing Center Hobbes: You mean nuclear war? Internet: Calvin: I think Mom was referring to if I BITNET: let the air out of the car tires again. ========================================================================= Date: Fri, 16 Sep 88 06:27:42 PDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Robert Slade Subject: Rearranging program guts An object code optimizer would be a pretty sophisticated program to try and imbed into a small virus. Also, adding to one place and taking from another or rearranging the bytes in order to imbed your code would require a program with a lot of smarts regarding how often a piece of code is likely to be executed, and *still* wouldn't fox the smarter CRC programs. Still, it would be a prime use for a targetted virus, and not all checking programs are all that smart. ========================================================================= Date: Fri, 16 Sep 88 12:37:00 EST Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Jerry Leichter (LEICHTER-JERRY@CS.YALE.EDU)" Subject: RE: Rearranging program guts I was NOT proposing that a virus optimize a random program it found on your disk in order to find place to insert itself. Nor was I suggesting that it search around in random programs for "safe" positions. The PROGRAMMER of the virus would find the safe position in some common file or files. Only those files would get infected. A nasty virus of this sort would operate in two stages. In stage 1, it would spread through files it knew about, but do nothing harmful: Infiltration. In stage 2, it would begin infecting other programs, which would then do damage, perhaps after a further delay: Sabotage. The stage 1 infection would be very difficult to detect - there would be no clue that anything untoward was happen- ing at all. Only explicit tests, like checksums on files, could detect the infiltration - and it is exactly ways of bypassing those that we are discussing here. If stage 1 were to delay long enough - 6 months, a year - you would likely find that you had no uninfected backups anywhere. Since the connection between the infection of OTHER programs of stage 2 and the hidden stage 1 virus would be tenuous, even figuring out that there WAS a stage 1 virus around would take a while - and finding it might be hard. A really nasty approach would be for stage 1 to be targeted at backup programs (where it would stay latent forever) and file transfer programs (where it would eventually infect files as it transfered them). This would make it look as if the stage 2 infection came from a recent up-load. How likely are these scenarios? Who knows. The point is, if you are going to rely on a virus detection mechanism, you had better have a LOT of confidence that it is hard to defeat - or you open yourself up to big headaches later. -- Jerry ========================================================================= Date: Wed, 21 Sep 88 08:31:04 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Ken van Wyk Subject: Donald Gene Burleson found guilty I just read an Associated Press (by Tim Lott) news article in an Allentown PA newpaper which said that Donald Gene Burleson, a former programmer, was found guilty of planting a computer virus. The article said that this was the first conviction in the country for such a case. Hopefully it will set a precedent. The conviction itself was for "harmful access to a computer, a third-degree felony that carries up to 10 years in prison and up to $5,000 in fines." According to the article, "A key to the case was the fact that State District Judge John Bradshaw allowed the computer program that deleted the files to be introduced as evidence". Apparently, the virus, if indeed it was a virus, was "activated like a time bomb, doing its damage two days after (the defendant) was fired". It is not clear, to me, that the program was actually a virus and not a simple time bomb. The article adds further confusion to the matter by defining a virus as "...a computer, often hidden in apparently normal computer software, that instructs the computer to change or destroy information at a given time or after a certain sequence of commands." Nonetheless, Mr. Burleson was convicted. His attorney expects him to get "the minimum sentence of two years' probation". It will be interesting to see if more such cases come to light as a result of this one. Ken Kenneth R. van Wyk Calvin: Here, try this new cereal, User Services Senior Consultant Chocolate Frosted Sugar Bombs. Lehigh University Computing Center Hobbes: Gack! Ptui! :-( Internet: Calvin: Yeah, they're a bit bland until BITNET: you scoop some sugar on them. ========================================================================= Date: Wed, 21 Sep 88 08:52:20 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Ken van Wyk Subject: info on court case The conviction that I described earlier, by the way, was in Fort Worth, Texas. Sorry I neglected to mention that before... Ken ========================================================================= Date: Wed, 21 Sep 88 09:42:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: NEWTON@NBSENH Subject: Viruses hit the big time... For anyone who hasn't been by a newsstand yet, the current TIME magazine cover is on computer viruses. Haven't read it yet, but thought that this was worth mentioning. Barry ========================================================================= Date: Wed, 21 Sep 88 12:46:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: me! Jefferson Ogata Subject: 2 years probation It's fascinating that there has actually been a conviction, but I must say two years probation is not likely to serve as the least deterrant to future virus attacks. Probation is a breeze. - Jeff Ogata ========================================================================= Date: Wed, 21 Sep 88 13:07:32 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Bruce Howells Subject: 2 years probation Probation might be a breeze, but... if you were an admissions officer, or interviewing someone, would you accept/hire them into a cs position if they had been convicted of attacking a system via virus? Bruce Howells, engnbsc@buacca.bitnet, engnbsc@buacca.bu.edu - These opinions are my own; and in no way represent those of Boston University or any other organization. (boring disclaimer, but it seemed important on that one.) ========================================================================= Date: Wed, 21 Sep 88 11:43:13 PST Reply-To: Virus Discussion List Sender: Virus Discussion List From: PJS%naif.JPL.NASA.GOV@HAMLET Subject: RE: 2 years probation SIGNOFF VIRUS-L 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