Return-Path: XPUM04@prime-a.central-services.umist.ac.uk Received: from G.SEI.CMU.EDU by ubu.cert.sei.cmu.edu (5.61/2.3) id AA13836; Fri, 1 Jun 90 11:29:18 -0400 Received: from SEI.CMU.EDU by g.sei.cmu.edu (5.61/2.5) id AA20551; Fri, 1 Jun 90 11:29:14 -0400 Received: from nsfnet-relay.ac.uk by sei.cmu.edu (5.61/2.3) id AA00614; Fri, 1 Jun 90 11:28:56 -0400 Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK via Janet with NIFTP id aa23431; 1 Jun 90 16:06 BST From: Anthony Appleyard To: KRVW <@NSFnet-Relay.AC.UK:KRVW@sei.cmu.edu> Date: Fri, 01 Jun 90 16:06:48 BST Message-Id: <$TGTWCZCFFBQX at UMPA> Subject: Virus-L vol 0 issue #0511 Virus-L Digest Wed, 11 May 88, Volume 0 : Issue #0511 Today's Topics christmas exec details ** no subject, date = Wed, 11 May 88 10:25:27 EDT PKARC bug, it is a valid patch Re: software self-checks Re: software self-checks Sueing ------------------------------ Date: Wed, 11 May 88 09:48:55 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: christmas exec details Here are some details about the IBM "Christmas Exec" virus that was floating around the network world right around Christmas 1987. These were forwarded to me by a reader: Date: 10 May 1988, 13:09:54 +0200 (MESZ) From: Otto Stolz +49 7531 88 2645 RZOTTO at DKNKURZ1 Subject: DIRTY DOZEN (Issue #8: February 21, 1988) > ????????.??? ?????? V There is a virus that was circulating > around Bitnet in December that advertises I can give you some details on this network-virus: It's name was CHRISTMA EXEC . I forgot its file size, and have kept no log of it. It consisted of a single program in the REXX language, which has been available in the VM/SP operating system (for IBM mainframes) since Release 3. (The REXX language is also available under MS-DOS for IBM-PC, -XT, and -AT, and it is announced for the mainframe operating system MVS/TSO-E; but for reasons given below, I reckon the virus could reproduce itself only under VM/SP.) The source of CHRISTMA EXEC (with REXX, there isn't anything as an object code file) started with a lore of say-instructions, that apparently would display a sketch of a Christmas-tree together with some good wishes on the screen. This bunch of (in fact rather boring) statements filled one and a half screens; it was followed by a half-screen-sized comment, stating roughly "Reading source-code like this is boring, rather RECEIVE this program, and just enter CHRISTMA" (the latter CMS command would have started the program). When you actually started the thing (I didn't do it, but people told me), the program indeed displayed a Christmas-Tree and best wishes for the year to come. Then it read two files, CMS (part of VM/SP) maintains on behalf of every user. The first one is called NETLOG, and contains a log of network traffic the user has been involved in. Here is a sample entry of my personal RZOTTO NETLOG file ("disc" meaning "discarded", and "from" pointing to the sender's address): File CHRISTMA EXEC A1 disc from RZBERAT1 at DKNKURZ1 on 12/16/87 14:34:44 sent as CHRISTMA EXEC A1 The NETLOG file contains similar entries for notes and files having been sent by the respective user (me, in the example). The second one is called NAMES and contains sort of private directory of people you are in correspondence with. Here are four sample entries of my private RZOTTO NAMES file: :nick.VIRUS-L :userid.VIRUS-L :node.LEHIIBM1 :notebook.VIRUS-L :name.Virus Discussion List :nick.VIRUS :name. Owners of VIRUS-L :notebook. VIRUS-L :list. KenVWyk Eshleman :nick.KenVWyk :userid.LUKEN :node.LEHIIBM1 :name.Ken Van Wyk :nick.Eshleman :userid.LUJCE :node.LEHIIBM1 :name.Jim Eshleman CHRISMA EXEC extracted all network addresses from these two files, and sent a copy of itself to every of these addresses except the address, from where it came to the current user (thus avoiding the ping-pong effect). The poor victim's very next experience: he received replies from thousands of BITNET nodes, telling him where the hundreds of CHRISTMA copies went. At last, CHRISTMA EXEC destroyed its own source on the user's disk. As CHRISTMA EXEC relied on one of the two special CMS files, it probably could reproduce itself only in VM/SP systems (I don't know, how net- working is implemented under TSO or under MS-DOS). Furthermore, it depended on active help of the user being "infected" to reproduce itself: he had to enter two commands, RECEIVE and CHRISTMA. This active help was provoked by an appeal on peoples curiousity and playfulness. In spite of these two handicaps, CHRISTMA EXEC spread within two days, worldwide. The effect was enhanced, as some copies went to BITNET discussion lists, where they automatically were duplicated and distribu- ted as any sensible contribution will be. If I remember correctly (and if I can trust rumours), it originated (as a student's joke) somewhere in Germany, went through USA, and came back to our blessed country from the far east. It's severest effect was obstructing the whole network with thousands of copies of itself. The cure was very simple: every node had to run a quickly developped program that purged every file of name CHRISTMA EXEC from the node's spooling area, the only difficulty being the distribution of this "macrophage" program through the helplessly overloaded network. Even without this cure, CHRISTMA would probably be extinct by now, as any user seeing it for the second time would have discarded the file, remembering the traumatic experience of the first time, when he started that thing. Thus by now, BITNET is probably "immune" to this virus. The moral of the story: 1. read and understand programs you receive without having asked for, before you run them. 2. Think about the possible results before starting a practical joke. Best regards Otto. - ---------------------------------------------------------------------- = Kenneth R. van Wyk = = = User Services Senior Consultant = Badgers! We don't need = = Lehigh University Computing Center = no stinkin badgers! = = Internet: = = = BITNET: = = - ---------------------------------------------------------------------- -------------------- Date: Wed, 11 May 88 10:25:27 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "David A. Bader" I have a question dealing with PKX35A35 and a virus/trojan associated with it. In the issue #8A of the Dirty Dozen by Eric Newhouse (available from this list) dated 2-21-88, Eric writes "As of this writing, Phil Katz (author of PKXARC) has verified that version 35A35 is the latest version of his ARChive extractor. This phony PKXARC scrambles FAT tables." (Refering to a suspected Trojan Horse: PKX35B35.EXE) Anyway, through local BBS's, I attained a BugFix archive called PK35BUG, complete with documentation supposedly written by Phil Katz, that supposedly fixes a bug in PKX35A35.EXE for "large binary files." The files in this archive are dated 9-22-87 through 9-27-87. I have heard through the grapevine that this BugFix will spread a virus, through archives, and also that it is legitimate, but still, no one has given me a consistent answer. I tried to contact Phil Katz through US Mail, Bitnet, and BBS's, but never got a response. Is this BugFix his, or not? (I have a copy of it, if anyone wishes to see it. The fix is about 3K.) Also, why would Phil Katz tell Eric Newhouse that 35A35 is the latest version, if he had released a BugFix, and why would Phil Katz release a BugFix, instead of releasing a whole new version to alleviate these problems? Any comments are welcome! -David Bader -------------------- Date: Wed, 11 May 88 09:20:00 CST Reply-To: Virus Discussion List Sender: Virus Discussion List From: LOWEY@SASK Subject: PKARC bug, it is a valid patch > I have a question dealing with PKX35A35 and a virus/trojan associated > with it. > Anyway, through local BBS's, I attained a BugFix archive called PK35BUG, > complete with documentation supposedly written by Phil Katz, > that supposedly fixes a bug in PKX35A35.EXE for "large binary files." > The files in this archive are dated 9-22-87 through 9-27-87. There was an official bug fix for PKARC. The problem was that when files were SQUASHED, and started with a certain character (CHR(0) I think) then it would not be unarchived. I tested this and the bug existed. I applied the patch I got from uucp, and the bug disappeared. I have had no problems with trojan horses arising from it. However, this official bug had nothing to do with "large binary files". It is possible someone else has released a different "bug fix" which is in fact a trojan horse. > Also, why would Phil Katz tell Eric Newhouse that 35A35 is the latest > version, if he had released a BugFix, and why would Phil Katz release a > BugFix, instead of releasing a whole new version to alleviate these > problems? The bug it was fixing was very very minor. Perhaps one in 1000 archives would have the problem. I agree that he should have changed the version number, but he didn't. Kevin Lowey -- University of Saskatchewan Computing Services -------------------- Date: Wed, 11 May 88 17:39:00 LCL Reply-To: Virus Discussion List Sender: Virus Discussion List From: Michael Wagner +49 228 8199645 Subject: Re: software self-checks > |however, such checks would be very useful in slowing the spread of a virus. > > A couple of comments to this. Yes, it'd slow the spread of > viruses, but it would also make you less paranoid about them (and > thus less likely to catch them), ---- I assume this should have been MORE likely to catch them? > make viruses more likely to be obnoxious Some people advocate make-shift virus protection, i.e. protection that is only one step ahead of the virus itself, and works by exploiting very particular properties of the virus. When virus protection only stops up one hole of many, it usually serves to produce a virus strain that circumvents the one plugged-up hole. This is what happened when people tried to patch MVT to make it 'more secure'. It was like the little dutch boy putting his finger in one hole in a sponge. The water just went around his 'secure hole'. Not all virus protection need be so make-shift. MVS was built with security as a basic design criteria, and the sponge is considerably less porous. Our experience at the University of Toronto (where I used to work) was that most infiltrations were done as a pasttime, to show that it could be done, and to show off to friends. If you make this too much work, you cut 99% or more of the perpetrators dead in their tracks. This is not to say that MVS is totally secure. Similarly, my house isn't entirely burglarproof. But you do have to have a strong motivation to work hard enough to break in. I don't store enough (in either place) to justify anyone working that hard to break in (and I don't put on airs like I do, either). Otherwise, I would worry. > (what kind of person would spend the time to work around the > protections?), Rather like the gun control arguments, the real criminals will always have guns, whether you attempt to control them or not. However, 99% of the viruses currently circulating are created by idle minds, and not by real criminals. > and slow the system down as well. This is a relatively weak argument. It runs faster with security controls enabled than it does when it isn't running at all. Besides, security that is 'architected in' rather than strapped on later shouldn't cost very much in computing resources. I like human analogies. If you have to unlock the front door to your house before you walk in, it slows you down. Have you tried to optimize your 'house access time' by leaving it unlocked? > This is a classic argument about security. The advent of a > "secure" system will make users forget about security. There is no such thing as a 'secure' system. There are only more and less secure systems. Therefore, a 'more secure' system includes facilities to enable the 'security officer' to check if security has been breached (for most PCs, the owner is also system manager, purchasing agent and security officer. Thats what he bought in to. If he didn't want all that responsibility, he should have bought time on a mainframe where someone else does that work (and it costs more as a result)). > When security is breached, the breach may never be found because > no one is looking for it. If no one was looking, it was a not-at-all secure system. The greatest security system in the world is useless if no one is watching it. > jim frost madd@bu-it.bu.edu Michael Wagner -------------------- Date: Wed, 11 May 88 12:51:41 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Adam Lewis Subject: Re: software self-checks In-Reply-To: Message of Wed, 11 May 88 17:39:00 LCL from There is a very good point here about making security such that it takes some effort on the part of the author of the virus to break it. This gets rid of the people who do this to "impress" their friends and neighbors. The problem is that the people who do in fact spend the time it takes to break security are going to do it in a fashion that is much more difficult to figure out and are going to be a lot more sophisticated (i.e. no FORMAT C: in your PC's AUTOEXEC.BAT). It strikes me as another application of Murphy's 90-10 law. - ---------------------------------------------------------------------- Adam Lewis %It could be worse, it Center of Excellence for Computer Applications% could be Monday. Univ. of TN, Chattanooga % - ---------------------------------------------------------------------- -------------------- Date: Wed, 11 May 88 12:30:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Joseph M. Beckman" Subject: Sueing Cliff Stoll has suggested that people sue perpetrators who hack into machines. He believes that even if these people cannot be prosecuted sucessfully (under criminal law, for whatever reason(s)), it is still a good idea to sue for damages (in civil court). He believes that this would (at a minimum) show people that organizations are serious in going after these people. Anyone care to sue the Pakistani who loosed the "Brain" virus? Joseph