VIRUS-L Digest Thursday, 26 Oct 1989 Volume 2 : Issue 223 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: re: IBM's Virscan Program (PC) Another suggestion for preventing viral spread (PC) RE: Apple II virus - LODE RUNNER INIT 29 vs. locked disk (Mac) Re: Jerusalem Virus Version B detected (PC) DataCrime Strikes!! (PC) Xeno--possible new virus? (AMIGA) SCANv45 and UNVIRUS (PC) reposting of FICTITIOUS virus story (UNIX) --------------------------------------------------------------------------- Date: 25 Oct 89 00:00:00 +0000 From: "David.M..Chess" Subject: re: IBM's Virscan Program (PC) This is the information I have; I think it's still correct (I'm sure everyone will tell me if I'm wrong!): IBM Personal Computer and PS/2 customers may order the virus detection program by calling 1-800-426-7282 from 8 a.m. to 8 p.m. Eastern time through December 31, 1989 and requesting the IBM Virus Scanning Program, part number 64F1424. The $35 fee can be charged to VISA, MasterCard, American Express, or the IBM Credit Card. There were also a bunch of security-related announcements from IBM yesterday that I haven't finished reading yet; there may have been something of relevance in there. I haven't seen any mention of official updates to the signature files. This program is very similar to the internal version of VIRSCAN that you saw while working for IBM. While I'm here, I'll also mention that it's a good idea to get anti-virus software direct from the owner whenever possible, and not trust indirect or pirated versions from questionable sources. Anti-virus programs are obvious candidates for malicious Trojan-Horse hacks! DC ------------------------------ Date: 25 Oct 89 09:59:00 -0400 From: "Damon Kelley; (RJE)" Subject: Another suggestion for preventing viral spread (PC) Earlier this week I was reading a book by Peter Norton. There was a passage about the importance of .OBJ files created by compilers (esp. assembly). While I was pondering the importance of .OBJ files, an idea hit me: since this type of file is non-executable and can only run when linked, wouldn't self-attaching viruses be scrambled when the "host" file is changed to an .EXE? Of course, the following factors would come into play: -the linker and the compiler must not be infected; -there are no viruses present in RAM or the disk(s) of the user; -the user must be willing to buy some compilers and linkers with as little economic discomfort as possible; -virus writers don't know very much about manipulating .OBJ files correctly; and -the .OBJ file was not compiled with an attached virus. In other words, wouldn't it be safer if all programs came .OBJ files (or ASCII)? That would eliminate much of the virus transmission going on now, I think. Counterpoints welcome. Damon Kelly jnet%"damon@umbc" "What? Do I speak for anyone damon@umbc.bitnet else?? Does Reagan remember damon@umbc2.umbc.edu what he did between 1980-'88??" ------------------------------ Date: Wed, 25 Oct 89 14:21:37 +0000 From: ZDEE699@ELM.CC.KCL.AC.UK Subject: RE: Apple II virus - LODE RUNNER "Non-destructeur" means: that does not destroy info. (So I would guess that it does not alter info on disks) Olivier Crepin-Leblond (and YES, I am French...) Computer Sys & Elec. , Electrical & Electronic Engineering, King's College London, UK. ------------------------------ Date: Wed, 25 Oct 89 11:45:21 -0400 From: Joe McMahon Subject: INIT 29 vs. locked disk (Mac) "Thomas R. Blake" writes: >>(Prior to INIT29, I had been advising my users that if they go >>to Kinko's they would be safe if they took only their data diskette. >>But if a data infection can spread to their application disks, >>this would not be good advice.) >> >>Anyone got the REAL answer? > >Well, I assume they're going to Kinko's to print. (Yes/No?) I'd say >if they write-protect their diskettes they have no need to worry. > >Macintosh viruses will not spread to write-protected diskettes. The problem with INIT 29, though, is that inserting a locked disk into the drive will get the "This disk needs minor repairs..." dialog. If they don't unlock it the disk will be rejected. If they do, it will be infected. Cute, huh? Best option is to COPY the files to another floppy, take it, use it, bring it home, and INITIALIZE IT IMMEDIATELY. --- Joe M. ------------------------------ Date: 25 Oct 89 20:51:54 +0000 From: jwright@atanasoff.cs.iastate.edu (Jim Wright) Subject: Re: Jerusalem Virus Version B detected (PC) In article <0010.8910251154.AA23552@ge.sei.cmu.edu> shaynes@lynx.northeastern.e du writes: | After running Scan 1.1V45 on my hard drive I detected the Jerusalem Virus | Version B on one of my files. The file that I detected the virus on had | not appeared in earlier runs of Scan. | | The infected file is UNVIRUS.EXE. The archive I got it out of was | UNVIRUS.ARC. I downloaded this file from the SIMTEL20 PD archives. I | immediately deleted the file. I have never had a reason to the | program (and I would think that running the program on itself would | have adverse affects). I uploaded unvirus.arc to SIMTEL20, after it was sent directly to me by the author. I will assert there is no virus in that file. Of course, for the program to be able to deal with the Jerusalem-B virus, it must first identify it. Apparently scanv is setting off false alarms based on the identification code present in unvirus. Scanv previously had problems with false alarms with one of the author's own programs. Unvirus.arc is an old version that was removed from distribution at the request of the author. No problems, but a newer version has been released. Please get unvir6.arc from any of the IBMPC anti-viral archives. Unvir6.arc also replaces the file immune.arc. Now, as for scanv. The author said previously that he regularly changes the methods he uses to identify viruses, thus hopefully discouraging crackers from releasing minor modifications of existing viruses. It seems that this incarnation of scanv is triggered by what it sees in unvirus. I tested both scanv45 and scanv42. 45 choked on it, 42 gave no false alarms. One more curious point. Scanv45 insisted that Jerusalem-B was present in memory! How to explain this? I *never* executed the unvirus program, so even it it did have a virus it couldn't load itself. No other file set off any alarms. Where did it come from? Well, when I unarchived unvirus.arc or unvir6.arc, the archiving program used more memory than scanv. Since MS-DOS doesn't clear memory after programs execute, there was still an image of unvirus left where the archiver had been working. Scanv45 barfed on this! To verify this, I unarchived unvir6.arc, then ran DBASE III+, then ran scanv45. This time no virus found in memory. So in summary, replace unvirus.arc with the current release unvir6.arc. Apparently scanv45 sets off a false alarm with unvirus (either version). Neither author should be faulted for this. But everyone should be made aware of it. And don't put blind faith in any one program!! - -- Jim Wright jwright@atanasoff.cs.iastate.edu (ignore the Reply-To: line) ------------------------------ Date: Wed, 25 Oct 89 13:51:33 -0500 From: GX6692%SIUCVMB.BITNET@VMA.CC.CMU.EDU (Vince Laurent - work id) Subject: DataCrime Strikes!! (PC) I just got back to work today and was notified that ALL our hard drives at work had to be reformatted since they had the virus on them. We used IBM's release of VIRUSCAN and the tests were positive - we were hit. I don't know the extent of the damage on campus yet but other departments are worried. Is there a 'cure'? Please contact me directly ASAP! Thanks! --------------------------------------------- | Vincent J. Laurent | | Computing Information Center & | | Computer Learning Center 1 | | Southern Illinois University - Carbondale | | GX6692@SIUCVMB | --------------------------------------------- ------------------------------ Date: 25 Oct 89 21:11:00 +0700 From: "Okay S J" Subject: Xeno--possible new virus?(AMIGA) I received this from Amiga-relay this morning....From all reports, it appears that Xeno, if it is a virus, is the 1st non-boot infector virus in the Amiga community. All the others I've seen so far live in the boot sector and most Amiga anti-virals seem to only worry about the boot sector and in RAM at the time. I'll cross-post anything I hear from either side to their respective lists. - ---Steve - ---------- Stephen Okay Technical Aide, The MITRE Corporation x6737 OKAY@TAFS.MITRE.ORG/m20836@mwvm.mitre.org *************************CUT HERE CUT HERE********************************* Date: 24 Oct 89 11:21:03 GMT From: MTR780::WINS%"" 24-OCT-1989 13:36:26.00 Subj: Xeno - Another bad virus? From: Anssi Ahonen Newsgroups: comp.sys.amiga Subject: Xeno - Another bad virus? Does anyone have information about virus called 'xeno'? This little beast is living on my hard disk (30 meg Supra, A500) and after many unsuccesful tries I still haven't find it. It first showed up a few days ago when I opened the shell and tried to get directory with 'ls'-command. The shell just gave me 'unknown command ls', and after that I noticed that also 'CD'-command didn't work. Strangely, the programs were still in c-dir, just as usual. I loaded my favourite debugger and examined the broken cli-commands. Both programs were modified so that they only used DOS.Write to print out 'unknown command'. The weirdest thing was yet to come! I found a strange file named '!' in devs-directory. This file was an IFF-picture, black border, white topaz font text : "You will never catch me, the allmighty Xeno" So, this is probably the first virus to write iff-files on your hard disk? I have now examined most of the programs on my hard disk with debugger, searching for 'virus-signs', extra code hunks, xor-loops etc, but no luck. The only facts I know are: Xeno is not a bootblock virus. It doesn't change reset-vectors. I am pretty sure it is some kind of link virus (like IRQ), but much harder to beat. *********************END FORWARDED MESSAGE*********************************** ------------------------------ Date: Wed, 25 Oct 89 18:23:50 -0400 From: Tom Young Subject: SCANv45 and UNVIRUS (PC) RE: Posting by Sean Haynes of Northeastern in vol. 2, issue 222. I, too, have a report that SCANv45 is generating a positive for Jerusalem-B when checking UNVIRUS.EXE. I don't have v45 yet, so cannot confirm. But the copy of UNVIRUS that I've distributed here came from the hotel.cis.ksu.edu server, not SIMTEL20. And I have successfully used UNVIRUS to remove Jerusalem-B infections. My copy of UNVIRUS does not set off SCANv42. I suspect that the fault lies with the newer version of John McAfee's program. Someone should confirm this before people start doubting the integrity of the virus archive sites. Thanks. Tom Young, Cornell Information Technologies [Ed. See Jim Wright's message (in this digest) about SCANv45 producing false alarms.] ------------------------------ Date: Tue, 24 Oct 89 20:24:16 -0500 From: Peter da Silva Subject: reposting of FICTITIOUS virus story (UNIX) This is the "UNIX VIRUS" article I referred to in a previous digest. It was posted in this form, complete with postscript. No more than a week later the Internet Worm was loose. I was originally amused by the irony, but as it became clear that the IW was relatively uninfective (only infected Sun-3s and VAXen) I felt more secure about my final paragraph. I still do. The debate "raging in comp.sys.amiga" at the time was about whether UNIX was as susceptible to viruses as PCs were. :-> - -----------8<----8<--------------------------------------------------`-_-'-- The Usenet virus: a case history. A cautionary tale. The Usenet virus was detected when a user discovered that a program he had received from the net seemed to have two versions of malloc included with the source. One version of malloc might be odd, but people have never tired of reinventing the wheel. Two versions were suspicious, particularly since they lead to a name conflict when the program was linked. The first, lmalloc.c, seemed to be identical to the malloc listed in Kernighan and Ritchie. The second, bmalloc.c, was rather strange, so we concentrated our efforts on it... this time was later found to have been wasted. After a little work during spare moments over the course of a week we decided it was actually a clumsy version of the buddy system (a fast but space-inefficient method of memory allocation). It might make a good example of how not to write readable code in some textbook, but it wasn't anything to get worried about. Back to the first. It made use of a routine named speedhack() that was called before sbrk() the first time the malloc() was called. There was a file speedhack.c, but it didn't contain any code at all, just a comment saying that it would be implemented in a future version. After some further digging, speedhack was found at the end of main.c. The name was disguised by some clever #defines, so it never showed up in tags and couldn't be found just by grepping the source. This program turned out to be a slow virus. When it was run, it looked for a file 'lmalloc.c'. If it found it, or it didn't find Makefile, it returned. From then on malloc ran normally. If it didn't find it, it reconstructed it using a series of other routines with innocuous names tagged on to the end of other files. This was apparently an attempt to avoid overly increasing the size of any one of the files in the directory. Then it went into Makefile or makefile (it looked for both) and added lmalloc.o onto the end of the first list of '.o' files it found. It then reconstructed each of the extra routines, and speedhack itself, using techniques familiar to any reader of the obfuscated 'C' contest. These were tagged onto the ends of the '.c' files that corresponded to the '.o' files in this same list. The program was now primed to reconstruct the virus. On inspection, we discovered that about 40% of the sources on our system were infected by the speedhack virus, We also found it in one set of shell archives that we'd received but never unpacked or used, which we took as evidence that it had spread to a number of other systems. We have no idea how our system was infected. Given the frequency with which we make modifications and updates, it's likely that the original speedhacked code is no longer on the system. We urge you to inspect your programs for this virus in an attempt to track it to its source. It almost slipped by us... if the author had actually put a dummy speedhack in speedhack.c we would have merely taken lmalloc.o out of the Makefile and defused *this* copy of the virus without being any the wiser. There are other failings in this program that we have thought of. We have decided not to describe them to avoid giving the author of this program ideas we might regret. Some ways that programs like this can be defeated include 'crc' checks of source files and, of course, careful examination of sources received from insecure sites. - ----- Now I have to make a confession. This whole document is a hoax intended to dramatize the problems involved with viruses and Usenet. I suspect that most of you were clued to this by the Keywords line. While playing with the idea and writing this article several things occurred to me: First of all, this virus is a much more complex program than any of the viruses that have been spotted on personal computers. I think it has to be, based on the design goals that a REAL UNIX virus must satisfy. I have not attempted to actually implement it because of this. It must be small, to avoid detection. It must not cause files to grow without bound. It must infect foreign files, otherwise it's not a virus... just a Trojan Horse (like the bogus ARC and FLAG programs on the PC). Trojan horses are a dime-a-dozen. It must infect source files, since this is the primary software distribution channel for UNIX. A virus stuck on one machine is a boring one. It must not break the infected program (other than what it might care to do deliberately). It must not be obvious from a simple examination of the source (like, changing main to Main and having a virus-main call Main). I believe that given these goals (which are, of course, subject to debate) a simpler program would be unsuccessful in infesting more than a small fraction of the machines that (say) comp.sources.misc reaches. There are systems immune to this particular attack, of course. Ones not running UNIX, so sbrk() doesn't work. Or ones with radically different versions of malloc(). Ones with no 'c' compiler. They are in the minority, though. On the other hand a virus of this type could infest a large proportion of the net before it was found. The virus I described does not cause any direct damage, except for using up a relatively small amount of disk space. A more vicious virus is possible. Other variations of this virus are obviously possible. For example, it could be tagged onto any standard 'C' library routine... I chose malloc merely because source was available and because it's something that people complain about, so they wouldn't be likely to find an extra copy suspicious. Another good routine would be perror(), for the same reason. This would have the additional benefit of making the spread of the infection dependent on an additional random factor, making it harder to detect the virus. Do I think something like this is likely? No. Especially not now that I've written this little piece of science fiction. I'm sure that eventually someone will try something unlike this, I suspect that their virus would get caught much sooner than 'speedhack', because I think that more people look at the source than conventional wisdom would lead you to believe. But, again, this is just my personal opinion. Debate is welcomed... that's why I did this in the first place: to inject some sense into the debate currently raging in comp.sys.amiga. - --- Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation. Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-' "That particular mistake will not be repeated. There are plenty of 'U` mistakes left that have not yet been used." -- Andy Tanenbaum (ast@cs.vu.nl) ----------------------------- End of VIRUS-L Digest ********************* Downloaded From P-80 International Information Systems 304-744-2253