VIRUS-L Digest Friday, 1 Dec 1989 Volume 2 : Issue 250 VIRUS-L is a moderated, digested mail forum for discussing computer virus issues; comp.virus is a non-digested Usenet counterpart. Discussions are not limited to any one hardware/software platform - diversity is welcomed. Contributions should be relevant, concise, polite, etc., and sent to VIRUS-L@IBM1.CC.LEHIGH.EDU (that's LEHIIBM1.BITNET for BITNET folks). Information on accessing anti-virus, document, and back-issue archives is distributed periodically on the list. Administrative mail (comments, suggestions, and so forth) should be sent to me at: krvw@SEI.CMU.EDU. - Ken van Wyk Today's Topics: Network Virus Scanner (PC) Re: Eddie ? (PC) Info on Jerusalem Virus (PC) Re: Sophisticated Viruses (Mac) DIR EXEC remedies (VM/CMS) JUDE Virus (?????) Mac SCANV50 Relay (Bitnet) interactive virus conference nVir outbreak (Mac) Virus Update (PC) Jerusalem B virus Jerusalem - D (PC) Multiple infections (PC) re: Eagle issues (PC) DIR EXEC question (VM/CMS) --------------------------------------------------------------------------- Date: Tue, 28 Nov 89 08:24:13 -0800 From: TCURRY@cup.portal.com Subject: Network Virus Scanner (PC) David Grisham asked about the availability of alternatives to NETSCAN. Tacoma Software Systems produces a network scanner that's equally as good if not better than NETSCAN. In addition, they throw in a prevention program called VIRSTOP that scans programs before they're allowed to execute and prevents infected programs from spreading. It's more expensive than NETSCAN but the combined package is pretty good. Their address is: Tacoma Software Systems 7526 John Dower Road, W. Tacoma, WA 98467 Tim Grant Curry ------------------------------ Date: 28 Nov 89 19:38:08 +0000 From: wsinrn@urc.tue.nl (Rob J. Nauta) Subject: Re: Eddie ? (PC) frisk@rhi.hi.is (Fridrik Skulason) writes: >I was wondering about a text string that appears inside the Dark Avenger >virus: > Eddie lives...somewhere in time > >Wasn't there a character named Eddie in a horror movie ? If so, did this >sentence appear there ? All Iron Maiden fans will recognise this, although I'm not one of them, I do know that part of their claim to fame is their sleeve illustrations, which features a creature known as 'Eddie' The various sleeves see him evolve, die, resurrect, enter the future, and on the last one in the ice-age. The quote has something to do with the album before, 'Somewhere in Time' which was more successful. Greetings Rob PS. Do the Ohio and/or Den ZUk virus do any damage apart from formatting track 41 ?? I'd like to know, there isn't much info on those... ------------------------------ Date: 28 Nov 89 21:29:24 +0000 From: sherk@umd5.umd.edu (Erik Sherk) Subject: Info on Jerusalem Virus (PC) Hi Virus Hunters, It has been a while since I worked on debrain and I have been away from this list for some time, so I am a little out of date. Please forgive me if this has been talked about recently. The University of Maryland has been hit by the Jerusalem Virus. The McAfee programs SCANRES and VIRSCAN have been invaluable in helping to detect the infection, but they don't help remove it. So what I am asking for is: 1) Is there a Public Domain program that will remove the virus from a machine? 2) I would like a detailed description of this virus, i.e. Is it a boot virus, where in RAM does it live, what INTs does it steal... Please send any info to my mail address, as I don't have the time to read this list regularly. Thanx in advance... ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Erik Sherk sherk@umd5.umd.edu Network Infrastructure (301) 454-0864 Computer Science Center University of Maryland ------------------------------ Date: 28 Nov 89 21:43:05 +0000 From: ut-emx!chrisj@cs.utexas.edu (Chris Johnson) Subject: Re: Sophisticated Viruses (Mac) christer@cs.umu.se writes: >chrisj@cs.utexas.edu (Chris Johnson) writes: >>There would be crashes because it's very common for software that >>patches traps to have interdependencies between its patches, i.e. one >>patch depends on data discovered and stored for later use by another >>patch. Removing only a portion of such patches will be likely to kill >>the machine sooner or later. >> . . . >>Further, restoring traps to their original values is going to remove >>all of the patches put in place by the System itself - the patches >>that keep that machine running inspite of bugs in the ROMs, etc. >>Also, whole portions of the OS and Toolbox will be removed by >>restoring traps to their initial values (as taken from the ROM) - this >>will kill the machine for sure. > >So what if I remove system patches? You seem to think that I need to >call every little routine in ROM to do my dirty stuff. What I need is >say, ChangedResource, WriteResource and perhaps AddResource. What do >these traps have to do with OS traps? How many system patches are >there for these traps? Do you *really* think that the ROM is truly >and utterly worthless without the system patches? Do you think they >wrote routines that didn't work at all and then patched them into >working? Why would I care if there is some small and obscure bug in >the ROM that could make my virus crash with prob. .000001%, after all >that is probably the whole idea with the virus after all!! The point is that you can't know the interdependencies of traps. Maybe you can get away with some of what you discuss, but it'll be a matter of luck more than anything else. And *no* I don't think that the ROM is utterly worthless and bug ridden, but most ROMs were created to operate in the context of much earlier system software and may not be (without the patches that would normally be in place) ready to cope with the modern Macintosh. Beyond that, and perhaps more significantly, Apple's fixes to the ROMs are often made not to the routine that has the bug, but to routines invoked *by* that routine which are likely to be, in and of themselves, unrelated to the actual bug. See the ongoing discussion of tail patching in comp.sys.mac.programmer for a full treatment of this subject. So I think the probability is actually a bit greater than ".000001%" that your virus will crash the machine *before* it can replicate itself. At which point it's just not a virus anymore. >I don't claim that the ROM is bug free, but your indirect claim that >every trap is buggy is pretty heavy. (I got that from the "fact" that >everything will kill the machine "for sure", in case you wonder). See above - I certainly didn't mean to claim that everything is buggy. Also, if I can't be sure something will work, when I program, I look at it as a guarantee that sooner or later I'm going to crash somebody's machine. I still make a good number of mistakes (like most folks), but I think this kind of paranoia is a good idea and steers me clear of a lot of other problems. I like to think that all Mac programmers will exercise similar care in their approach to programming issues, but, of course you're right, virus authors may not bother. >>Writing well behaved patches is a black art on the best of days - >>writing the sort of un-patching patches discussed here would make that >>"black art" look like a carefree romp in the sunlit countryside. I >>don't think such patches could be implemented safely, and I don't >>think anyone clever enough to do so would be wasting his time working >>on viruses in the first place. > >This proves you've missed the point entirely. We're not talking about well >behaved viruses here. And just because you think no one would write one isn't >exactly proof that no one will... I didn't miss any point completely. The first of my points which you quote above deals with issue of reliability and practicality - I stand by that statement. The second of those points was a psychological one, it was *not* offered as *proof* of anything, just a statement of what I believe to be a reasonable opinion. If you have a different opinion - that's fine. I hope you and your opinion are very happy together. :-) >>All in all, I don't think the techniques dealt with in this discussion >>are significant simply because there are too many reliability and >>compatibility problems intrinsically linked to them. > >I do think they are significant though. The whole point with my post in the >first place was to make people realize that a virus could bypass the >protective fences of all anti-viral programs (including Gatekeeper) pretty >easily (theoretically anyway). What if a virus changed the resource map >directly without going through the ROM at all? We can't just rely on the >trivial and obvious protection that Gatekeeper et al. provies. For the reasons I stated above, I still don't think the techniques dealt with in this discussion are significant. This is not to say that there aren't ways around the various virus protection schemes currently available - there is not now, nor do I believe that there is ever likely to be, an infallible anti-virus system for the Macintosh. Nonetheless, I don't think that these particular techniques will be of service to anyone in trying to get around anti-virus systems. Since the failed attempts to create such a virus could, however, cause a few victims a lot of damage I thought it was important to comment on the practicality of these techniques. Techniques that would safely create more sophisticated viruses, are techniques that I refuse to comment on in any public forum. (In general I also refuse to comment on the techniques that won't work, but I made a rare exception in this case.) As an aside, Gatekeeper is more sophisticated than Vaccine, and SAM is more sophisticated than Gatekeeper (although in ways that aren't yet important, I'm relieved to say). Gatekeeper is improving and will continue to do so - I will not be advertising these improvements because I do not care to notify would-be virus authors of what Gatekeeper can and cannot do. The more they're left guessing, the better-off the rest of us will be. Further, Gatekeeper, at least, can only be extended so fast because my resources (free time, money, etc.) are very limited. To the extent that this discussion promotes the creation of newer, more sophisticated viruses we are all done a dis-service - I can only extend my tools so fast; if you deprive me of time by accelerating the development of new viruses, you are *not* promoting the creation of more sophisticated anti-virus tools, instead you're hindering such efforts. If you find the protections offered by Vaccine, Gatekeeper and SAM trivial, I would encourage you to write a better tool. I imagine that a lot of people would be very pleased to see another good tool made available. >What we need >is sophisticated protection schemes, and unless there's no discussion of >potential viruses we might never come up with these schemes in time. More to the point, I believe, would be the following statement: "unless we keep up open discussions of this kind the virus authors may never come up with the ways to bypass the existing protection mechanisms." Sharing of information is great, but offering would-be virus authors important information isn't. It'll be a dark victory indeed if we get the more sophisticated anti-virus tools you desire (quite appropriately) IN RESPONSE TO the appearance of more sophisticated viruses made possible by these discussions. I am sympathetic with the desire for more sophisticated tools (although I think you underestimate SAM), but I don't believe that this is the way to make them a reality. If you'd like to pursue these issues privately, I'd welcome an email discussion with you. Seriously. Best wishes, - ----Chris (Johnson) - ----Author of Gatekeeper - ----chrisj@emx.utexas.edu ------------------------------ Date: Tue, 28 Nov 89 09:54:00 -0300 From: Marty Zimmerman Subject: DIR EXEC remedies (VM/CMS) What are other VM/CMS installations doing to slow down the spread of the DIR EXEC? I seem to remember that the CHRISTMA EXEC prompted someone to write a program to scan/clean the SPOOL queue, and I was wondering if anything similar is available for DIR. On this subject: how far should system administrators go to protect users from this type of "letter bomb". It seems a bit heavy-handed to purge ANY file from the queue with a filetype of EXEC, XEDIT, or MODULE. Is it best to let the users fend for themselves, or overprotect them? Marty Zimmerman ------------------------------ Date: Tue, 28 Nov 89 10:55:50 -0500 From: "Gregory E. Gilbert" Subject: JUDE Virus (?????) Mac I saw a posting on VALERT-L stating that a new virus has been found called the JUDE virus. Does anyone have any information beyond what was reported on VALERT-L? Has this been CONFIRMED to be a virus? Thanks much. Greg Postal address: Gregory E. Gilbert Computer Services Division University of South Carolina Columbia, South Carolina USA 29208 (803) 777-6015 Acknowledge-To: ------------------------------ Date: Tue, 28 Nov 89 11:14:12 -0800 From: Alan_J_Roberts@cup.portal.com Subject: SCANV50 ViruScan V50 is now out. It detects the Holland Girl .COM infector reported by Fidonet SysOp Jan Terpstra in the Netherlands. The virus increases the size of infected programs by 1332 bytes and contains a message about a girl named Sylvia in Holland. No damage has yet been reported from the virus. Will report back when more is known. Alan ------------------------------ Date: Tue, 28 Nov 89 21:02:51 -0500 From: "Doug Sewell" Subject: Relay (Bitnet) interactive virus conference A few problems with the idea: 1. Access: Quite a number of VIRUS-L/comp.virus readers that might wish to participate in an interactive conference are not members of the Bitnet/NetNorth/Earn network. These people could not par- ticipate. I do not know for sure if there are interactive confer- encing systems for usenet and internet, but I doubt it... and COMPU$ERVE is too expensive. 2. If all the participants were on Bitnet/NetNorth/Earn, the Relay network probably wouldn't cooperate - many relay sites have 'quiet hours' during the day, and time zone conflicts would have some users locked out while other users could participate. Also, the relays I'm familiar with limit a channel to 8-10 participants (but I'm not sure if there would even be that many, and I'm not sure if the ones with the most to offer are on Bitnet). It is a nice idea, though. Doug Sewell (DOUG@YSUB.BITNET), Tech Support, Computer Center, Youngstown State University, Youngstown, OH 44555 >> Love it or hate it, your body is yours for life. ------------------------------ Date: Wed, 29 Nov 89 09:39:44 -0000 From: Subject: nVir outbreak (Mac) 1. Can I warn people that there has been another outbreak of nVirB on the Macs at Teesside Polytechnic, Middlesbrough, Cleveland UK. Please check any disks received from here on or after today. 2. Can I apologise to everyone on VALERT-L who received my complaint about repeated error messages. It should have gone to VIRUS-L. Sorry to have put even more unwanted stuff in your mail boxes. Rgds, Iain Noble ------------------------------ Date: Wed, 29 Nov 89 08:39:40 -0600 From: Bill Hobson Subject: Virus Update (PC) I have finally had a reoccurance of the virus that wiped out several hard disks in our architecture department. It has positively identified as Jerusalem B as I had suspected. I am sure that it won't be the last outbreak - this has been the fourth outbreak on campus in less than 6 months (sigh). I have an unconfirmed report of the Stoned virus that I am investigating. More later as the search continues! ------------------------------ Date: 29 Nov 89 20:30:51 +0000 From: jag@beach.cis.ufl.edu (Jason Griggs) Subject: Jerusalem B virus The Jerusalem B virus started to sweep over the Electrical Engineering dept. at University of Florida this afternoon. I'd appreciate any information as to how the virus works & how to get rid of it. Thanks in advance. ||===========================================================================|| || // // //--- || Gravity: Not just a good idea, it's the LAW! || || // //_\\ // __ || jag@beach.cis.ufl.edu || || \\// // \\ //__// || alan%oak.decnet@pine.circa.ufl.edu || ------------------------------ Date: Wed, 29 Nov 89 22:59:20 +0200 From: "Yuval Tal (972)-8-474592" Subject: Jerusalem - D (PC) For some reason ViruScan idetifies the sURIV 2 as the Jersualem - D virus. The sURIV 2 is not a varient of the Jerusalem, it is more likely to be some kind of 1st of April - EXE virus. - -Yuval +--------------------------------------------------------------------------+ | BitNet: NYYUVL@WEIZMANN Domain: NYYUVAL@WEIZMANN.WEIZMANN.AC.IL | | InterNet: NYYUVAL%WEIZMANN.BITNET@CUNYVM.CUNY.EDU | +-----------------------------------+--------------------------------------+ | Yuval Tal | Voice: +972-8-474592 | | The Weizmann Institute Of Science | BBS: +972-8-421842 * 20:00-7:00 | | Rehovot, Israel | FidoNet: 2:403/136 (CoSysop) | +-----------------------------------+--------------------------------------+ ------------------------------ Date: Wed, 29 Nov 89 21:48:16 +0000 From: frisk@rhi.hi.is (Fridrik Skulason) Subject: Multiple infections (PC) Some of the early variants of the Jerusalem virus are known to infect the same file over and over, but it was thought that no other virus did that. It seems, however, that the Cascade virus does this too, under certain conditions. One of the software companies here in Iceland called me today, asking for help in removing a virus which had invaded their network. It was obvious that something unusual was going on - COMMAND.COM was over 50K instead of the usual 25K or so. Examination revealed that programs on their Novell network server had been infected multiple times (up to 20 times) with the same virus (1704-B), but programs on diskettes and local hard disks had only been infected once. I just used a quick and dirty solution - ran my disinfection program 20 times, but I would like to know if anyone else has noticed this phenomena. - -frisk ------------------------------ Date: Wed, 29 Nov 89 17:56:00 -0500 From: IA96000 Subject: re: Eagle issues (PC) Normally I would agree would you. However, many people hunt for VGA specific applications on BBS's which I guess is why EAGLE.EXE was said to be a VGA animation of an eagle in flight. As far as whether it should be considered a trojan, a virus, both or neither, since two forms of viruses have been detected in it, and since it is also a trojan, it might be a good idea to consider as something, don't you think? EAGLSCAN does not just identify the viruses inside these encrypted files. Note I said encrypted files. It also hunts for the specific code used to determine the processor type and the code used to do the actual disk writes. In any event, this is the last you will hear on the subject from me. SWE is swamped with more requests than they can handle and as far as I am concerned, it is time to turn to another subject. ------------------------------ Date: Wed, 29 Nov 89 11:59:30 +0000 From: P.E.Smee@gdr.bath.ac.uk, Subject: DIR EXEC question (VM/CMS) My boss has just heard about this and got himself into a flap. (We run, among other things, a VM/CMS 'service' (if that word can be applied to VM/CMS) on a 3090/150S.) We have not seen a copy of it, and we don't know how BITNET/EARN IBM's are interconnected. However it sounds from the description like it must transfer itself using SENDFILE (or TRANSFER) over something like RSCS. Is this indeed the case? (If so, it is unlikely to travel freely between UK academic IBM sites as we tend to run UK Bluebook for file transfers, which requires that you know the password as well as the username on a remote site in order to send them a file. If it travels as mail, then password is not necessary of course, but on the other hand the mechanics of MAIL are such that a user is more likely to have looked at it before running it, since it is a bit tricky to 'RECEIVE' mail into a separate executable file.) Of course if we DID end up with a copy on our machine, it could redistribute itself freely within the machine. I'm simply trying to make a value judgement as to the likelihood of our getting a copy from outside; and to decide exactly how to phrase our warning to users. It also affects our protective reaction. If it transfers via SENDFILE/TRANSFER we're not going to get it. If it transfers via MAIL or some other protocol, we might get it, but it will not show up in our SPOOL as DIR EXEC... Paul Smee, Univ. of Bristol Comp. Centre, Bristol BS8 1TW (Tel +44 272 303132) Smee@bristol.ac.uk :-) (..!uunet!ukc!gdr.bath.ac.uk!exspes if you HAVE to) ------------------------------ End of VIRUS-L Digest ********************* Downloaded From P-80 International Information Systems 304-744-2253