VIRUS-L Digest Monday, 23 Apr 1990 Volume 3 : Issue 79 Today's Topics: Writeable Executables Re: Disinfecting a Macintosh Re: Mainframe Viruses Virus Summary Document Stoned Found in shrink wrapped GEM/3 (PC) Length field of ~.EXE header (PC) Translation of ANARKIA virus description (PC) Re: Disinfecting a Macintosh Usenet "virus" {Ed. HOAX - no, that's *not* a UNIX variant...} Virus listings Viruses in text files (IBM VM/CMS) Another virus from Germany (PC) Twelve-Tricks (PC) 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. Please sign submissions with your real name. Send contributions to VIRUS-L@IBM1.CC.LEHIGH.EDU (that's equivalent to LEHIIBM1.BITNET for BITNET folks). Information on accessing anti-virus, documentation, and back-issue archives is distributed periodically on the list. Administrative mail (comments, suggestions, and so forth) should be sent to me at: krvw@CERT.SEI.CMU.EDU. Ken van Wyk --------------------------------------------------------------------------- Date: Fri, 20 Apr 90 12:19:00 -0400 From: WHMurray@DOCKMASTER.NCSC.MIL Subject: Writeable Executables The original argument as to wether executables was between Howard Aiken and John von Neumann. Dave Chess and Dave Ihnat associate themselvees with a long tradition when they debate it. A brief reading of history tells you that Ihnat/Aiken were right, i.e., correct, but that Chess/von Neumann carried the day. For reasons of economics most systems reserve the flexibility for executables to be writeable, even by themselves. Indeed, the only widely used systems that I am aware of that do not permit this are the IBM S/3X and AS/400. That they do not is a well kept secret, even in IBM. The mechanisms required to enforce this, and other data-type rules, include hiding all physical storage from the user and application, as well as a fully qualified program name that includes the version. While I have always championed Aiken, and, with Ihnat, am quick to restrict write permission to executables, I am enough of a realist to recognize that this strategy is hardly applicable to the problem at hand. The problem at hand is to stop the geometric growth of existing viruses in the existing environment. In the long run, the requirement for trust in programs will drive us inexorably in the direction of immutable programs and application specific machines. As storage and cycles become cheaper, the apparent penalty for this will vanish beneath the level of notice. Nonetheless, writeable executables will never disappear, it won't solve the current problem anyway, and in the long run, we are all dead. William Hugh Murray, Executive Consultant, Information System Security 21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840 203 966 4769, WHMurray at DOCKMASTER.NCSC.MIL ------------------------------ Date: Fri, 20 Apr 90 15:31:18 +0000 From: rutgers!umn-cs.cs.cs.umn.edu!thornley@uunet.uu.net (David H. Thornley) Subject: Re: Disinfecting a Macintosh MAINT@UQAM.BITNET (Peter Jones) writes: >This is probably a dumb question for the veteran MAC users but here >goes. A friend of mine tells me he needs to disinfect his MAC. I can >get hold of the anti-virus programs with no problem. But what bothers >me is how does one prevent the memory from being reinfected from the >hard disk, when the MAC is booted from a known good OS. On the PC, one >boots from a clean DOS; the hard disk isn't accessed until an explicit >command is given. Doesn't the MAC read its hard disk as soon as it >finds it? > >I would appreciate very explicit instructions for my friend, as I may be >able to be present at my friend's machine when the disinfection is done. The best way is to boot the Mac from a secure diskette. This diskette should have the system and the disinfecting program(s) on it, and should have the write protect tab in the open position. Put the diskette in and turn the Mac on. (The Mac is set up to boot from a floppy if offered.) If the computer ejects it, push it back in. You will then have booted from a secure system, and can proceed to disinfect the hard drive. Disinfecting numerous diskettes can be tedious, of course. David Thornley ------------------------------ Date: Fri, 20 Apr 90 13:26:00 -0400 From: <90_PENNYPAB@UNION.BITNET> Subject: Re: Mainframe Viruses About 6 years ago somebody at a California university (I think it was UCLA) performed an experiment on mainframe viruses. I remember this experiment because I incorporated it into a paper I was writing at the time on national security, including security to government computers. Unfortunately I don't have the paper any more, but I do remember (vaguely) where I got the information from. There was a small write up of the project in the Boston Globes Science section. I don't remember the exact date, but it was between October 1984 and February 1985. The experiment performed was as follows: The mainframe (I don't recall what type) was "sealed off", meaning that any network connections were removed, and all software was backed up. A virus was then introduced into an account with normal user privilages. The mainframe was then used in its normal way. By "normal" I mean that the various programs on the computer were used as if a group of typical users were doing what they usually do with the computer. While the computer was being put through its paces the activity of the virus was monitored. I believe that this procedure was performed only two or three times. The virus spread throughout the mainframe so rapidly that system administrators refused to allow it to be run any more. I believe that the fasted the virus propogated throughout the entire computer was within a matter of minutes after it was activated. Well, the above information is very sketchy. It's been 5 years since I've seen it, so I don't remember if it is entirely correct. But to anybody who really wants to find out more about mainframe viruses, I suggest that you try to find this Boston Globe article. It was very interesting. Bruce Pennypacker 90_PENNY@UNION.BITNET 90_PENNYPAB@GAR.UNION.EDU ------------------------------ Date: Fri, 20 Apr 90 09:37:50 -0700 From: Alan_J_Roberts@cup.portal.com Subject: Virus Summary Document There was a request for information in yesterday's Virus-L for a summary list of known viruses. The VSUM9004 document by Patricia Hoffman is by far the most comprehensive and is available on most FidoNet nodes, or on HomeBase at 408 988 4004. It is kept reasonably up to date and provides information on: Type of Virus; Size; Origin; Memory Resident Activity; encryption techniques; host types; and a detailed description of how they work, what activates them and the visual, disruptive or destructive activation symptoms. A very useful document. Alan Roberts ------------------------------ Date: Fri, 20 Apr 90 16:16:42 -0400 From: Jim Dunkin Subject: Stoned Found in shrink wrapped GEM/3 (PC) Shrink Wrapped Gem/3 Desktop Stoned Yesterday afternoon I helped a user get rid of the stoned virus that had infected his machine. This person believed that he had been infected from a shrink wrapped copy of "Gem/3 Desktop" that he had just purchased and tried to install. I was quite skeptical at first, but the disks were write protected, the write protect tab was UNDER the manufacturer's disk label, and the disk label appeared unaltered in any way. Still not being a true believer, I went out and bought a copy of GEM from the same store, and scanned the manufacturer's disks straight out of the shrink wrap. Sure eneogh, disk three of a five disk set contained the stoned virus, according to MacAfee's scan57. This version of Gem/3 is labelled "Release 3.13 RDK 04/89" with a serial number of 5153-1921. A technical representative from Digital Research Inc. in Toronto, Ontario, Canada indicated to me today that the disks I had were OEM disks, and that the retail outlet I bought them from, was not authorized to carry these disks. He is looking into the matter further. The retail outlet I purchased the disks from indicated that they will pull the disks as soon as they verify for themselves that there is a problem. Has anyone else out there stoned GEM disk??? ------------------------------ Date: Fri, 20 Apr 90 12:22:48 -0700 From: well!odawa@apple.com (Michael Odawa) Subject: Length field of ~.EXE header (PC) Recently Fridrik Skulason stated, > it is not always possible to detect if the program has been damaged beyond > repair by the [Jerusalem] virus. This may happen if the information on > the length of the file which is stored in the header is incorrect. I believe Fridrik was referring to the information in bytes 02-03 and 04-05 of an ~.EXE file, and if so, I would like to agree with what he said, but pick one small nit with the way he said it. The information in these fields is not the length of the file, but the length of the code image that is to be loaded prior to execution of the file. In commercial programs this value is nearly always "correct," though it may not coincide with the length of the file. When a linker creates an executable program in which code segments are overlaid upon each other, only a portion of the entire ~.EXE file need be loaded prior to execution. The remaining segments are loaded (and re-loaded) from either the ~.EXE or an auxiliary (e.g., ~.OVL) file when called. Michael Odawa Software Development Council odawa@well.sf.ca.us ------------------------------ Date: Fri, 20 Apr 90 15:59:00 -0400 From: Jim Shanesy Subject: Translation of ANARKIA virus description (PC) Virus Anarkia. It's a major variation of the Friday 13th virus. It actuates the same as before, but it releases all of its operations on the hour, not on the half hour like Friday 13th. In this variation of the virus the destructive effect is the 12th of October. The choice of this date is not clear, perhaps because the following day is a Friday 13th and to give a scare one day before, or perhaps because the 12th is Hispanic day. It can be found easily by looking for the string "ANARKIA". [Ed. Thanks to everyone who sent in a translation of the Spanish text that Frisk posted! I guess that there are indeed a lot of kind souls out there. Unfortunately, I'd have to post several (!) digests today just to send out all the translations that I received. Instead, I'm just posting this one (the first that I received). If anyone has any serious gripes/corrections in the translation, I'll post them. Otherwise, the above is the "official" :-) translation. Thanks again to all who responded! It's efforts like yours that make the networks *worthwhile*!] ------------------------------ Date: 20 Apr 90 13:06:31 +0000 From: vaxb.acs.unt.edu!ac08@cs.utexas.edu Subject: Re: Disinfecting a Macintosh MAINT@UQAM.BITNET (Peter Jones) writes: > This is probably a dumb question for the veteran MAC users but here > goes. A friend of mine tells me he needs to disinfect his MAC. I can > get hold of the anti-virus programs with no problem. But what bothers > me is how does one prevent the memory from being reinfected from the > hard disk, when the MAC is booted from a known good OS. On the PC, one > boots from a clean DOS; the hard disk isn't accessed until an explicit > command is given. Doesn't the MAC read its hard disk as soon as it > finds it? If you run Disinfectant, it will remove all (known) viruses, then ask if you want to reboot (to clear the memory of potential resident virii). Say 'Yes!' I haven't seen any problems with reinfection using any of the major antiviral programs on the Mac... and Disinfectant certainly helped us get our lab virus problem under control... Make sure you also check every disk that will be used in the machine... Or get SAM (Symantec Antivirus for the Macintosh), or Gatekeeper, or one of the other INIT/DA/CDEV type antivirals for the machine... saves lotsa trouble later. > > I would appreciate very explicit instructions for my friend, as I may be > able to be present at my friend's machine when the disinfection is done. If it's Disinfectant, just hit the "About" button and read away... tells you all you need to know. Chad Irby "Lookout! it's a code ac08@vaxb.acs.unt.edu resource, and it's \c loaded!" ac08@untvax ------------------------------ Date: Fri, 20 Apr 90 20:55:42 +0000 From: peter@ficc.uu.net (Peter da Silva) Subject: Usenet "virus" {Ed. HOAX - no, that's *not* a UNIX variant...} > I have to believe that the same yahoos who think viruses are fun > things on single-user OS machines like PCs and Macs would love to > infect Unix and VMS systems, if they could. They can. > I really do believe that these systems are more difficult to > circumvent, and this has, to some extent, accounted for great disparity > in the number of successful attacks on these systems as compared to the > single-user boxes. I believe you're right, *but* source code has little to do with it. It's been at least 6 months since I posted this little fable. 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 successful 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. +1 713 274 5180. / \ 'U` Have you hugged your wolf today? \_.--._/ v Disclaimer: People have opinions, organisations have policy. ------------------------------ Date: Sun, 22 Apr 90 20:38:00 -0400 From: ELKALAMARAS@VASSAR.BITNET Subject: Virus listings I am new in this discussion list, but in many ways old to the whole subject, since I have been working on various disinfectants since 1988 in Greece (I am also a BBS SysOp in Athens for a BBS which specialises in virus disinfectants). I would like to ask a question, and why not, start a discussion about the moral issue of publishing a virus listing for educational purposes on a magazine or a book. I have been writing a book about viruses (unfortunately it is in Greek but I hope to translate it when I finish it :-) ) and I have been puzzled with this issue. Is it ethically right to publish code that can create trouble for lots of people, even if it might be very educational for the non-malicious types of programmers? If not, is it right to publish disinfectant or vaccine code? Because even the vaccine code can be easily transformed into a virus itself, if you only reverse the procedures... My opinion is that it is inevitable that malicious people will find the way to write a virus. Therefore, it is OK (in some ways) to publish code, because it will educate people so that they have the tools to fight those viruses. Anxiously waiting for your replies, Lefteris Kalamaras Vassar College - ------------------- Of course, what I think does not represent Vassar anytime!!! - ------------------- ------------------------------ Date: Sun, 22 Apr 90 20:22:00 -0400 From: Lynn R Grant Subject: Viruses in text files (IBM VM/CMS) Viruses certainly ought to be possible under VM, using the Waterloo Script text formatter. This formatter has a .sy command that lets you execute VM/CMS commands while your text file is being formatted. It is handy for running EXECs to allocate files your document has to include text from, but it could easily be put to more sinister uses. ------------------------------ Date: Mon, 23 Apr 90 08:28:00 -0500 From: Christoph Fischer Subject: Another virus from Germany (PC) Over the week end I disassemled a new virus, it was found in Stuttgart, West-Germany during an anti-virus campaign of a computer magazine. Here are the facts: 1. It infects COM and EXE type files via INT 21 (4b00) 2. It installs a TSR 3. after its trigger date it will play randomly one of 8 tunes 4. COM type files grow by 1971 bytes EXE will grow 1971 + up to 15 bytes 5. It uses INT 21 INT 08 INT 24 6. Its "music engine" is able to resolve 1/8 notes, doted notes, legato non legato, stakato and so on 7. 4of the first 6 tunes are typical German hiking or roving songs dating back to a "Back to Nature Movement" in the twenties. The 7th tune ist I think garbage. The 8th tune is part of the coding of the virus itself. (tune 1: "Jenseits des Tales ..." tune 2 : "Horch was kommt von drausen rein" tune 3: "Auld lang syne" tune 4: "Wenn die bunten Fahnen wehen ..." tune 5 : "Nobody knows the trouble I've seen" tune 6 : "Hoch auf dem gelben wagen" tune 7 : garbage tune 8: INT 08 handler) This is a preliminary analysis, more will follow. Fridrik Skulason, Dr. Alan Solomon and John McAfee will or have already included this virus in there scanners. As a name I discussed with Dr. Alan Solomon "8-tunes". Sincerely Christoph Fischer ***************************************************************** * Christoph Fischer and Torsten Boerstler and Rainer Stober * * Micro-BIT Virus Team / University of Karlsruhe / West-Germany * * D-7500 Karlsruhe 1, Zirkel 2, Tel.: (0)721-608-4041 or 2067 * * E-Mail: RY15 at DKAUNI11.BITNET or RY12 at DKAUNI11.BITNET * ***************************************************************** ------------------------------ Date: Mon, 23 Apr 90 08:53:56 -0500 From: Christoph Fischer Subject: Twelve-Tricks (PC) Hi, two questions connected to twelve tricks recently appeard on VIRUS-L 1.Someone has found "twelve tricks - B" on his disk. well there is no such thing as twelve tricks - b the scanner from H & B EDV looks for a string, that is expected in an infected partition table, in normal files. They didn't read well Dr. Solomon and I published an exact report on VALERT-L. This string can't be found in the "dropper" program as well since the "dropper" program uses an encryption method to hide its infection code! 2.The gentleman that claims he really has twelve tricks should check if he isn't fooled by the same problem as above. If not I sugest low-level format / fdisk / high-level format / restore from back-up find the twelve tricks dropper and delete that file ( if it is something else than a hacked version of the core-test programm please let me know! We have hundreds of calls of people who run the above mentioned scanner, it was distributed via a special edition of the CHIP magazine!!! Sincerely Christoph Fischer ***************************************************************** * Christoph Fischer and Torsten Boerstler and Rainer Stober * * Micro-BIT Virus Team / University of Karlsruhe / West-Germany * * D-7500 Karlsruhe 1, Zirkel 2, Tel.: (0)721-608-4041 or 2067 * * E-Mail: RY15 at DKAUNI11.BITNET or RY12 at DKAUNI11.BITNET * ***************************************************************** ------------------------------ End of VIRUS-L Digest ********************* Downloaded From P-80 International Information Systems 304-744-2253