========================================================================= Date: Fri, 1 Jul 88 13:08:00 ECT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Ole-Hjalmar Kristensen +47-7-592760 Subject: Re: OS/2 and virii Adam Lewis writes : "Once someone has managed to get superuser priv. then the writing of a virus is within the realm of possibility." It is NOT necessary to have any special privileges under UNIX to make a virus, on the contrary, making a virus is probably one of the "better" methods to attack the security of a UNIX system. Virii can be created by anyone who has access to the compiler and linker and some knowledge of the format of an executable file. Once the virus is created, it can be inserted into a copy of a system program, for example ls. This infected ls can then be spread to all directories where the creator has write access, and the first time a user tries to list the files, it will infect any other executables owned by this user. I have tried this myself, using a harmless virus which is intentionally built so that it needs a specific file to propagate itself. The UNIX system on which the test was performed is isolated from our other machines in order to avoid uncontrolled infection. Furthermore, the virus maintains a log which shows all executables infected. This virus has successfully infected programs such as ps, ls, sh as well as other executables I will not go into any details about how the virus works, but it was created in approximately two days of work. One day to dig up the necessary information, and another to implement and test it. I have drawn the following conclusions from this experiment : * Creating a UNIX virus is simple. * The infection can spread from user to user. * As soon as the superuser runs an infected program, the virus can get superuser privileges. Ole Kristensen ========================================================================= Date: Fri, 1 Jul 88 22:09:17 PLT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Andrew Vaught <29284843@WSUVM1> Subject: UK Virus Crossposted from RISKS digest: ------------------------------------------------------- ======================================================================== Date: Fri, 1 Jul 88 10:36:42 CDT From: Will Martin -- AMXAL-RI Subject: New UK Virus The following is a complete item from the FEDERAL BYTES column (p. 42) of the June 27, 1988, issue of Federal Computer Week, which just arrived in today's mail (July 1): Oh, No - Not Maggy! Sources of reasonable reliability within the British Ministry of Defense (MoD) report that a computer virus has broken out. It seems that MoD uses a number of Macs, largely for graphics but some of them for word processing. Whenever anyone writes "Margaret Thatcher" or "prime minister", the screen [image] vanishes, along with whatever was on it. In the place of the missing document appears a picture of Maggy, with a Union Jack behind her. MoD, say our sources, has not found a cure. --------------------------------------------------------- Does anyone know anything else about this? If true, this is probably an example of someone infecting a computer `manually' and leaving it sit for someone else to trigger. Digitized pictures on the mac can take up quite a bit of space (20-30k?) on a disk, that would probably be easy to notice. Then again, on macs, the only place it tells you how big your file is is when you ask for a `by-name' description, and even then sizes are only given in kilobytes. Andy ========================================================================= Date: Fri, 1 Jul 88 18:04:14 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Joe Sieczkowski Subject: Questionable Ads Over the course of the last 6 months, I've seen numerous questionable ads concerning virus protection software. However, the one SysteMate Incorporated placed in the June 6'88 Info-World on page 58 takes the cake. The ad starts with the caption "You had better STOP VD, before it stops you", and follows with the typical scare-tactic approach. In the ad, SysteMate states that SecurMate is "the only software package that GUARANTEES you protection against all strains of VD." Furthermore, it seemingly (<- note this word) challenges anyone who breaks the program a 60% controlling interest in the company. If that's not incentive, what is? I can picture everybody and his brother trying to develop viruses to do this. Personally, I lock horns with enough viruses, I don't need more. I took the liberty of calling the company. I know there is no 100% effective "software" method of protecting a PC (an unsecure system where real memory and the i/o ports can be directly addressed). During my conversation with one of the technical people (an ex-NSA person no less), I questioned the method of protection. Although quite sophisticated, I proposed a viral method which could probably circumvent the protection. (I rather not go into the specific method here.) However, this method implied that I put a PD piece of software on the system containing the virus. The answer I received was something like "How can you expect your system to be secure if you subject it to untrusted software." To which I replied, "If all my software was trusted, I wouldn't need your package." At this point I inquired about there offer. Apparently their offer of "breaking there system" implies being able to read a message that they ran through their one-way encryption scheme. The end of the article stated "our highly satistfied customer base, each with hundreds or thousands of copies installed, include the Austrailian Postal Department, Chase Manhatten, Citibank, Donaldson, Dupont, EXXON, General Motors, Generall Electric, Honeywell, IBM, Mobil, NSA and other government entitlies, Nynex, Pacific Telesis, Prudential, Rockwell International and many others." I didn't check this out, but I find it hard to beleive. (If your from one of these organisations, please comment.) Perhaps all of these agenties bought an evaluation copy. Misleading advertising on this area has run rampant. ========================================================================= Date: Fri, 1 Jul 88 11:42:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: WHMurray@DOCKMASTER.ARPA Subject: Re: Some BYTES from fidonet (sorry) In-Reply-To: Message of 30 Jun 88 18:00 EDT from "Len Levine" Hurrah for Lee Kemp! That is an incredibly valuable piece of work. I wish that I had said it. While the INTERNET is not quite as open as FIDONET, there are numerous gates and lots of traffic between them. Therefore, whatever applies to them applies equally to us. As I reported earlier, work is going forward. 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: Fri, 1 Jul 88 11:09:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: WHMurray@DOCKMASTER.ARPA Subject: Re: do you believe in magic? In-Reply-To: Message of 30 Jun 88 18:48 EDT from "me! Jefferson Ogata" >God forbid that anyone should actually write an operating system or >compiler. Just think of the damage that would cause to everyone's >data. It's THIS kind of unjustified fear (superstition) that prevents >progress along so many different paths. A virus is a PROGRAM. That >program has certain characteristics that one can use to one's advan- >tage. It seems to me that a number of people out there are terrified >by one word: 'virus'. This fear of viruses prevents them from even >considering the possibilities for code using viruses. It is not the wand that we fear. It is not even the magician. It is the apprentice. We are particularly afraid of the apprentice who thinks that he knows what the magician does not even pretend to know. >The simple truth is that viruses ARE controlled entities. They do what >they are supposed to do when they are properly written. The COMMAND.COM >virus, for example, infects COMMAND.COM. It performs a deterministic >action on COMMAND.COM, then trashes the disk. It doesn't infect other >environments, only those running under DOS with COMMAND.COM. It would >be difficult, in fact, to write viruses with potential for infecting >multiple environments. For example, the above suggests to me that the author does not understand the difference between the execution environment and the system population of which it is a part. The creators of the Pakistani virus could predict exactly how it would behave in a PC; they had no idea how it would behave in the world. The creator of the XMASCARD knew how it would behave in a CMS environment. He might make some intelligent predictions about how it would behave in BITNET. He could not possibly have known how it would behave in VNET even if he could have predicted that it might end up there. It is not the potential for infecting multiple unlike environments that concerns me. It is the ability to know the extent of the intended environment. >It would >be difficult, in fact, to write viruses with potential for infecting >multiple environments. True. A virus is target specific. For example: >If we're following the analogy of biological >viruses, consider how they work, which is quite similar to computer >viruses. A biological virus consists of a head and some legs. The virus >has a key which matches a particular site on a cell, called the active >site. Viruses can only infect those cells that have an active site on >them corresponding to the virus key. This site is the location where >the virus DNA material is injected. Because of this, biological viruses >are well-suited to the fighting of cancer. If a virus can be tailored >to find an active site that exists only on cancer cells, it will >destroy >cancer cells throughout the body. When there are no more cancer cells, >the virus will die. If biological computers can be added to these >viruses, they can be programmed to die after n generations, thus >preventing the possibility of spread to other animals whose cells might >carry the same active site. Which, of course, admits of the very danger that concerns us. That is, that there is something in the environment, unknown to the creator of the virus, that is vulnerable to it. Cancer has demonstrated itself to be highly resistant to many strategies. We might be justified in taking some risk to deal with it. Almost any problem that will yield to a program virus, also yields to other programs without the uncertainties of a virus. Of course, Mr. Ogata does not admit to much uncertainty. And, I am sure, that he can hypothesize some problem that will justify continued experimentation on which so many seem bent. One can only argue for the truth that he sees. 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: Fri, 1 Jul 88 10:57:51 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "David M. Chess" Subject: Forwarding a colleague's reply A colleague had the attached reaction to the signature-authentication idea that the FidoNet article suggests. (My own reaction is that Kemp dismisses the possibility of CRC-type protection way too lightly; "can be easily bypassed", indeed!) Perhaps someone with the right access could send it on its way back to Mr. Kemp? DC Re: Lee Kemp's FidoNet article As I see it, the purpose of this 'tamper-proof' packaging is to prevent the program from being infected from the time it leaves the author or factory until it reaches my hot little hands. This has several advantages over the current state of affairs, and should be encouraged, but also leaves plenty of exposures. The advantage of the scheme is: * One can be quite sure that the product has not been tampered with since its encryption. If it comes from a commercial manufacturer, listing the public decryption key in the docs, one can be sure that one has the right program and that it hasn't been infected since its packaging. Disadvantages/Exposures: * In the case of shareware, a malicious person could decrypt the program, infect it, and then re-encrypt it with a new pair of keys. Wily Hacker could then pose as the author on any bulletin board not requiring user authentication, and thereby spread the infected version. Soon there are two or more versions of the program (with different keys) floating about, and people will not know which one is the clean one. Considerable FUD. Some will be infected before discovering that there is a danger, as the result of a false sense of security brought on by the nature of the packaging. * If the developer's machine is infected, then there is a very good chance that the new program will be infected. This scheme would not have prevented the Aldus Freehand/MacMag incident. * Boot block and operating system viruses will continue as usual. * If your machine is already sick, this does not prevent it from infecting the executable once you have removed the protective packaging. * An infected encryption/decryption program could do all sorts of nasty things. Dan Hankins ========================================================================= Date: Tue, 5 Jul 88 09:10:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Shawn V. Hernan" Subject: stupid question Can someone please tell me what CRC protection is? I don't know much about this sort of thing, and I just want to learn. Shawn Hernan University of Pittsburgh please mail ( don't post) to valentin@pittvms.bitnet ========================================================================= Date: Tue, 5 Jul 88 09:35:22 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: Over the weekend problems with LISTSERV Dear readers: Over the long (Fourth of July) weekend, our LISTSERV ran out of disk space for the VIRUS-L archive files, and subsequently stopped sending out any submissions. The problem has been fixed, but some submissions were held over the weekend, and some users may have had difficulties accessing the archive files. I do not believe that any submissions were lost, however. Once the LISTSERV was re-started this morning, all of the held submissions were then sent out to the list. I apologize for any inconveniences that this may have caused. 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, 5 Jul 88 09:52:46 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: forwarded comments on OS/2 from David M. Chess Date: 1 July 1988, 09:38:00 EDT From: David M. Chess CHESS at YKTVMV To: VIRUS-L at LEHIIBM1 Subject: OS/2 and viruses I'd like to correct a little more misinformation, about OS/2 this time. Note that all this is just my understanding of the case, and in no sense Official Word from my employer (on the other hand, I'm pretty sure that I'm right!). It's very simple (just a line in CONFIG.SYS) to bring up OS/2 in a mode where there is no DOS box. DOS-only programs (including DOS-only viruses) will not run on a machine configured that way. So if you consider the DOS mode a risk, you can easily turn it off. On the other hand > the hardware memory management of the new processors will > defeat any attempt at cross-process infection by viruses of > the (in DOS terms) .COM/.EXE-hidden kind is not quite true, I don't think. COM/EXE viruses typically spread by altering other executables as they exist as files on disks. "hardware memory management" isn't relevant to this kind of infection (it protects memory, not disk images). Even the typcial disk-image protection only protects one's executable files against writes by *unauthorized* users and processes, but these viruses tend to spread Just Fine by way of *authorized* users and processes. (That is, if George is authorized to write to 25 executable files, and George gets an infected program and runs it, those 25 executables are going to get infected (and so are the executables of anyone else who runs them) no matter *how* "unbreakable" the disk protection is in the usual sense.) * Most traditional "security" and "protection" schemes provide little hindrance to viruses. DC 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, 5 Jul 88 14:20:48 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: me! Jefferson Ogata Subject: Bill Murray's fears You don't fear the wand; just the apprentice? What makes you think the apprentice isn't already out there? What I propose is intelligent use of viruses by professionals. The apprentice is irrelevant. The appren- tice will go about his business whether others write useful viruses or not. And your whole viewpoint indicates a vast misconception of the relationship of viruses to other useful programming tools. Consider the biological viewpoint once again: we use only existing animals and plants as resources. We do not design them. This is where the biological analogy becomes useless. You seem to be arguing that it is dangerous to utilize gene-altered viruses for biological purposes. What about gene-altered cows? Aren't they just as dangerous in that they might have unpredictable effects through hormonal secretions in milk? Any gene-altering introduces new possibilities into an environ- ment. But programs are ALL gene-altered. We're not discussing a brand new area of exploration such as gene-altering. We're merely discussing the use of one particular type of gene-altering. All programs are the result of human intervention. Why is it that we don't have accidental Trojans running rampant? It's because people write programs according to general guidelines such as "use files to store data". Programs that use whole disk tracks to store data regardless of the file system would do heavy damage to peoples' data. What I've been working up to is this: people need a set of guidelines they can use in the writing of beneficial viruses. Perhaps operating system support could even be used. Virus managers and whatnot. It is obvious that without any knowledge of infection-modes and environments, idiots will write stupid viruses. But I believe viruses should be regarded in the same way as "normal" programs. There are correct ways (apart from style) to write all programs; why not viruses? And don't come back with remarks about hubris, how I don't know anything, and why people won't follow guidelines. There ARE malicious people out there. They aren't writing beneficial viruses, and they don't care about beneficial viruses. The worst thing beneficial viruses could do is provide a vehicle for transport of malicious viruses. As if there aren't already enough vehicles. As to the question of unpredictable virus spreading, if the necessary virus protection methods ever get developed and installed, it won't be possible for ANY virus to spread uncontrollably. In the meantime, viruses are already strictly limited in their environments; as I said before, it's HARD to write viruses that can live in multiple environments. Computer environments are nothing like biological environments, where biological hardware has common elements between organisms. Even if two computers have the same processor, it will be difficult to get a virus to spread between them if they use different operating systems. And appropriate guide- lines might precisely limit environments. By the way, things like CHRISTMA EXEC require gross stupidity and care- lessness on the part of the target user. I don't think this case is a good model for any conclusions. The spread of this virus was the fault of the users as much as the writer, if not more. And this program is also a network virus, not a program-infecting virus, so once again it's a poor model. - Jeff ========================================================================= Date: Tue, 5 Jul 88 16:08:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Woody Subject: intro to CRC in 1,000 words... "Shawn V. Hernan" writes, >Can someone please tell me what CRC protection is? I don't know much >about this sort of thing, and I just want to learn. I think its appropriate to post a quickie overview of what CRC, or Cyclic Redundancy Check, protection can do for you. In essence, what one is trying to do is write down a number associated with your data that will help you know whether or not the data has been altered. Originally, it was intended as a means of telling whether or not a message was transfered correctly: if the CRC of the transmitted message wasn't a pre-agreed upon value, the sender knew to try again. So keep in mind that what it was designed for is to detect "random" errors in transmission. The simplest example of a CRC is what is called "even" parity. What the sender does is express his message in binary, count the number of 1's, and append a 1 or a 0 to his message depending upon if that number is odd or even. The reciever then looks at what he's recorded, and if the total number of 1's in the message is even, he is happy - throws away the last bit (the parity check bit) to recieve the message. If the total number of 1's is odd, then he asks the sender to retransmit. The problem with something this simple is that while it will tell you something is wrong if exactly one bit was garbled, it won't tell you if something is wrong if exactly two bits were garbled. (It detects the error only if an odd number of errors were made.) There is a natural way to improve this - instead of working with just [number of 0's and 1's mod 2] use something a bit more detailed. Suppose you are working with (base 10) numbers, and are trying to send a message to a friend. What you agree to do is send the number, and then send a single digit that is the sum of the digits, then summed as many times as needed to get a single digit. For example, suppose you wanted to send the number 2,147,483,648. Since 2+1+4+7+4+8+3+6+4+8 = 47 => 4+7 = 11 => 1+1 = 2, so you would send 21474836482. Your friend would strip off the last digit (2), and then add up the digits to make sure they added up to two. If he dropped a digit, it would be detected. If he changed a 2 to a 3, a 4 to and 8, and a 1 to a 9, it would be detected, etc. Mathematically, what you are doing is sending the remainder after dividing the original number by nine. (Nine is convienent because it is one less than the base.) The basic idea of CRC is to consider the message (or datafile) as one gigantic binary number, compute the remainder after dividing by a large binary number, tack that onto the end of the message, and send it. Choice of the "large binary number" is made upon certain grounds of primality or other properties: since you are mapping a larger set (all messages) into a smaller set (the residues) you want to ensure that all the residues are covered, they are all hit about equally often, no two messages are too "close", etc. If the adversary is random - i.e. a noisy telephone line or the like - and so changes are made to bits at random, then mathematically one can show this is an excellent form of protection. However, the malefic forces we are trying to protect against are not random. For example, suppose our virus is trying to scramble our data file, and knows we are going to use a parity check. As long as the virus is careful enough to always make EXACTLY an even number of changes, the CRC won't detect it. Similarly, if the virus changes our base ten number by a multiple of nine, we won't detect it. But if it changes our base ten number by something that ISN'T a multiple of nine, we WILL detect it. This is where the discussion of the "random CRC polynomial" comes in. The idea is that even if you restrict yourself to, say, a 16-bit check tacked on the end (where the odd-even scheme is just a 1 bit check) you have a great deal of leeway. You need to divide by a 16 or 17 bit number (so you have a 16 bit residue) and you want to use a prime number (for mathematical reasons) but you don't have to use a specific one. The virus can protect itself from detection by a single residue check, but it is very hard to protect from ALL the residue checks. For example, suppose we are going to do at most a 4 bit residue. We might record our message plus the remainder after dividing by 2, 3, 5, 7, 11, or 13. The virus changes message to message*. If we used all of the checks, then the residue of message* under 2, 3, 5, 7, 11, and 13 would have to be the same as under message - and to accomplish that, message* would have to be the same as message, up to 2*3*5*7*11*13 = 30,030. For four bit protection, we're able to assure integrity up to a fairly large degree of accuracy. (In particular, if we never sent more than 14 bit messages, we could be sure it was right!) Of course, we probably aren't going to use every one of those, but if we just picked one or two, and someone else chose a different one or two, etc, someone will detect the garbling. The mechanical details of CRC are rather interesting, and the mathematical details are quite beautiful (sitting squarely in number theory and field theory). Almost any upper division textbook on the general subject should have some information about it. It is quite accessible, and I'd recommend it to anyone curious about the subject. woody WWEAVER@DREW.bitnet ========================================================================= Date: Tue, 5 Jul 88 17:40:56 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Otto Stolz +49 7531 88 2645 Subject: Receiving multiple files under VM/SP 5 Hello folks, as we had discussed in VIRUS-L back in June, a file could inadvertently be RECEIVEd under CMS Release 4 (and the earlier releases) -- if this file was hidden as a second partition in a NETDATA file. This was unanimously considered a dangerous feature, as the hidden file could be some trojan horse, e.g. a PROFILE EXEC which would become active at the next LOGON. Meanwhile, I've tested this feature under CMS Release 4 and the official antidote of CMS Release 5. Thanks to everybody who helped with sending double-edged files and/or remarks to me. This note is meant as a digest of my findings. A NETDATA file ============== containing a note and an attached data file can be sent from a MVS/TSO installation to a VM/SP installation by one of these commands: > TRANSMIT node.user DSN(fn.ft) MESSAGE > TRANSMIT node.user DSN(fn.ft) MSGDSNAME(msgfile) where: fn ft are the two components of the CMS file-id (up to 8 characters, each); node user are the two components of a BITNET or EARN address; msgfile is the MVS file-id of the note to be sent. Under Release 4, ---------------- the VM/SP user sees two files in one message, separated by a double line, when PEEKing at the NETDATA file before RECEIVing it (as one should always do :-). After issuing RECEIVE, he will receive a note AND a file -- and he will only be informed of the former. If a NETLOG file is kept, both the note and the data file will be logged therein, e.g.: > Note JAMES NOTE A0 recv from JAMES at XXXXXXX on 06/22/88 10:04:20 > File HELP EXTRACT A recv from JAMES at XXXXXXX on 06/22/88 10:04:20 sent as JAMES.TRANSMIT.HELP.EXTRACT For long files, which cannot be PEEKed in their entirety, this feature indeed constitutes a severe safety threat. The SENDFILE, NOTE, and RECEIVE commands use a module DMSDDL for sending/ receiving NETDATA format files. DMSDDL is documented in DMSDDL ASSEMBLE. I suppose, there's a modified DMSDDL MODULE available for node admini- strators from their nearest backbone LISTSERV, that will avoid receiving hidden files, in Release 4. With Release 5, --------------- the RECEIVE command has been enhanced with a new triple of options: FULLPROMPT, MINPROMPT, and NOPROMPT. With FULLPROMPT, or MINPROMPT (default), RECEIVE will no longer write a file to the user's disk with- out his consent. As there have been added *new options* to the command syntax, I had expected to read about this enhancement in the "Release 5 Guide", or in "Using Release 5 Enhancements". But this change of the command syntax isn't mentioned there at all (perhaps a mere oversight -- or perhaps an inter-release enhancement not considered worth to be repeated in these manuals); on the other hand, some trifling details (e.g. look up RECEIVE in the index) are covered. I regret my rash, inappropriate remark of 21 June on this account. The new prompt allows the user to receive every partition of a NETDATA file under the name given, or under a new name chosen by the user, or to deny receiving it. If any partition of a file is not received, then the whole partitioned file remains in the user's reader. BTW, as any new prompt, also this one constitutes an incompatibility between Release 4 and Release 5: a disconnected machine running into an unforeseen prompt will stall (and will be forced after 15 minutes)! Furthermore, the PEEK command displays two message lines, containing the note's and the appended file's file-ids. I'll keep a file with a Release 5 sample dialogue for another fortnight. Anybody interested in it please drop me a short note. CP SPOOL PUN CONT ================= is another CMS possibility to create multiple files in another person's reader, as mentioned before in VIRUS-L. Under Release 5, these files can be overcome: they can be RECEIVED into one single, harmless disk file. If they are read in using READCARD, however, they are separated into several single disk files; this happens under user control if he has specified the new FULLPROMPT or MINPROMPT options. As opposed to RECEIVE, READCARD defaults to the NOPROMPT option. Hence, if you want to be on the save side, be sure to use READCARD always with the MINPROMPT or FULLPROMPT option! Regrettably, the CMS DEFAULTS com- mand does *not* apply to the READCARD command. That's all for now. Best regards Otto ========================================================================= Date: Wed, 6 Jul 88 07:59:23 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: forwarded info on NASA virus from Keith Peterson From: Keith Petersen Subject: FBI to investigate rogue computer program at NASA FBI TO INVESTIGATE ROGUE COMPUTER PROGRAM AT NASA NEW YORK (JULY 4) UPI - NASA officials have called on the FBI to investigate a rogue computer program that has destroyed information stored on its personal computers and those of several other government agencies, The New York Times reported today. The program was designed to sabotage computer programs at Electronic Data Systems of Dallas, the Times said. It did little damage to the Texas company, but wreaked havoc on thousands of personal computers nationwide, company spokesman Bill Wright told the newspaper. Although damage to government data was limited, NASA officials have asked the FBI to enter the case since files were destroyed, projects delayed and hundreds of hours spent tracking the electronic culprit at NASA and at the Environmental Protection Agency, the National Oceanic and Atmospheric Administration and the United States Sentencing Commission. It was not known how the program, which damaged files during a five-month period beginning in January, spread from the Texas company to networks of personal computers and whether it was deliberately introduced at government agencies or brought in accidentally, the Times said. The computer program is one of at least 40, termed ''viruses,'' now identified in the United States, computer experts said. Viruses are designed to conceal their presence on a disk and to replicate themselves repeatedly onto other disks and into the memory banks of computers. The program currently being investigated is called the scores virus, the newspaper said. Some government officials say viruses are spread through informal networks of government computer users who exchange publicly available software. Viruses often lie dormant and then explode on a certain day or on contact with a specific computer program. They can erase entire disks, such as happened with a one word virus that flashed the word ''Gotcha!'' Kenneth R. van Wyk Hobbes: Wow, buried treasure right User Services Senior Consultant where you said it'd be! A Lehigh University Computing Center wallet full of money! Internet: Calvin: Yeah, it's Dad's. I buried it BITNET: here last week! ========================================================================= Date: Wed, 6 Jul 88 09:43:08 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Joe McMahon Subject: Scores Arrest A quote from the Washington Apple PI Journal this month: "Donald Burleson of Fort Worth, TX has been arrested on felony charges as the creator of the Scores virus. If convicted of 'harmful access to a computer' he faces up to 10 years in jail. He is accused of executing programs 'designed to interfere with the normal use of the computer' and of acts 'that resulted in records being deleted.'" Those sure are wide-open categories as crimes, aren't they? --- Joe M. ========================================================================= Date: Wed, 6 Jul 88 11:36:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Jim Shaffer, Jr." Subject: RE: Scores Arrest >A quote from the Washington Apple PI Journal this month: >"Donald Burleson of Fort Worth, TX has been arrested on felony charges as >the creator of the Scores virus. If convicted of 'harmful access to a >computer' he faces up to 10 years in jail. He is accused of executing >programs 'designed to interfere with the normal use of the computer' and >of acts 'that resulted in records being deleted.'" >Those sure are wide-open categories as crimes, aren't they? Wide-open? You bet. Everybody at this site has been guilty of "(interfering) with the normal use of the computer" at one time or another :-) Nevertheless, you can't believe how happy I am that someone's gotten nailed for writing a virus. The only problem is, how is anyone sure that it's him? Anybody have any further info? _______________________________________________________________________________ | James M. Shaffer, Jr. | Bitnet: shafferj@bknlvms | | P.O. Box C-2658 | Internet: shafferj%bknlvms.bitnet@cunyvm.cuny.edu| | Bucknell University | UUCP: ...!psuvax1!bknlvms.bitnet!shafferj | | Lewisburg, PA USA 17837 | CSNet: shafferj%bknlvms.bitnet@relay.cs.net | ------------------------------------------------------------------------------- | "He's old enough to know what's right and young enough not to choose it; | | He's noble enough to win the world but fool enough to lose it." | | -- Rush, "New World Man", on _Signals_ | ------------------------------------------------------------------------------- ========================================================================= Date: Wed, 6 Jul 88 16:01:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: WHMurray@DOCKMASTER.ARPA Subject: Re: Scores Arrest In-Reply-To: Message of 6 Jul 88 09:43 EDT from "Joe McMahon" >Those sure are wide-open categories as crimes, aren't they? I think they call that "frontier justice." I understand that you can still be hung there for rustling cattle (but not for shooting your wife). Yes, they are wide open categories. However, there must be very narrow specifications. It will be interesting to read them. My recollection is that SCORES had very specific targetes within EDS. Not exactly a "let's turn it loose and see what happens." Bill ========================================================================= Date: Thu, 7 Jul 88 10:32:57 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: David.Slonosky@QUEENSU.CA Subject: Removable hard disks I just saw in the July issue of BYTE magazine that they now have removable hard disks, something that has been suggested as being desireable for viral protection. Thus, you could have two formatted hard disks, one for using with suspicious code and one for normal use. Of course, this would not make your system virus proof if the proper precautions weren't taken, but it is another tool in the fighting of virii and such. David Slonosky ~ Know thyself? Queen's University ~ If I knew myself, Kingston, Ontario ~ I'd run away. ========================================================================= Date: Thu, 7 Jul 88 10:39:04 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: David.Slonosky@QUEENSU.CA Subject: VAX/CMS and transportable virii I routinely use YTERM and a two floppy IBM compatible to transfer data to and from the mainframe. I know that it has been suggested that a virus could be written on an AT with the proper code to transfer to a VAX/CMS environment, but would it be possible to design one that would be transparent to DOS and still be transmitted upon file transferring? What about having one tacked on to the end of a program which got activated somehow? I guess what I'm asking are 1) are security measures strong enough to prevent a virus from coming "alive' in this fashion and 2) is this sort of thing possible in the first place? (Actually, these should be reversed, but I'm only working on my second coffee this morning (8*-).) David Slonosky ~ Know thyself? Queen's University ~ If I knew myself, Kingston, Ontario ~ I'd run away. 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