From: Will Martin __ AMXAL_RI 4-MAR-1988 18:47 To: Clement Taylor Subj: [40970] Re: BITNET Security [Moderator note: part 1 of 2. _H*] Here is a compilation of data on the CHRISTMA EXEC virus which I collected from postings in the RISKS Digest: Regards, Will Martin ***Begin Included Messages*** From: minow%thundr.DEC@decwrl.dec.com (Martin Minow ML3-5/U26 223-9922) Date: 11 Dec 87 11:55 Subject: Yet another virus program announcement fyi From CRTNET, number 115. From T3B%PSUVM.BITNET. Subject: Christmas Virus Warning If you are at a CMS site and receive a program called CHRISTMA EXEC, please (a) warn your postmaster and (b) discard the exec (or keep a copy for the postmaster to look at, but DO NOT RUN IT). This exec paints a Christmas tree on your screen and then sends itself to everyone named in either your NAMES or NETLOG files. The result is potentially serious stress on Bitnet and on your local spool system, and possibly a few system crashes here and there as the number of reader files soars and exceeds the maximum. The Christmas tree isn't all that pretty, and the joke is pretty mean. A word to the wise. Your postmaster will thank you. Michael Sperberg-McQueen ------------------------------ From: davy@intrepid.ecn.purdue.edu (Dave Curry) Subject: IBM invaded by a Christmas virus Date: Sat, 12 Dec 87 10:02:24 EST (From the Lafayette (Indiana) Journal & Courier, December 12, 1987. Quoted without permission.) IBM Woes -- Computerized grinch jams the mail BINGHAMTON, N.Y.- A computerized Grinch invaded IBM's electronic mail Friday. An illegal software-style so-called Christmas card sent through IBM's electronic mail jammed desk-top computer terminals, spokesman Joseph E. Dahm said. The so-called virus program forced plant officials to turn off internal links between computer terminals and mainframe systems to purge the message, Dahm said. IBM sources say the link was off from 45 minutes to 90 minutes depending on the location. The program is known as a virus because it enters computer programs and replicates itself automatically. Curious employees who read the message titles "Christmas" in the morning electronic mail discovered an illustration of a Christmas tree with "Holiday Greetings" superimposed on it. A caption advised "Don't browse it, it's more fun to run it." "That was the hook," an IBM source said. "A lot of people thought they could take a peek and then kill the message, but once opened, it was too late." The program automatically entered a security log listing contacts made from the individual computer terminal, duplicated and mailed itself to new victims. Like a Pandora's Box, once opened, the program rarely accepted commands to stop, sources said. Operators who turned off their terminals to stop the Christmas message lost electronic mail or unfinished reports not filed in the computer. This article seems to have a lot of things in it that the reporter didn't understand. I assume that the "terminals" in question are really PC's connected to the mainframes; for one thing. Plus, I presume the "Don't browse it" refers to the VM/CMS "BROWSE" command used for looking through files, and not just to the regular English word. Does anyone have any more info from a source which understands all the big words? --Dave Curry, Purdue University ------------------------------ Date: Mon, 14 Dec 87 09:38:55 est From: Franklin Davis Subject: IBM invaded by a Christmas virus This article seems to have a lot of things in it that the reporter didn't understand. I assume that the "terminals" in question are really PC's connected to the mainframes; for one thing. Probably the users were connected by 3270 type terminals (or emulations on a PC) which use a half-duplex block mode protocol. If you turn off such a terminal your session is aborted, and you lose current edits. It is also very difficult to interrupt an executing program, since it "owns" the line. There is a "system-attention" key, but a busy system may take literally minutes to respond. (I'm glad I don't have to use an IBM mainframe any more!! :-) --Franklin Davis Thinking Machines Corp. fad@think.com ------------------------------ Subject: IBM Xmas Prank Date: Fri, 18 Dec 87 10:03:57 -0500 From: Fred Baube From Friday's Washington Post, excerpted without permission. "The message popped onto desktop screens in IBM offices around the country and even crossed the Atlantic and Pacific oceans, showing up in IBM outposts in West Germany, Italy and Japan." [as pictured X in the article] X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X A very happy Christmas and my best wishes for the next year. Let this run and enjoy yourself. Browsing this file is no fun at all. Just type Christmas. ________ "The message that bedeviled IBM was a comparatively benevolent one and did not, as computer tricksters' creations sometimes do, destroy other material in the system .. [although] rapidly producing electronic gridlock." "The culprit is unknown .. but preliminary investigation suggests that the message originated outside the company. IBM's mail system is attached to those of several other institutions." "From start to finish, the message survived only hours .." "Does the world's biggest and most advanced computer company feel embarassed about its Christmas chain ? 'We didn't want it to happen, but we anticipated something like this might be attempted and we were prepared to deal with it.'" Questions: (1) An incoming message can contain an executable program, that can easily be run ? (2) Such a message can be remailed under its contained program's control, presumably with the name of the last victim in the "From:" field ? (3) Can IBM trace it to an originator, or was anonymity possible ? (4) How/where can readers of RISKS submit something similar ? (strictly for professional testing purposes) (5) Is the Internet similarly vulnerable ? The prank seems to be benign, and therefore beneficial. IBM seems to have dealt with it effectively (or have they ?). Browsing this message is no fun at all. Just type Christmas .. [Bay Area folks can read a long front-page article by John Markoff on viruses in today's SF Chronicle-Examiner. PGN] ------------------------------ Date: Mon, 21 Dec 87 15:22:26 EST From: Ross Patterson Subject: Re: IBM Christmas Virus There have been several messages to RISKS lately about the CHRISTMAs EXEC virus on IBM's network. This was an extension of the same problem on BITNET and its European counterpart, EARN. Since I raised the general alarm about it, I'd like to answer a few questions. The virus used two standard CMS files, called NAMES and NETLOG, to help it infect other users. The NAMES file contains a list of userids and system names that you correspond with frequently, allowing you to abbreviate them to a mnemonic nickname when sending mail, files, or interactive messages. I composed this mail by sending to "RISKS", which my NAMES file lists as user RISKS on system KL.SRI.COM. You can also list phone numbers, paper addresses, etc. There is a commonly available program that will print off a personal phonebook from your NAMES file ("Traveling Sidekick" from the days BB - Before Borland). The NETLOG file lists all users you've sent mail or files to, or received them from. It's a very nice audit trail when you're trying to remember where you got that copy of Space Wars. After typing the Christmas Tree on your terminal, the virus proceeded to read both the NAMES and NETLOG files to get a set of target addresses. It then sent a copy of itself to each of them, and finally deleted itself. >I assume that the "terminals" in question are really PC's >connected to the mainframes; for one thing. The terminals mentioned are generally IBM 3270's, and PC's with IRMA-type cards. The virus ran on the host system, not on the PC. >Plus, I presume the "Don't >browse it" refers to the VM/CMS "BROWSE" command used for looking through >files, and not just to the regular English word. Both, actually. The intent was obviously to stop the reader from going further down into the file, where the real purpose of the program was quite obvious. The language used (IBM's REXX) is usually interpreted, so the program was sent in source form. Anyone who bothered to read below the second screen-full (like all of us paranoid Systems Programmers) began to see the trouble. It was slightly cloudy, as all the variable names were in German, but seeing was fair to good. >The culprit is unknown That is no longer the case. The culprit has been tracked down, and barred from access to his/her system. A note to that effect was broadcast to a number of mailing lists by the General Secretary of EARN. The source system had recently been attached to the West German section of EARN, and the user who started it all only intended to send a greeting to a few friends. To quote a TV commerical, "... and they'll tell two friends, and so on, and so on, ...". > .. but preliminary investigation suggests >that the message originated outside the company. IBM's mail >system is attached to those of several other institutions." Quite so. No one seems quite sure which of the gateways between BITNET/EARN and IBM's internal network, VNET, passed the first copy of the virus. It matters very little, since it found the VNET environment even more conducive to reproduction than BITNET/EARN. VNET'ers apparently keep much larger NAMES files than BITNET'ers. It wasn't long before the links were carrying more CHRISTMA EXEC's than anything else. >"From start to finish, the message survived only hours .." Per copy, perhaps. The first known instance of infection was at about 1300 GMT on Wednesday, December 9. Within BITNET, it was generally stamped out by the following Monday, December 14. On VNET, it didn't show up until a day later, and was mostly killed in a massive network shutdown on Friday. >(1) An incoming message can contain an executable program, > that can easily be run ? Yes. Please remember that the Internet is not the only network style in the world. In BITNET and VNET, mail is just another case of file transfer. File transfer is performed by the sender, not the receiver. These are store-and-forward networks, so the path from system A to system B need not be intact for the duration of the transfer. The viral program was transferred as a normal file, not as mail. >(2) Such a message can be remailed under its contained program's > control, presumably with the name of the last victim in the > "From:" field ? It wasn't mailed. Thus, there wasn't any From: field, etc. It did carry the system name and userid of the most recent victim, but not any trace-back information. >(3) Can IBM trace it to an originator, or was anonymity possible ? A task force of BITNET and EARN systems programmers traced it back to its source, by the usual disease-control procedures: Doctor: "Miss X, you've got a nasty case of viral . Who have you had contact with recently?". Miss X: "Just a moment, I'll check my notebook." A byproduct of the tool used to transmit the virus is an entry in the NETLOG file listing the userid and system name of anyone it was sent to, making it easier than usual for Miss X to remember. In some cases, the user had suppressed the NETLOG facility, but that is the exception, not the rule. >(4) How/where can readers of RISKS submit something similar ? > (strictly for professional testing purposes) Noplace safely. Please don't try it on anything but an isolated network, and then coldstart your spool afterwards. >(5) Is the Internet similarly vulnerable ? Not to this one. It plays on several things that the Internet doesn't have: 1) A large number of IBM VM/CMS systems. The program would only run in a CMS environment. There is no reason one couldn't write something similar in any other language, though. 2) A suitable file transfer system. FTP doesn't apply. It must provide a way for a user to receive an unsolicited file, in a runnable form. 3) A good method of determining targets. The CMS NAMES and NETLOG files provided an excellent source of information. I suppose in a Unix environment, ".alias" and "/etc/aliases" would be ok, but .alias is comparatively rare, while NAMES files are almost universal in CMS. >The prank seems to be benign, and therefore beneficial. That is being debated in several circles. I, for one, agree with you. >IBM seems to have dealt with it effectively (or have they ?). Yes, they have. >Browsing this message is no fun at all. Just type Christmas .. The lesson of this one is the same as for PC viruses: Never run something you don't recognize. When the virus first appeared, several people suggested that it was the work of students, and that it might be used negatively in an ongoing argument over whether students belong on BITNET. When we heard that "professionals" inside IBM were also running programs they didn't recognize, that particular suggestion vanished. This virus was quite sly, in that by sending itself to people listed in your NAMES and NETLOG files, those people would recognize the source (you) as a friend, and be generally less inquisitive, until things got nasty. Lesson #2: Even your friends sometimes make mistakes. Ross Patterson, Rutgers University [RISKS received an unusually large number of messages on this subject -- from Fred Baube, John Owens (2), Allan Pratt, Anne Louise Gockel, and Bruce O'Neel. I started trying to edit them down, but rapidly gave up that strategy -- inordinate overlap. So, I will take a new tack, which is to put out Ross' message -- which was the most comprehensive -- and then give Fred, John, Allan, Anne and Bruce first priority if THEY wish to comment marginally or additionally thereupon. Please be terse -- and avoid replicating ALL of the foregoing text in your messages, as some of you have been doing. (One of the joys of mailers?) PGN] ------------------------------ Organization: The MITRE Corp., Washington, D.C. Subject: The Christmas Card Caper, (hopefully) concluded Date: Mon, 21 Dec 87 11:45:03 EST From: Joe Morris (jcmorris@mitre.arpa) The following item was posted on the VMSHARE bulletin board. It describes the origin of the CHRISTMAS EXEC file, and makes valid points about the inability of computer systems to automatically recognize some types of ill-behaved programs quickly enough to prevent damage to a network. (VMSHARE is a closed bulletin board operated for the use of VM installations who are members of SHARE, the large IBM mainframe user group. Shadow copies of the VMSHARE traffic are distributed to many other nets, including VNET and BITNET.) Joe Morris (jcmorris@mitre) Append on 12/19/87 at 20:10 by Melinda Varian : The following statement, from a member of the EARN Board, answers the queries about the origin of the CHRISTMA EXEC. Clausthal-Zellerfeld is quite a new VM installation. When Heinz Haunhorst, of their staff, was notified that the first appearances of the virus on the networks originated at his node, he pursued the matter vigorously and skillfully. Helmut Woehlbier, of the Technical University of Braunschweig, also did an excellent job in helping to determine the originating node. <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> Date: Wed, 16 Dec 87 18:33:58 GMT Sender: EARN Technical Group From: Michael Hebgen <$02@DHDURZ1> Comments: To: EARN Executive , EARN Board of Directors Comments: cc: German EARN Executive , German EARN node administrators , Heinz Haunhorst , "Dr. Gerald Lange" , Otto Bernd Kirchner To: Melinda Varian Subject: CHRISTMAS EXEC Dear colleagues, after some very sophisticated detective work it is clear that the origin of the CHRISTMAS EXEC is the EARN node DCZTU1. A student there has writ- ten this EXEC to send christmas greetings to his colleagues and another student has used it without knowing what he is doing (as many of our network users) and started the explosion. The node DCZTU1 has already blocked the Userid of the author and done all necessary steps. Every node in the network can be the next starting point of a similar explosion and distribute virus programms or other bad things. As far as I know the EDP-systems there is no way to prevent users from their own mistakes. The only solution I can think of for this type of behaviour is to observe "EDP-hygiene": If you receive an executable file (EXEC, CLIST, program) from another might be unknown user do NOT execute without control because it can result in gross missdemanour and serious damage. Check all EXECs/CLISTs, what they are doing, before you execute them and check all executable programs, where they come from and what they do. As in normal life uncontrolled behaviour may result in serious consequences (I am not going to mention AIDS). You as a user are responsable for all what you are doing. I propose to include such statements (in better english formulation) into the CODE OF CONDUCT and to start an "enlightenment" process for the end- users Best regards, merry christmas (without tree) and a happy new year Michael Hebgen EARN director of Germany and General secretary of EARN *** APPENDED 12/19/87 20:10:47 BY PU/MELINDA *** ADDED NOTE FROM JOE MORRIS: Did any contributor suggest how the message jumped from EARN (or BITNET) into VNET? Supposedly the gateways (one at Yorktown, I believe) are monitored closely so that the ability of a message to cross without supervision is quite limited. I'm told that a few years ago there was something of a major flap when a meeting of relatively high IBM brass was shown a message Melinda Varian (the BITNET source of the EARN message I forwarded) had sent to an IBM'er via VNET (WITH the permission of IBM...upper management in IBM just hadn't been aware of the arrangement). My guess would be that it came through an account on a customer machine but assigned to an IBM'er who could pass mail into the IBM network. Thought for the week: was this supposed to be a demonstration of a computerized Christmas distribution TREE? Second thought on the word "tree" (swiped from an undergraduate thesis at MIT from the 60's): Problems are posed by fools like me, but only heuristics can search a tree. Joe Morris From: Will Martin __ AMXAL_RI 4-MAR-1988 18:47 To: Clement Taylor Subj: [40970] Re: BITNET Security [Moderator note: Part 2 of 2. _H*] From: Una Smith <0402909%pucc.bitnet@RUTGERS.EDU> Subject: The Virus of Christmas Past (Re: RISKS-5.80) To: comp-risks@RUTGERS.EDU Re the discussion of receiving run-able mail files (sometimes viruses) via BITNET. A few years ago I received 2 pieces of mail, an XMAS EXEC written in EXEC2 and a compiled module of some sort. The module was hard to break into, so no one I knew then knew how to tell what it did without running it. Well, it was a very nice, benign bug: First, it imitated all the usual system messages one gets when logging off, up to the full-screen VM370 logo. Then, slowly, the logo disintegrated into a night time scene of a cottage on a snowy hillside under some pine trees, smoke floating out of the chimney (the "smoke" was made up of phrases; "s..m..o..k..e" and "M..e..r..r..y...C..h..r..i..s..t..m..a..s", etc.), and snow flakes "*" falling from the sky. Elapsed time: about 5 minutes. Then it quit, abruptly leaving you sitting in front of a terminal in some dingy office or terminal room, just as you were before. The clue to this so-called Christmas card's origin was that the usual machine name in the lower right was replaced with, if I remember correctly, PSUVM. Has anyone on the net now got an old copy of that somewhere? I didn't keep mine. ------------------------------ From: Skip Montanaro To: risks@csl.sri.com Subject: Re: IBM Christmas Virus (RISKS 5.80) >(5) Is the Internet similarly vulnerable ? >>Not to this one. It plays on several things that the Internet doesn't have: The quasi-equivalent of this problem in UNIX systems (and most of the Internet, because of the large number of UNIX systems it contains) is the ubiquitous shar file, an ASCII packaging machanism used to transfer code and other ASCII files via mail and/or Usenet news transfer. The problem lies in the way users unpack shar files: they execute them. Needless to say, inspection of shar files before execution/extraction is highly recommended. There's nothing to prevent me from writing a shar file that purports to be a Christmas card. Execution of it might display the card, check out the contents of various mail-related files, (like ~/.mailrc and ~/mbox) looking for likely candidates to send the shar file, then recursively send it. In fact, the same scheme would work for most operating systems with a command language that could be executed from a file. UNIX systems are especially vulnerable, however, because of their large numbers. Skip (montanaro@ge-crd.arpa, uunet!steinmetz!sprite!montanaro) ------------------------------ From: msb@sq.com (Mark Brader) To: risks@csl.sri.com Subject: Another article on the Christmas Virus [just in time for Xmas] [In the spirit of the season, I am including this now rather old-hat and somewhat ill-informed note for a few more background details. It is interesting perhaps more for what the press can do to an incident than for the incident itself. Happy holidays to all. RISKS will take some vacation -- unless something really startling happens. PGN] I have been handed a clipping from the (Toronto) Globe and Mail's "Report on Business" section. I don't have the date, but Texaco Canada Inc. closed at $31, up $4.50, on the other side of the page. The clipping is of the Quidnunc column by Bud Jorgenson. My !'s in square brackets. Merry Christmas, Big Blue. The internal system of the world's biggest computer company was disrupted for almost 72 hours by an electronic Christmas card. IBM's public relations department played down the seriousness of the incident, but according to our mole at IBM, "it crippled us". The computer equivalent of a nuclear meltdown [!] began at a university in West Germany when someone tapped into [!] IBM's Prof (PRofessional OFfice) System with a graphics-laden Christmas message. Whether it was deliberate or a coding error was not clear [!], but the card quickly became a hit and was passed on to various routing systems. As every computer buff knows, graphics use large bites of memory and this one gobbled up an ever expanding chunk of the Prof System as it multiplied its way through IBM offices. This was a week ago Friday, just before quitting time in Europe and during the first half of the workday on this side of the water. When the system goes down, IBM simply cannot work because just about everything is dependent on the [!] computer, right down to daily diaries with meeting schedules. By early Monday, the system in Canada was partly restored so that employees could tap into the data base to read files. But they couldn't use printers or communicate with other offices until the all-clear was sounded, which was after 10 am Eastern time. An IBM spokesman said the impact on operations varied from country to country. Police work to track down the culprit was turned over to Bitnet and Earn, a pair of computer networks that link universities in North America and Europe. The list of suspects has been narrowed to two at the Technical University of Clausthal, a small town south of Hanover. Forwarded by Mark Brader, SoftQuad Inc., Toronto, utzoo!sq!msb ------------------------------ From: Eric Skinner Subject: Christmas Exec AGAIN! To: RISKS@csl.sri.com An interesting point that has not been mentioned so far is that, at least in the version that reached BITNET sites in Canada, there was a major bug in the code of the program. It parsed the NAMES file in a very inflexible way causing it to have a success rate of about 5% at coming up with valid forwarding addresses. If the programmer had been more careful, we might have been in an even bigger mess. So there are fewer risks when a program has bugs? :-) Eric Skinner, Computing Centre, University of Ottawa ------------------------------ From: minow%thundr.DEC@decwrl.dec.com (Martin Minow) To: risks@csl.sri.com Subject: The Christmas Virus [end of the season?] The same comments on the virus from a slightly different (vms) point of view. The only new info is the description of the anti-viral software. Martin [Pardon a little initial redundancy. I did not want to edit. PGN] Newsgroups: comp.os.vms Path: decwrl!ucbvax!QUCDNSUR.BITNET!PYM Subject: CHRISTMA comes but once a year, a virus may be forever. By now, many of you will have heard of the (infamous) CHRISTMA EXEC "virus" which infected BITNET/EARN/NETNORTH and virtually paralyzed IBM's internal network for a day or two. For those who haven't seen the various postings on the BITNET LINKFAIL list, RISKS-FORUM Digest, etc., I will summarize (no flames for the oversimplifications in the interest of brevity, please). Originating as a "prank" on a German end-node on EARN, this EXEC (i.e. similar to a .COM file - and written in REXX, a DCL-like language) displayed, when executed on an IBM VM system, a primitive christmas tree on the terminal and then mailed itself to everyone on that poor user's NAMES file (i.e. personal mailing name list) before deleting itself. Of course, some users had network distribution lists (e.g. JNET-L, MEDINF-L, etc.) defined in their NAMES file . . . [I personally received six copies of this EXEC from different sources - this is probably not unusual.] While this was a significant problem on BITNET/EARN/NETNORTH with a fair number of VM/CMS nodes, the virus clearly could not infect VAXinated nodes, of which there are a larger number. Also, many (usually undergraduate) students on VM/CMS systems are denied network access, thus limiting the rate of spread of the virus beyond an infected system. However, once the virus entered VNET, IBM's internal network of VM/CMS systems, things really took off (all VM/CMS systems; users with large NAMES files; all with network access) and allegedly brought their network to a standstill. Initially, the problem required manual intervention by system managers to purge CHRISTMA EXECs from users' readers - but this could only give a temporary remission in the disease. Fortunately, a CHRISTMA eradicator was written (by Eric Thomas, author of the LISTSERV software), and also an ingenious virus was developed (by Hank ?, sorry, I've forgotten) to follow and destroy the original CHRISTMA virus and then self-destruct in mid-January. So now it's eradicated like smallpox: hmmm . . . I expect that there may be another minor epidemic when some users return from vacation. So, what should we do? Laugh at IBM? Say "It can't happen to me." Look at all those experienced, computer-wise IBMers who ran CHRISTMA EXEC. Oh yes, there will be flames . . . platitudes about NEVER using any software which you haven't written yourself - or is written by someone you TRUST ABSOLUTELY :-) . . . flames about chain letters and viruses on the network . . . their authors should be boiled in oil / set in RA81 air filter glue / sentenced to do 10 years of RSX SYSGENs / locked in a room with only an IBM PC / (substitute your favourite nightmare here). Let's just think a little before flaming. Could a "harmless" CHRISTMA-like virus attack a VAX/VMS system? A recent network posting (RISKS?, LINKFAIL?) mentioned the possibility of a virus hidden in SHAR files which are _executed_ as .COM files to unpack them. SHAR files are, after all, an excellent method for _reliable_ software distribution over gateways. (This is not meant to reflect negatively on Michael Bednarek in any way - VMSHAR is a great contribution and we all have used it or will use it.) But . . . nobody unpacks one of these distributions with PRIVs turned on, do we? Could such a virus, like CHRISTMA EXEC, replicate from a non-privileged account (apart from doing a SET PROC/PRIV=ALL quietly in the middle of the file)? Certainly, VMS Mail won't allow wildcard SEND (and JNET won't allow a wildcard SEND/FILE), but, for example, a .COM file could do a SHOW LOGICAL/OUTPUT=CRACKER.TMP, look for logicals with syntax "jnet%", "BITNET%", "IN%", etc. and try mailing itself to these addresses. (No flames about giving state secrets to the enemy, please. Blind Freddy could have seen that one.) We may not be able to read a SHAR file in its entirety (looking for a virus in a few thousand blocks of code), but I for one am certainly going to "quarantine" it as far as possible, SEARCHing it for more than a few key words before unpacking it from a non-privileged (either default or authorized) account. Further suggestions from the more devious minds on the list would be welcome, please. Ignorance may be bliss, but it is definitely NOT SAFE. Most if not all of us have public domain software running on our systems - or programs written by students and our colleagues (trustworthy, of course :-} ). How many VAX/VMS systems do _not_ use at least one piece of DECUS software? This PD software, even if not essential, makes life easier and/or saves hours of work. Software exchange isn't going to stop now, nor should it. We must be vigilant, both for our own safety, and as a responsibility to colleagues on the network. We must make all reasonable efforts to check before executing software ourselves or posting it to the net - or making it available for FTP or putting it on a BITNET LISTSERV. CHRISTMA EXEC comes but once a year, but a virus can be forever. Comments from the Info-VAX gurus would be appreciated. What are the guidelines for "safe software exchange"? What are the best methods of checking software for viral contamination, granted that we are going to continue to exchange it? John Pym ------------------------------ Date: Mon, 4 Jan 88 07:51 EDT From: "guthery%asc@sdr.slb.com" Subject: Source Code is Counter to Viruses & Trojan Horses To: risks@csl.sri.com As a little bit of reflection about the fact that almost all computers have clocks in them will show, there is no protection in trying programs out with write-only harddisks or with privileges turned off. Doing this only sets the hook deeper. In fact, anytime you run a program whose complete workings you do not and cannot understand you are at the mercy of the author of the program and you are at risk. One very good way to counter viruses and trojan horses is to insist on getting the source code of any program you run. This is summarized in the following pocketsize adage: IF YOU CAN'T READ IT, DON'T RUN IT There are NO good reasons why software vendors shouldn't give you the source code of any program they sell you. The reason they don't currently is because you could see what a mess the program really is. In 999 cases out of 1,000 they don't know everything the program does and they certainly don't want you looking over the code and telling them. For a moment stop and think of all the execute only software you run on your system. Think of all the companies from whom you purchased this software. Think of all the pressure you put on them for bug fixes, new features, and lower prices. Think about the translation of these pressures into pressures on programmers. Suppose one of these programmers decides to get just a little even ... an occassional bad number, a lost record once a month, a couple pennies moved from here to there just for fun, a scrambled directory entry once in a blue moon. If the program does what it purports to do, where is the check? The project leader? The manager? The president? The venture capitalist? You? And who is responsible? You! And what can you do with a bunch of object code? Turn off the harddisk? Scan the program for strings? Deny privileges? Piece of cake! We are marginally able to answer the question "Does this piece of software do what I want it to do?" but we are absolutely incapable of answering the much more important question "Does this piece of software NOT do what I don't want it to do?" Through this gaping hole in our capabilities enter viruses and trojan horses. It is historically interesting that I can get a handle on the first question without the source code but I can get nowhere on the second without it. As long as we willing to accept programs from software suppliers without the source code we, irresponsibly in my view, accept undue risk and invite disaster. ------------------------------ From: bryce%hoser.Berkeley.EDU@ucbvax.Berkeley.EDU (Bryce Nesbitt) Subject: Viral VAXination? (Re: RISKS-6.1) Date: 4 Jan 88 07:52:09 GMT >Could a "harmless" CHRISTMA-like virus attack a VAX/VMS system? A >recent network posting (RISKS?, LINKFAIL?) mentioned the possibility of a >virus hidden in SHAR files which are _executed_ as .COM files to unpack. I'm surprised nobody has mentioned this: Around here we don't "execute" shar files to unpack them. Instead there is a handly little utility called "unshar". I use a version on both Unix and my Amiga microcomputer. It internally handles all of the "legitimate" commands that a simple file packing shar might contain (echo, wc, cat, if, test, #, exit, etc.). It is much less vulnerable to attack. To use the example of the poster, unshar would simple report "unknow command" if a "SET PROC/PRIV=ALL" was quietly inserted in the middle of the file. The comp.sources.unix and comp.sources.misc archives undoubtably have C source code for the taking. bryce@hoser.berkeley.EDU -or- ucbvax!hoser!bryce (or try "cogsci") ------------------------------ Date: Tue, 05 Jan 88 08:44:54 EDT From: Jeffrey R Kell Subject: Christmas virus plus The problem is compounded on IBM VM/CMS systems (where CHRISTMAs EXEC took its toll) by an often overlooked "feature" of the standard IBM "receive" command. Files such as EXECs are usually sent in a special encoded form called NETDATA format. The "receive" command is smart enough to determine the format of the file and decode it appropriately, as is the "peek" command used to browse a file before receiving it. BUT... the NETDATA encoding also allows for multiple files to be combined into one NETDATA stream. The file appears with only the attributes of the first file in the stream, and only the first file appears when "peeked". When the unsuspecting victim performs the "receive", the remaining files are ALSO received with REPLACE IMPLIED! Building such a "nested" NETDATA deck is not common knowledge, but can be done using the undocumented internal module used by sendfile/receive. The now infamous CHRISTMA EXEC could just as easily contained a PROFILE EXEC behind it that would format your A-disk the next time you logged on. Thus even if you did read the source code for CHRISTMAs and trashed it upon discovery of its function, your next logon would result in erasure of your entire A-disk (and also any evidence of what caused it to occur). There is a semi-public-domain overlay for RECEIVE available on any Bitnet NETSERV server which detects multiple datasets in a NETDATA stream. Any concerned IBM CMS user out there should investigate this utility. ------------------------------ From: ahh@j.cc.purdue.edu (Brent L. Woods) Date: Tue, 5 Jan 88 9:14:35 EST Subject: Unshar program (was: Viral VAXination [Risks 6.2]) >I'm surprised nobody has mentioned this: Around here we don't "execute" >shar files to unpack them... This probably should have been mentioned earlier, as I'm sure it's of interest to quite a few people. I can't speak for either the comp.sources.unix or comp.sources.misc archives (though, as a side note, I couldn't find any unshar programs in the comp.sources.unix archive that is maintained here at Purdue), but there *is* an unshar program in the comp.sources.amiga archives. I'm not absolutely certain, but I believe that the version we have is the one that Bryce was writing about above. If anyone might want a copy of this program source code (in C), it's available via anonymous ftp from j.cc.purdue.edu in the amiga source archives (the directory it's in is news/comp/sources/amiga/volume1, and the filename is unshar.c.Z). It's written with portability in mind, so it should compile and run under a variety of systems, but we've only tested it under UNIX and on the Amiga so far. Also, the file in the archives is compressed (UNIX "compress" utility), so ftp should be set to "binary" mode to insure a correct transfer. Brent Woods, Co-Moderator, comp.{sources,binaries}.amiga USENET: ...!j.cc.purdue.edu!ahh ARPANET: ahh@j.cc.purdue.edu BITNET: PODUM@PURCCVM ------------------------------