VIRUS-L Digest Friday, 27 Oct 1989 Volume 2 : Issue 224 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: Using OBJ files to prevent viruses (PC) Macintoch MacWrite, STR 801 (Mac) Obj - anti-virus (PC) Re: Operating System virus protection (DOS & UNIX) Re: VIRUSCAN/VIRSCAN Issues (PC) VIRUSCAN False Alarms (PC) CERT_RCP_Advisory Can we get a summary? Virus scanners Clarifying SAM Comments... (Mac) Jerusalem virus infects boot sector ? (PC) PC Problem? --------------------------------------------------------------------------- Date: 26 Oct 89 09:15:00 -0500 From: EVERHART%ARISIA.decnet@crdgw1.ge.com Subject: Using OBJ files to prevent viruses (PC) May I suggest that distributing .OBJ files and having the user link them would only disable current viruses; an obj infector is perfectly feasible, and could be easier than an .EXE infector. More to the point, though, linking applications is not always feasible at all PC sites. To link AnalytiCalc on a 256K machine with dual 5.25" floppies is barely possible, with many disk changes, and requires some skill AND the correct linker (since the linker distributed with most MSDOS versions cannot handle the particular .OBJ constructions). This even though the resulting executable will fit (tightly) in 256K. With an only slightly larger file, linking would be completely infeasible on such a small engine. In addition to a fairly onerous "installation" procedure thus invoked, the distribution would be several times larger than it is; the object library requires an entire disk, and separate objects needed for overlays take much of a second. Documents, utilities, and so on are still required. Finally, commercial software vendors may be nervous about distributing .OBJ code. Consider that global symbols, and sometimes internal symbols, are present in these files. A disassembly of such a beast can be VERY close to the original code, labels included...especially if the original is IN assembler. This is wonderful for learning algorithms, etc., but tends to make it easier to clone applications. In the current climate I suspect it would lead to a great many more lawsuits based upon suspicions that competitors' code was derived in part from such sources. Unfortunate, but likely... Then, some object libraries that come with compilers can be linked and the results distributed; without these, the .OBJ files cannot be linked. This would also prevent widespread use of .OBJ files. In a different vein, may I suggest that a great deal of the hysteria over viruses stems from the fact that well backed-up PC disks are the exception rather than the rule. As an industry we should become VERY upset over machines with inadequate backup hardware and software. More energy in this direction could render the damage viruses can cause moot. By easy backup/restore, I mean hardware such that one can slap a tape into a slot, type some simple command, and after a few minutes (over lunch break, perhaps?) come back with the entire volume copied. Not having this designed into ALL the PCs we use, or at least made a requirement for those containing business-critical data, seems a mistake. As Grace Hopper put it, we are terrible custodians of the data we have/use. Glenn Everhart Everhart%Arisia.decnet@crd.ge.com ------------------------------ Date: Thu, 26 Oct 89 10:39:09 -0500 From: Joe Simpson Subject: Macintoch MacWrite, STR 801 (Mac) I'm unclear about the STR 801 discussion. Let me tell a little story to see if I can further confuse things. About 4 months ago a client reported that MacWrite was growing in file size on a public Mac. I checked to see that VACCINE was turned on. I ran Disinfectant 1.2. A clean machine. I then ran ResEdit to look at the MacWrite file. There were a large number of STR 801 resources. The program was adding STR 801 resources at some unknown interval. I replacedthe file with a fresh copy of MacWrite and the problem disappeared. I put it down to normal computer miseries and not a computer virus. ------------------------------ Date: Thu, 26 Oct 89 10:39:00 -0400 From: "Paul Bienvenue" Subject: Obj - anti-virus (PC) Damon Kelly writes: > 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? It's a nice idea, but it wouldn't really stop virus writers, just make life a little more difficult for them. (and possibly for virus detectors as well) What would keep a virus writer from creating an obj which would become a virus when compiled? Also, it would be a real pain for users to have to compile every piece of software they were going to use. Anyone with much assembling experience would also know how difficult it is to write code which will successfully compile with all major assemblers. Good try, though... Paul Bienvenue S0703PDB@SEMASSU.BITNET ------------------------------ Date: Thu, 26 Oct 00 19:89:08 +0000 From: davidsen@crdos1.crd.ge.com Subject: Re: Operating System virus protection (DOS & UNIX) | How do you know? The only machines DOS runs on are PCs and compatibles. | UNIX implemented on these machines would be just as vulnerable as DOS. | The most obvious weaknesses of DOS are unimportant compared to the fact | that the hardware itself has no protection mechanisms. True, but only of the 8088 (original XT) machines. The AT and 386 machines run UNIX in protected mode, and have as much hardware protection as a VAX. - --- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "The world is filled with fools. They blindly follow their so-called 'reason' in the face of the church and common sense. Any fool can see that the world is flat!" - anon ------------------------------ Date: Thu, 26 Oct 00 19:89:34 +0000 From: davidsen@crdos1.crd.ge.com Subject: Re: VIRUSCAN/VIRSCAN Issues (PC) You have a good point about encrypting strings, and I am as guilty as anyone else of not saying thanks often or publically enough. Due to the recent flap about viruses, I gave a talk about protection at a local user group meeting, and distributed about 40 copies of viruscan, including putting a copy on my BBS. I am happy to say that I am not a user of the program, since I run UNIX, but I have tried it, am impressed, and do provide it to any PC user who wishes it. Well done, for what it's worth! - --- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "The world is filled with fools. They blindly follow their so-called 'reason' in the face of the church and common sense. Any fool can see that the world is flat!" - anon ------------------------------ Date: Thu, 26 Oct 89 10:52:42 -0700 From: portal!cup.portal.com!Alan_J_Roberts@Sun.COM Subject: VIRUSCAN False Alarms (PC) This message is forwarded from John McAfee: ============================================================================= SCANV45 causes false alarms when used with a number of Jerusalem Virus detectors/eradicators. What has happened is this: I returned to an earlier version of string identification for this virus in order to avoid conflicts with a number of newer Jerusalem detectors. Apparently, however, the string identifiers used in earlier versions (being unencrypted) were picked up on by other authors (perfectly legitimate) and used in their own detectors. There are over 30 such detector/eradicator programs in use now. I stgrongly urge all such authors to do one of two things: Choose your own strings, or encrypt them if you use strings from older versions of SCAN. Otherwise, your programs will be flagged as viruses not just by my scanner, but by everyone who chooses those same strings. The problem is worsened now cause I use multiple strings for some viruses (to avoid cracking) and either one of the multiple strings will cause an alarm if that string is chosen by others and not encrypted. If authors do not like the idea of encryption, then ASCII representations can be used (like IBM uses). THis will allow your users to see the strings that you have chosen but will not cause false alarms. We must all remember that multiple authors are trying to fight the virus problem, and we should do everything possible to avoid conflicts with each other's programs. John McAfee ------------------------------ Date: Thu, 26 Oct 89 21:24:58 -0400 From: CERT Advisory Subject: CERT_RCP_Advisory CERT Advisory October 26, 1989 Sun RCP vulnerability A problem has been discovered in the SunOS 4.0.x rcp. If exploited, this problem can allow users of other trusted machines to execute root-privilege commands on a Sun via rcp. This affects only SunOS 4.0.x systems; 3.5 systems are not affected. A Sun running 4.0.x rcp can be exploited by any other trusted host listed in /etc/hosts.equiv or /.rhosts. Note that the other machine exploiting this hole does not have to be running Unix; this vulnerability can be exploited by a PC running PC/NFS, for example. This bug will be fixed by Sun in version 4.1 (Sun Bug number 1017314), but for now the following workaround is suggested by Sun: Change the 'nobody' /etc/passwd file entry from nobody:*:-2:-2::/: to nobody:*:32767:32767:Mismatched NFS ID's:/nonexistant:/nosuchshell If you need further information about this problem, please contact CERT by electronic mail or phone. J. Paul Holbrook Computer Emergency Response Team (CERT) Carnegie Mellon University Software Engineering Institute Internet: (412) 268-7090 (24 hour hotline) ------------------------------ Date: Thu, 26 Oct 89 21:16:31 +0100 From: cas@mtdcb.att.com (Clifford A Stevens, Jr) Subject: Can we get a summary? I'm new to all this stuff, been on superminis for 10 or so years, so could somebody post a summary of what a virus is, how it works (in *REAL* general terms), and how it propogates? Thanks! [Ed. This is a frequently asked question; let me "answer" it by referring you, and others who've asked, to some of the introductory documents found on the VIRUS-L/comp.virus documentation archive sites - - or to any of the introductory books on the subject, many of which can be commonly found in bookstores.] Who, me worry?!? Cliff Stevens MT1E228 att!cbnewsj!ncas (201)957-3902 ------------------------------ Date: Thu, 26 Oct 89 18:58:33 -0700 From: portal!cup.portal.com!cpreston@Sun.COM Subject: Virus scanners In VIRUS-L #222 David Gursky wrote concerning an earlier posting that "a strategy that relied solely on a scanner application would not be a strong defense defense against electronic vandalism." This is because "you must remember to periodically scan the disk." I believe Mr. Gursky is quite correct about not relying solely on a scanning program. While I was mainly relying on the technical sophistication of VIRUS-L readers to know that, I did mention qualifiers such as "very useful part of an anti-virus program." Actually, there are programs for the Macintosh (SAM, Virex) that can be set to check each floppy disk each time it is inserted. Or a "log-on" or "log-off" batch file could be used for other machines to run the scanning program against all the hard disk files. Even if that were done, it would still not be adaquate protection against viruses, even on microcomputers, since it can be effective only against known viruses. My point about "How good are scanning programs" is mainly that if the program uses well-chosen search strings it can be more effective than I, at least, initially expected. Several scanning programs for the Macintosh relied only on resource names (resources include program code on the Mac). These resource names, such as nVIR, are very easily and quickly changed to hPat or anything else, completely defeating the scanning program. I always urge clients to use additional detection and prevention, and am somewhat frustrated that some of them feel that scanning programs will protect them. Charles M. Preston MCI Mail 214-1369 Information Integrity BIX cpreston Box 240027 907-344-5164 Anchorage, AK 99524 ------------------------------ Date: 26 Oct 89 17:05:00 -0700 From: harvard!applelink.apple.com!D1660@garp.MIT.EDU Subject: Clarifying SAM Comments... (Mac) In response to Henry Schmitt's comments about SAM, I would like to clear up a few things. SAM does indeed provide a mechanism to view, edit, and even print its exceptions list (i.e., the alerts that have been learned). It's quite easy to remove any exception that may have been accidentally entered. So his comments about SAM letting a virus through, etc. are not true. Also, I programmed the alert display in SAM without the help of MacDTS (I too am simply an independent developer)! BUT, I believe how I do it is even safer than how Apple does certain similar things! This was the hardest part of SAM, and required quite a bit of research, testing, and so forth to guarantee a stable alert under all environments. There are man-months of work in those alert boxes!! Paul Cozza SAM Author ------------------------------ Date: Fri, 27 Oct 89 11:23:16 +0700 From: "S. Yeo" Subject: Jerusalem virus infects boot sector ? (PC) Hi everybody, My colleague passed me a diskette which contains a viruscan program from Rotterdam this morning. While looking through a file which contains some virus signatures, I was surprise to learn that all Jerusalem strains of viruses except Jerusalem (PLO/sUMsDos) virus infect COM/EXE files as well as*boot sector*.The documentation for this program was written by J.P. van der Landen and the signatures collected by Jan Terpstra. Could anyone out there please verify this? Thanks ! ------------------------------ Date: Thu, 26 Oct 89 23:54:48 -0500 From: James Ford Subject: PC Problem? A friend who works a company began to experience some interesting problems on his hard drive. He works with JL Modula2. Code that had run in the past would not work now. Someone else could put a comment in a file (however you do that in Modula2), re-compile it, and it would hang. I gave him a copy of Scan 1.1V45 and Scanres 1.1V45, but they found nothing strange. He has purchased a copy of Flushot, and the following message is from him, describing what Flushot sees. Can anyone explain this? If you need more information from him, send direct to me and I'll ask him. For better or worse, the powers-that-be are leaning towards taking all source code off the hard drives, and doing a lowlevel/highlevel format of all harddisks involved. (I have no ideal if he has installed Flushot+ correctly, but he is by no means ignorant when dealing with computers.) Thxs James Ford - JFORD1@UA1VM.BITNET =========================================================================== Sent : Oct 25, 1989 at 5:44 PM Subj : Re: <1446> Bit (...after running SCAN 1.1V45, it found...) Not a thing.. it found nothing either on my systems or the ones at work. I'm still totally convinced something is sorely amiss, however. We installed Flu+ and watched JPI's Mod 2 compiler/linker do all kinds of strange calls (Flu+ labeled them as 'handle write access attempted' operations, but they appeared to be reads... why would anyone write to a 'DEF' file during a link? I checked them with a disk editor afterwards and found nothing but pure ASCII text...) I did discover one interesting thing. When you copy a non-executable file with COMMAND.COM, Flu is perfectly happy. When you copy an EXE, COM, etc. file you get the old 'handle write access attempted' msgs. Curious. Why would COMMAND.COM care what type of file is being copied? It seems to use DOS to open the file and the BIOS to transfer the data or something. The only thing I can figure with the compiler is that the program opens the file for READ/WRITE and Flu+ flags it just to be safe. We all got tired of the beeping, and Dean absolutely refused to believe anything was wrong, so everyone just kinda went back to doing their stuff and just checked it occasionally. Anyway, I really appreciate your uploading SCAN45 - I'm gonna keep pluggin and see if I can find out the problem. I'm also gonna call McAffee Assoc's board tonite and see what I can start finding out. Thanks! - -=Marcel=- ====================== end of note ======================================== ----------------------------- End of VIRUS-L Digest ********************* Downloaded From P-80 International Information Systems 304-744-2253