VIRUS-L Digest Tuesday, 12 Nov 1991 Volume 4 : Issue 215 Today's Topics: Re: A couple questions (Mac) (Commodore) IBM Anti-Virus Product 2.1.5 (PC) Re: write protect tabs Request for info on PC virus AirCop (PC) re: Real User re:viruses and "viruses" Hong Kong Virus found (PC) Interesting use for SafeMBR (PC) First SPARC Virus? (Character Replacement Within Files) (UNIX) Updating hardware Re: UNIX anti-virus program (UNIX) Re: Taxonomy Re: Virus removals vs. Virus classification Re: Hardware... Re: Disk Compression (PC) Subjects 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 VIRUS-L at LEHIIBM1 for you 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, 08 Nov 91 11:07:24 -0500 >From: Joe McMahon Subject: Re: A couple questions (Mac) (Commodore) Tony writes: >Well, I use this MacIntosh SE that the school has provided me and it >works nicely, but recently my roommate erased all of the anti-viral >programs and thus I was prone for an attack, which occurred. An OLD >virus, nVIR B, hit. No biggie, but the ANTI-virus program VIRUS >DETECTIVE removed the virus resource, but didn't redirect the >pointers, so I had a useless System, Finder, and Term program. You alarm me. Your roomie killed your hard disk copy and all of your backups, too? :-) I believe that the documentation for VirusDetective specifically states that using its "delete viral resources" feature can damage your files; I always take "can" in documentation to mean "will". Install the Disinfectant INIT. Free and small. >What makes the difference between the two is this, one is constantly >on - going from one application to another, while the other has to >constantly be shut off. On a Mac, (OR IBM for that matter) if you >want to increase the ANTI-virus protection, just after EACH >application shut the system off. The virus MAY still spread, but then >again, it may not. No. It *will* spread. Running an infected program will infect your machine. Scenario: Run an nVIR-infected program with no protection. It starts up and noiselessly infects the System file. You shut down. You reboot. You run another uninfected program. The copy of the virus in the System file gets the new application. You have gained nothing. If most of your Commodore disks are bootable, essentially you have multiple different computers which all run a single program and which never contact each other. That's what keeps viruses down on your Commodore. >Another reason why my Commodore can't be infected is that it has its >DOS in ROM not in a modifyable DISK which is then loaded into RAM. >Both are loaded into RAM, but on the Commodore, it cannot be changed >with software. I'm not so sure about "can't". Certainly interpreter-level viruses could be spread on a Commodore; how about a viral BASIC program? --- Joe M. ------------------------------ Date: 08 Nov 91 11:23:29 -0500 >From: "David.M.Chess" Subject: IBM Anti-Virus Product 2.1.5 (PC) A new level of the IBM Anti-Virus Product now exists. It should be available now or shortly from IBM Marketing Reps, Branch Offices, the Electronic Software Delivery section of IBMLINK, and on Promenade (the PS/1 support BBSy-thing). I'll attach the contents of the WHATIS.NEW file. As I said a bit ago, I'm not an Official Anything, so don't send me your money! *8) This has actually been out for a little while now, but I just noticed. Sorry as usual... As before, the U.S. terms are $35 for an original license, $10 for an upgrade (for terms outside the U.S., contact your country IBM). Note that these prices are for an *enterprise* license, so if you are a company with a thousand employees, it's $35 for all thousand copies. The last released version was 2.1.2, this is 2.1.5. Versions 2.1.3 and 2.1.4 were internal IBM versions, and not released. DC The IBM Anti-Virus Product, Version 2.1.5 Copyright (C) IBM Corporation 1989, 1990, 1991 The following are the highlights of the changes and enhancements made to The IBM Anti-Virus Product since the release of Version 2.1.2: - Added new virus signatures, modified signatures to identify virus variants, and updated virus information (refer to VIRSCAN.DOC, section 5.1, for more details) - Added a new "test mode" (-X) switch. - Improved VIRSCAN's identification of network drives in protect mode sessions under OS/2 1.2 and later. - Provided the ability to scan master boot records in OS/2 protect mode sessions. - Locked drive no longer identified as a network drive. - When "APPEND /X" or "APPEND /X:ON" is used, VIRSCAN no longer scans every directory in the APPEND path multiple times. - Made changes to handle an error reading HPFS boot sectors when VIRSCAN is run in the OS/2 DOS Box. - Added support for "family signatures" to some virscan signatures. - Added a "-U" option that allows users to add filetypes to the default filetypes that are scanned (e.g., to scan for all files of type EXE, COM, OV?, INI, SYS, BIN, and GUM on the C: drive enter the command VIRSCAN C: -U*.GUM) - Added support for an "options" file. Virscan will look for the file "VIRSCAN.OPT", in the same directory as "VIRSCAN.EXE", and if found VIRSCAN will read command line options from that file and add them to whatever command line options are on the actual command line. The -NOPT switch is available to turn off the option file support. ------------------------------ Date: 08 Nov 91 11:56:15 -0400 >From: "Jim Pinson" Subject: Re: write protect tabs turtle@darkside.com (Fred Waller) writes: >Write-protect tabs are not `near'-perfect - they ARE perfect. >Totally, not just `near'; there's no software bypass of a write- >protect tab. True, a write-protected disk cannot be updated... True enough, I know of no way to bypass, via software, the write protect feature. Such diskettes are not absolutely secure however. I once made a simple modification to a floppy drive so I could write to protected diskettes. These diskettes were used in a student lab where the students could not accidentally infect them with a virus. If I had malicious intent, I could have "borrowed" someone's original protected application diskette, and infect them. If that person assumed that no virus could possibly be on that disk, and failed to scan them, they would find themselves infected. Granted, this is not simple virus infection, but a combination of sabotage and virus attack. The point is that too much confidence that you have a "perfect" defense can leave you vulnerable to other forms of attack. Now if you keep your diskettes in a safe....... Jim Pinson UGA ------------------------------ Date: Fri, 08 Nov 91 12:33:00 -0500 >From: DOUG%HUGIN@NORWICH.BITNET Subject: Request for info on PC virus AirCop (PC) We have a high Infection rate of public access disks. They are infected with the virus AirCop according to McAfee's Scan program. So far there have been no problems with the disks, except that they have the virus in the boot sector and infect any other disks they come in contact with. 1. Can a data disk (not bootable) which is infected with AirCop infect another disk (bootable or not) with AirCop. (I am about to run some tests and see if this is true, but I would like some other opinions.) 2. Is this virus as benign as it appears. What does it do except infect other disks. Please send messages to Doug@Norwich.bitnet because I'm not a member of this list. Thanks. ------------------------------ Date: 08 Nov 91 12:20:31 -0500 >From: "David.M.Chess" Subject: re: Real User > From: turtle@darkside.com (Fred Waller) No one skilled enough to post to VIRUS-L counts as a "real user" the way I was using the term! *8) OK, I think we're converging as we come to understand better what we're really saying. This generally seems to happen in net-disagreements! Once all the differences in tone and accidental offenses are cleared up, people have only slight bits of easy-to-live-with disagreement, if that. I would disagree that promotion, availability, and distribution are the *only* reason that people are using software rather than hardware, but it's certainly part of it. I think it'd be neat if good hardware solutions would be designed and made available. Maybe we can usefully brainstorm about them here. I just (still!) think that software will always be useful, too, and until I see what people put together as hardware solutions it won't be -obvious- to me that hardware is inherently better. > Write-protect tabs are not `near'-perfect - they ARE perfect. This is the sort of statement that causes folks to flame at you! *8) It's true, of course. Or, more to the point, this is true: - If you want to make a diskette unwriteable by normal non-broken diskette drives, putting on a write-protect tab (a nice thick opaque one) works perfectly (modulo quantum mechanics). ((TRUE)) No one disagrees with that. HOWEVER, it's clear that the following is *not* true, and your sentence might be interpreted as claiming that it is (similarly, some of your other statements about hardware have had similar potential "mis"readings): * If you want to keep the machines under your control from becoming infected by viruses, you can do it perfectly by using write-protect tabs. ((NON-TRUE)) Now that's of course not true for lots of obvious reasons. So when you say that something is "perfect", you have to state very clearly what it's perfect *at*! Otherwise you're open to misinterpretation. Of course, the claims won't sound nearly as exciting if fully spelled-out that way! (Sorry, couldn't resist...) I realize that your earlier strong statements were also given in a context that qualified the strong terms. But in general if you're going to weaken a claim later, it's best not to make the strong form at all, because it gets folks' hackles up (at least in part because we've seen less-technical folks wander by and claim blithely that a *really* perfect solution would be "easy" if we just had X (or Y or Z); people probably mistook you for one of those...). DC P.S. Thanks for not changing the "Subject:" line! ------------------------------ Date: Fri, 08 Nov 91 19:03:00 >From: "Axel Gutmann" Subject: re:viruses and "viruses" In his reply to a posting of mine concerning analogies between biological and computer viruses which closed: >> I'd like to do to old STONED what we did to the smallpox-virus! turtle@darkside.com (Fred Waller) writes: >Easy. A vaccination for the Stoned has existed for a long time. >Several, in fact. Use it on your diskettes, and the Stoned will >never attack them. :-) I don't want to go deeper into this analogy stuff as I a) don't think it's (very) important, b) am neither biologist nor programmer (student of mech. engineering) and would soon run out of arguments :-), c) don't totally disagree with You. You're sure right with Your opinion that this analogy shouldn't be driven too far as it's easily misunderstood (especially in newspaper articles), but You misunderstood my last sentence. I'm not personally afraid of getting "infected" with the STONED. What I meant is that I'd like to see STONED getting as rare as the smallpox virus has become thanks to vaccination, so that even non-"vaccinated" computer-users run no serious risk of getting "infected" even if the STONED (like smallpox) isn't totally eradicated. ************************************************************************ *Axel Gutmann, uh2m@DKAUNI2, Internet: uh2m@IBM3090.RZ.UNI-KARLSRUHE.DE* ************************************************************************ ------------------------------ Date: 08 Nov 91 15:29:43 -0600 >From: DAVID W LAVIGNE Subject: Hong Kong Virus found (PC) I have two Dell Computers with the Hong Kong Virus which is what Central Point Anti Virus said. However, This version of C.P.A.V. does not remove the Hong Kong Virus from the Hard Drive. I sent off for the new version of Anti Virus but they sent the same version I had which is 1.0 not 1.1 Is there another way of removing it? I tried removing the part and putting it back and reformating but that did not work. Thanks..... Running MS-DOS 3.31 * David W LaVigne, ------------------------------ Date: Fri, 08 Nov 91 19:11:02 -0500 >From: padgett%tccslr.dnet@mmc.com (A. Padgett Peterson) Subject: Interesting use for SafeMBR (PC) Just found an interesting use for the SafeMBR program: If installed following a clean boot of a machine infected by a virus containing the Partition Table code in its body (e.g. Stoned, Azusa/Hong Kong, Aircop, & other non-stealth infections), it will replace the virus with itself. One caveat however: since the present version was designed to be used on a clean machine and to preserve the original MBR, the virus code will be moved to sector 2 and use of the restoration program (2to1.com) will restore the virus, not the "original" MBR. Padgett ------------------------------ Date: Sat, 09 Nov 91 04:22:15 +0000 >From: cmcl2!tester@uunet.uu.net (L Testerville) Subject: First SPARC Virus? (Character Replacement Within Files) (UNIX) I've been experiencing some very unusual problems and posted the following article to alt.sys.sun regarding the phenomenon. I've included it here for your consideration and/or suggestions/comments. - -=-=-=-=-=-=-=- Recently, it was necessary for me to restore an entire filesystem from backups. The system in question is a SPARCstation 1+ with 40M, CG3, two 1.6G Wren drives, one 1.2G Wren drive, no internal drive, EXB-8200 8mm, and Wangtek 6200HS 4mm tape. After successful filesystem restoration from tape, I noticed that there were quite a few errors going from single user to multiuser due to syntax errors in the /etc/rc* files. Specifically, character: "[" was turned into "{" and "]" was turned into "}". This, however, was not the only anomaly or set of files experiencing problems. The format.dat had several instances of the "\" being replaced by "|". In both situations not every instance of the affected character experienced this replacement phenomenon. It seemed to randomly affect the target characters in different places. Thinking back, I recall several instances when compiling source that /usr/include/*.h or /usr/include/sys/*.h files would have syntax errors. Usually in the form of spurious "^?" characters appearing at strategically annoying spots in the subject .h file. I didn't think anything of it at the time, but now it occurs to me that the strange system failures that I've experienced lately may be due to this kind of corruption taking place within binary files (or the kernel [vmunix] file itself). Has anyone else out there seen this kind of phenomenon before? The OS version I'm using now is 4.1.1 from the CDROM distribution. Only source from reasonably secure locations have been compiled and utilized (if you consider UUNET and gatekeeper.dec.com to be "secure"). Suggestions or comments would be appreciated as this is my personal/home machine and I can ill afford any more loss of data integrity. (Is this a matter CERT should be made aware of?) \\Lee thx1138@nyu.edu ------------------------------ Date: Fri, 08 Nov 91 22:00:08 -0800 >From: turtle@darkside.com (Fred Waller) Subject: Updating hardware Writes magore@watserv1.waterloo.edu (Mike Gore): > ...it should be noted that hardware will likely have to change > as system requirements change also. Well, yes. I didn't have THAT much permanence in mind . When the machine itself is changed, it's possible that any hardware devices ancillary to it might also be changed. And then again, maybe not... . What I meant is that, unlike software antivirus devices, which must be constantly updated in response to new challenges from new forms of viral attack, hardware devices are inherently more stable and robust, and can forestall attack without regard for new virus variations ("strains", types, etc.). Once you have one, you don't need to download the next version two weeks later... and another two weeks after that! . Hardware is... a lot less fickle, shall we say. > At some point more effort will be spent trying to patch a > badly designed system then starting from scratch would... Well, this is unfortunately the (PC) world we live in. But it's hard for many to contemplate junking 60 million PCs running MS DOS, even if it would allow us to start from scratch with Chris' Virus Proof System... > Regarding this debate in general - One often sees the argument > that ANY system can be broken in regards to the question of fixing > this problem - but why is it that, in the REAL world, we don't > leave our money in paper bags on park benches but still use vaults > _because_of_this_fact? The lesson here is there will be a point > were some degree of protection will reduce crime to a reasonable > degree given it will cost the offender too much to be of interest. > The PC with its hardware and software, as it stands now, is this > "paper bag" of the analogy in question... Uh-uh... this kind of plain, down-to-earth reasoning won't get you anywhere. Sorry. You could be absolutely right, but if your ideas don't agree with Cohen's theories, they couldn't possibly be of any use to anyone... Even if they work in practice. Who cares if they work in practice. They're not supposed to. THAT's what matters! Fred Waller turtle@darkside.com ------------------------------ Date: Sat, 09 Nov 91 08:26:21 +0000 >From: plains!umn-cs!LOCAL!aslakson@uunet.uu.net (Brian "Zamboni" Aslakson) Subject: Re: UNIX anti-virus program (UNIX) tommyp@ida.liu.se (Tommy Pedersen) writes: >I wrote: [Tommy Pedersen] >>TCell is a commercial UNIX virus checking program that the company I >No, there are no virus to check for on UNIX systems around today, so I So TCell isn't a virus checking program. Don't call it a virus checking program if there aren't any viruses that it can check for. Call it a checksumming program, call it an administrative tool, but do NOT call it what it isn't. Brian <-= Glad that there aren't many Mac viruses - -- .signature: No such file or directory ------------------------------ Date: Sat, 09 Nov 91 13:50:27 +0000 >From: Fridrik Skulason Subject: Re: Taxonomy In Message 5 Nov 91 04:22:57 GMT, turtle@darkside.com (Fred Waller) writes: > Those are not virus families, those are single virus names. Wrong. Either you have a very unusual understanding of what a virus family means, or you simply misunderstood my article. My list of families is by no means perfect - there are a few cases where questions remain, such as whether the W13 group should be considered a separate family, or just a subgroup of the Vienna viruses. In general, however, I believe most researchers accept most of the entries in my list as legitimate families. > Since no information whatsoever is given as to which viruses he would like > included in each of these "families", the list is not very useful. It is useful to a few people who have a good understanding of viruses, who recognize most of the names, and who have already developed a similar list of families on their own. I admit it is of little use to most readers of this newsgroup, except maybe to give an idea of the complexity of the classification problem. > The list consists of over 270 names. How does it relate to the NIST > proposal? Is it being suggested that known viruses should be simply > divided into 270 "families" Yes, this is exactly what I am doing. Of course, around half of the families have only a single member, with the rest containing from 2 to 50+ members. > without any rationale being presented for such division The rationale is quie simple - If two viruses are developed independently and share practically no code they are classified as belonging to two different families. Period. > without even listing what individuals fall in each "family" I don't think any researcher with a sizable collection of viruses has a problem with that part - there is no real disagreement on how to group viruses together - and it is generally easy to determine how closely related two viruses are. The only reason I posted the article - and you obviously missed that point, is to list a proposal of which groups of viruses are sufficiently distinct to be considered a single family. > of 270 taxa! :-(( Well, you may not like that fact, but that's just the way it is. We have nearly 300 independent groups of viruses, with 1000+ variants. Just classifying them into 270 (actually more like 290) families is a necessary first step. If you have any ideas on how to create fewer familes then please publish them. If not, please don't waste my time - I'm trying to get some useful work done in classifying viruses. - -frisk ------------------------------ Date: Sat, 09 Nov 91 14:39:35 +0000 >From: Fridrik Skulason Subject: Re: Virus removals vs. Virus classification In Message 5 Nov 91 04:22:03 GMT, turtle@darkside.com (Fred Waller) writes: > program managed to remove a certain virus from an infected file, > then that virus must belong to the family of viruses for which the > removal program was designed. First, the inference is not strict. I have a similar program, and from Vesselin's description it sounds as they work in a very similar way. It is able to remove almost all Jerusalem variants from .EXE files, and is equally good at handling "new" variants. What my program does is simple: It first determines that the "victim" is really infected with a Jerusalem-related virus. This step is so obviously necessary that it does not make sense to proceed if it fails. However, this classification is partially performed by the program looking for a specific section of code, which contains information on the length of the virus, and the location of the information which was extracted from the header of the original program - initial CS:PC and SS:SP This information is read, written back to the beginning and the file is shortened - cutting the virus off the end. I have not distributed this program - simply because I feel it is a matter of principle that a program should not attempt to disinfect "unknown" viruses. > Second, the "family" he was talking about remains un undefined > entity. Not undefined, just a bit fuzzy. The questions that have not been answered, regarding the Jerusalem family are: 1) Should Suriv-1 and Suriv-2 be considered to members of an "Israeli"-family, that also includes the Jerusalem viruses ? 2) Should the two encrypted variants (Slow and Scott's Valley) be considered a separate family ? 3) Should the Plastique/AntiCAD viruses be considered to belong to a separate family ? My opinion is: 1) Maybe 2) No 3) No, but of course I don't have the final say in this matter. > Third, from a technical standpoint, the use of a curing > program to make a taxonomical classification is abominable. If the program is not able to disinfect a virus it is somehow different from other Jerusalem-related viruses - it may be a heavily modified Jerusalem variant, or a totally new virus - something which can only been determined by careful analysis, but at the very least this method would produce some useful information. Nobody has said that all virus-classification should be done on the basis of the abilities of one disinfection tool, but a generic family-specific disinfection program, such as this one can provide information on whether a virus is a more-or-less ordinary member of a particular family or not. My program, and I presume alse othe one Vesselin described, will for example not disinfect Slow-infected programs, because of the extra encryption code added - but I don't hesitate to classify them as Jerusalem-variants nevertheless. > Note that I'm NOT SAYING that the Fu Manchu virus DOESN'T belong to > the Jerusalem family - it may or it may not. There is absolutely no disagreement among virus researchers that it does. Don't confuse the issue. - -frisk ------------------------------ Date: Sat, 09 Nov 91 15:05:30 +0000 >From: Fridrik Skulason Subject: Re: Hardware... [Ed. To the people participating in this discussion on hardware vs. software, I'd like to remind you all that, "Contributions should be relevant, concise, _POLITE_, etc.". (Emphasis added - with reason.)] In Message 5 Nov 91 04:20:28 GMT, turtle@darkside.com (Fred Waller) writes: Not surprisingly, I happen to disagree with almost all he writes.... :-) > False. Hardware offers inherent protection which is totally > undefeatable by software in the realm where applied. You keep making this unsubstantiated claim. I have a software solution. It works. Hardware is theoretically better against new viruses, as software can only be guaranteed to be 100% effective against known viruses, but I have not yet seen you prove that hardware can be 100% effective against all viruses, while at the same time allowing normal operation. I wrote: > If the computer is not an embedded system, > if it ever runs programs "from the outside" > and is designed to allow "useful stuff", like program > development, Fred Waller wrote: > That's one "if"... > ...and that's another "if"... > ...and a third "if". > Fortunately, most computers in the world are not used for writing > programs, and some restriction of the other parameters is readily > allowable. Well, of course I expected to say that - otherwise nobody would even consider your hardware "solutions". However - I have said it before, and I will say it again, if necessary: You can protect computers from viruses if you do something like the following: ... Carefully analyse all new programs brought in, to be sure nothing infected gets installed to begin with. ... Put all executable programs in ROM, or on a write-disbled hard disk (of course you have to be sure no virus is active when you temporarily write-enable the disk). ... Prevent the users from ever copying or compiling a program. The problem is just that "solutions" of this type are not acceptable to most users. As soon as you allow people to compile a program or to run something "from the outside", you open up a loophole, regardless of any anti-virus hardware installed. I am not saying all hardware is useless - Dr. Alan Solomon has one nice little patent, - on a hardware modification that will prevent any writes to track 0, head 0, sector 1 of a hard disk - totally protecting your hard disk from any partition boot sector viruses. (of course this will not protect your floppies, or protect you from DOS boot sector viruses, or protect you from file viruses.....etc, but it is a hardware solution which has only a limited effect on normal operations, and it does its job). I'm not totally anti-hardware, as you seem to think - I just want to make the claim that if hardware is to give 100% virus protection it will restrict normal operations so much that it will never be adopted by the majority of users. > A virus can be _written_, of course (anything can be written), > but it cannot defeat sensible but simple hardware protection. > Ever. Describe "sensible but simple hardware protection" that works and is practical. Or maybe better still - just produce it, get rich, and drive me and the other companies that offer a software solution today out of business. Then I'll admit that you were right.... - -frisk ------------------------------ Date: Sat, 09 Nov 91 15:24:00 +0000 >From: Fridrik Skulason Subject: Re: Disk Compression (PC) >I've saved the cost of the software simply by disk savings. Also, it >makes scanning for conventional viruses easier since the disks look >normal (certainly under SuperStore). Well, it depends. It is possible that a virus scanner might be written to bypass the file system entirely when searching for viruses. It would interpret the FAT directly, and access the disk, preferably by INT 13H calls to the ROM. This would not work for network drives, disks installed with a device drivers...etc, but in the cases where it works it provides one benefit - immunity to "stealth" viruses - at least the current generation. Acessing the disk on this level does not work with compressors of this type...... - -frisk ------------------------------ Date: Fri, 08 Nov 91 21:58:34 -0800 >From: turtle@darkside.com (Fred Waller) Subject: Subjects Complains Dr. Chess: > I notice you always seem to change the Subject: line > when replying to a posting. Is that intentional? Mostly, yes - but not ill-intentioned. By the time I start composing a reply, some part of its theme is already clear in my mind, and I tend to use that as the subject. > The tradition is to leave the Subject: line alone, > just sticking a "re:" at the front if there isn't one. > This would make it easier for folks to follow (or > avoid) specific threads in the conversation... I confess guilt here. One reason is that I don't use an automated mail reader/editor, which tends to keep "Subject:" lines intact. Another is that I may sometimes prefer a different heading for the thread. Another is that sometimes I start a new thread, or change the emphasis of the old one. The suggestion is good, but I have also seen where this habit is abused: the thread drifts to other subjects, but the original "Subject:" line is kept forever, well past its applicability. I mostly don't like that. I'll try to do better, though. :-) Fred (W.) ------------------------------ End of VIRUS-L Digest [Volume 4 Issue 215] ****************************************** Downloaded From P-80 International Information Systems 304-744-2253