From CUNYVM.CUNY.EDU!lehigh.edu!virus-l Thu Feb 11 05:22:53 1993 Date: Tue, 9 Feb 1993 09:44:08 -0500 Message-Id: <9302091224.AA04058@barnabas.cert.org> Comment: Virus Discussion List Originator: virus-l@lehigh.edu Errors-To: krvw@cert.org Reply-To: Sender: virus-l@lehigh.edu Version: 5.5 -- Copyright (c) 1991/92, Anastasios Kotsikonas From: "Kenneth R. van Wyk" To: Multiple recipients of list Subject: VIRUS-L Digest V6 #22 Status: R VIRUS-L Digest Tuesday, 9 Feb 1993 Volume 6 : Issue 22 Today's Topics: Re: Mainframe viruses? [Sam Wilson:06/13] Re: Infection question Re: Patriotic Virus Writers? Re: scanners. re: new NIST Pub (CORRECTION) Undecidability (was: On the definition of viruses) Re: How to measure polymorphism Re: os2-stuff (OS/2) Re: Vshield vs Virstop (PC) Norton buggy??? (or I have a PROBLEM!) (PC) Re: PKZIP 2'S AV is cracked (PC) Re: can anybody help my little lost computer? (PC) New Virus (PC) Mr. BIOS (PC) ANSI Bombs (PC) 696 Virus? (PC) New virus in Germany :-( (PC) DAME/MtE (PC) re: Virus scan on a compressed drive (PC) dame virus (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. (The complete set of posting guidelines is available by FTP on cert.sei.cmu.edu or upon request.) Please sign submissions with your real name. Send contributions to VIRUS-L@LEHIGH.EDU. Information on accessing anti-virus, documentation, and back-issue archives is distributed periodically on the list. A FAQ (Frequently Asked Questions) document and all of the back-issues are available by anonymous FTP on cert.org (192.88.209.5). Administrative mail (comments, suggestions, and so forth) should be sent to me at: . Ken van Wyk ---------------------------------------------------------------------- Date: Fri, 05 Feb 93 19:48:32 -0500 From: Anthony Naggs Subject: Re: Mainframe viruses? [Sam Wilson:06/13] Sam Wilson, , recently posted a copy of an article from the UK trade paper "Computing", entitled: > Mainframes hit by epidemic of viruses > ===================================== As Klaus Brunnstein, , noted: > Sam Wilson mentioned a "survey of 816 European and North America mainframe > sites (with) ...35.5% .. disasters .. 60% of which had been due to viruses". It seems that a journalist misunderstood the survey results, or at least misrepresented them. The following letter appeared in this week's edition of Computing, and seems to make more sense: [reproduced in full, but without permission] - - - - - Mainframes are in good health ============================= I read with sheer horror your article 'Mainframes hit by epidemic of viruses' (Computing, 21 January). Those who do not know better may reasonably infer that the numbers reported refer to occurrences of viruses on actual mainframes, but, although the survey in question is sent to sites with mainframes, the question asked if the installation [site] had suffered viruses. It is therefore invalid to conclude that the viruses actually occurred on the mainframe. Furthermore, the bar chart you showed in the article seems to show a rise in viruses from 1991 to 1992, but investigation into the Ibex results shows that this chart actually shows the five year totals, so the 1992 five year total includes the 1991 total. The annual increment was actually less than half of the increase in five year totals. Last year, in one part of Africa, the stork population decreased sharply. Also in the same area the human birthrate happened to fall. What would your reporter have concluded from this? Richard Phillips, Reed Travel Group, Dunstable, Bedfordshire - - - - - Hope this helps, Anthony Naggs Software/Electronics Engineer P O Box 1080, Peacehaven (and virus researcher) East Sussex BN10 8PZ Phone: +44 273 589701 Great Britain Email: (c/o Univ of Brighton) amn@vms.brighton.ac.uk or xa329@city.ac.uk ------------------------------ Date: 07 Feb 93 19:56:24 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Infection question David_Conrad@MTS.cc.Wayne.edu writes: > But in my (humble?) opinion, a boot sector infector does attach itself to > a program, i.e. the bootstrap loader. This program just doesn't happen to > be contained in a file. It depends on how do you define "attach". A boot sector infector does not modify or attach itself to a bootstrap loader - it just moves this loader to a different place and puts its own body at the original place. Furthermore, viruses like Stoned will infect and spread even if the bootstrap loader is absent - e.g. a diskette with a zeroed out boot sector is both infectable and infective after infection. So, you'll have to define "attach" in such a way that defines "attaching to the execution process of a program" or something like that. > I'm not quite as certain what to say about companion viruses. I don't They are not the only problem. The Dir_II virus modifies the directory entries - not the files themselves. The StarShip virus infects the MBR by modifying only three bytes of the partition table -data-... And so on... > Still, without the "host" program the companion virus would never be > executed by the user, would it? It depends. Consider an EXE file, "infected" by a companion virus. If you delete the host (i.e. the EXE file), the virus will still be able to spread, in most cases. Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN < PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C e-mail: bontchev@fbihh.informatik.uni-hamburg.de D-2000 Hamburg 54, Germany ------------------------------ Date: 07 Feb 93 20:29:44 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Patriotic Virus Writers? ercm20@festival.edinburgh.ac.uk (Sam Wilson) writes: > The following letter and editorial response appears in the February > 1993 issue of the UK magazine 'Personal Computer World' under the > heading "Spreading viruses": [ARCV's silly letter deleted to save the net.bandwidth.] > ARCV > (Association of Really Cruel Viruses) > [And the editor replies:] > You say you're not depraved people? Perhaps you weren't beaten as > children, but as far as we're concerned you should be beaten as > adults. According to the latest information, six members of the ARCV group have been arrested. Perhaps this will stop them from writing viruses any more... Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN < PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C e-mail: bontchev@fbihh.informatik.uni-hamburg.de D-2000 Hamburg 54, Germany ------------------------------ Date: 07 Feb 93 20:33:31 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: scanners. TAWED@etsu.bitnet (Ed Street) writes: > I know this is probably a dumn question but I was wondering about the > realistic aspects of scanners like do they really protect as much as > some of the people that I have talked to seem to think? In my opinion > they are just merely an aid to problem solving and should not be used > as a general "cure-all" All a scanner can do is to detect known viruses. Nothing more. Good scanners detect most known viruses, worse scanners detect fewer of them. No scanner detects -all- known viruses, because new viruses are created literally every day. A scanner is useful for: 1) Checking that a system is virus-free before installing some more sound virus defense, like an integrity checker. 2) Checking new software before you execute it or install it on your system. This way you can detect a virus before it gets the chance to execute. 3) Trying to figure out what has happened when your more serious defense (the integrity checker) has raised an alert and you are wondering whether it is a known virus. Because of the above, scanners are -useful- and should be used as a first line of defense. (Up-to-date scanners, of course; an old scanner is worse than no scanner at all, because it gives you a false sense of security...) However, no defense should rely on scanners -alone-, because they are a -weak- defense. You must use a layered approach, with several protection levels, like integrity checking software, some kind of access control, and, of course, backup. Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN < PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C e-mail: bontchev@fbihh.informatik.uni-hamburg.de D-2000 Hamburg 54, Germany ------------------------------ Date: Mon, 08 Feb 93 11:26:24 -0500 From: Tim Polk Subject: re: new NIST Pub (CORRECTION) Ouch! I *swear* I proofed that message, but I switched the second and third parts of the address of the ftp server. The correct name is: csrc.ncsl.nist.gov I have successfully printed this PostScript file on several different printers. However, I have been notified that this file will not print on some Adobe-licensed printers. If it fails on your printer, please let me know. I will be happy to send a hardcopy. Sorry for any difficulty, and thanks to those who sent me notice of the switch. Tim Polk polk@csmes.ncsl.nist.gov ------------------------------ Date: Mon, 08 Feb 93 11:27:26 -0500 From: Y. Radai Subject: Undecidability (was: On the definition of viruses) (First, note that I've changed the Subject line. I didn't notice how inappropriate it was until someone wrote me on the basis of my postings that I seem to have an interest in defining virus items. Secondly, although I address this reply to Fred Cohen, I think it will also serve as a reply to most of the comments on this subject made by Vesselin, Padgett and others.) In reply to my statement: >> Suppose a program contains code for replication, but only within a >> statement of the form "If then ", where >> is something which depends on the run-time environment, >> e.g. on the input which a user supplies. Can a detection program >> discover whether the program actually does replicate? Fred Cohen replies: > Only at runtime! True, provided the question is interpreted as asking whether it replicates on a *particular* execution. (As my later discussion indicates, I was also interested in determining whether the program replicates on *every* execution, or on *at least one* execution.) > Also, instructions > is a relative term. I prefer to discuss sequences of symbols. These > symbols can be interpreted by any number of mechanisms. Agreed, but since that wasn't subject to controversy, I simplified the wording by speaking of "instructions". >> (b) a virus is a sequence of instructions which replicates on *at >> least one* execution; > > Same as above, but add - if *at least once* does it mean that if a copy > program copied it, it would be a virus? Example: run your program which > halts, then later, someone copies it once, and bingo, it's a virus. The > reason for *every* is that we can associate the replication property > with the virus and not the rest of the machine. I suspect that we are using the phrase "at least once" in two differ- ent senses. To clarify this, let's talk about "generations" of a virus: the virus in the original infected program is of generation 0, and whenever a virus of generation n infects, it creates a virus of generation n+1. Now if I understand you correctly, you mean that in order for something to be a virus, *the number of generations must be (potentially) infinite*. Otoh, when I used the phrase "at least once" in definition (b), I was referring to a *conditionally infecting* virus (which I think is what you call a "partial" virus). I.e., an infected program (of any given generation n) can be a virus according to definition (b) even if it infects on only a single execution (thereby creating a single virus of generation n+1). But I did not intend to imply that such a virus would also be limited in the number of generations. >> If the decision is to be made by appearance of the program alone, >> then the simplest case is (c), for suppose that the program asks the >> user to supply two numbers, x and y, and is "x < y". Then >> it is completely obvious that fulfillment of this condition cannot be >> determined without actually running the program, hence whether the >> program is a virus is undecidable by appearance of the program alone. > > The problem is that in the Turing Machine model, there is no `input'! > All the information needed for the computation is on the tape and in the > FSM, and is thus provided a-priori. Input is modeled as a preexisting > tape state. The undecidability proofs I generated relate to ANY inputs > (i.e. any tape state can exist outside the virus). They are thus `input' > independent. This seems to me irrelevant, since I was not using the Turing Machine model! When I spoke of user input, I was merely trying to give a *convenient example* of a run-time environment on a computer. (Actually, I'm not sure we're using "environment" in the same sense.) >> Note that this argument does not require the assumption that the >> computer has an infinite amount of storage, as Fred's proof does. > > Sure it does - we can identify that under one set of inputs it's a > virus, and under the other it is not. As we watch the inputs, there > comes a point in time when we say `VIRUS!!!'. At the point I made this statement, I was referring to definition (c), where we're asking whether the given condition ("x < y" in my example) is satisfied on a *given* input (x,y). Also, I was talking of having to determine whether the condition is satisfied *merely by appearance of the program* (as opposed to using its runtime behavior). Therefore, we cannot "watch the inputs", and I fail to see anything in your reply which shows the need for an unbounded amount of storage in order to prove undecidability by appearance alone. >> Not only can we not decide this >> by appearance of the program, but even if we run this program a zil- >> lion times and the program doesn't replicate, that doesn't prove that >> it can *never* replicate; all one can say is that the program hasn't >> replicated *so far*. > > Not right. For finite sized systems, these problems are not unsolvable. > They merely take a lot of time to solve. We could literally try all > possible integers that could fit in the finite sized computer. It seems that many readers, perhaps including you, are confusing the two parts of my argument, so let me make this clear. Part 1 assumed that Definition (c) was chosen, and concerned detection by *appearance alone*. It had nothing to do with unsolved problems, and it was valid even when the amount of storage was finite. Part 2 assumed that Definition (a) or (b) was selected, and concerned detection by *run-time behavior*. It spoke of unsolved problems, did not claim to be conclusive, and there was no claim about the amount of storage. The section you are quoting above deals with Part 2, and there I never said that the problems are unsolvable on a finite computer. > All unsolvable problems of this sort depend on the size of the integers > being infinite. - As above. There is no undecidability for finite sized > computers, and there can never be. Perhaps we mean different things by "undecidable". Maybe you mean undecidable by *any* means, appearance *or* behavior. I claim that if one chooses definition (c), and if is something which is sometimes satisfied and sometimes not (e.g., if it is "x < y" where x and y are numbers supplied at runtime by the user), then the question whether the program is a virus is obviously undecidable *BY APPEARANCE ALONE*, even on a *finite* machine. > Also, solving Fermat's last Theorum will neither make you > famous, nor solve all of the world's unsolved problems. They used to > say the same thing about the 4-color graph problem, but some people > proved it with a computer theorum prover. What was their name? I never said that solving Fermat's Last Theorem *alone* would solve *all* the world's unsolved problems! My hypothesis for that conclu- sion was being able to "write a program which could decide whether the resulting programs [after substitution of *all* the other unsolved problems as the ] are viruses". As for making one famous, I'm sure the solvers of the 4-color problem are reasonably famous among most of the people who are interested in that problem, even if *we* don't remember their names. > As I mentioned above, there is no problem that can *NEVER* be solved for > a finite machine. Unsolvable problems only occur in infinite state > machines. As I mentioned above, the "x < y" case with definition (c) is undecid- able by *appearance alone*, even on a finite machine. > The reason undecidable problems are undecidable is that they CAN > NEVER be solved by ANY Turing Machine. It does not depend on the state > of mathematics of the day or a proof not yet found or the number of > computations we can perform per unit time. In that sense, it is an > absolute limit of the nature of the machine. All of the realized > digital computers to date and all of the theorized finite discrete > valued computers fall into a subset of Turing Machines, and thus no > undecidable problem can be solved by any of them either. That's why > the concept is so powerful. > Instead of running to `unsolved' problems, it seems a much better > choice to run to `unsolvable' problems in your proofs. That's why I > used the halting problem to show that virus detection is undecidable > rather than Fermat's last theorum. I didn't want to show computational > complexity, but unsolvability. .... I agree with this, but perhaps you don't understand my motivation (and the same goes for many others who commented on my posting). In Part 2, I was not attempting to give a rigorous proof! (As I wrote, I was presenting a non-conclusive argument, and I twice used the phrase "for all practical purposes".) My purpose in presenting the argument was to explain the situation to someone who does not have the necessary background, in as *intuitive* a manner as possible. Now from a logi- cal point of view, proofs such as yours are perfectly valid. More- over, my idea of "intuitive" may be quite different from yours. How- ever, my experience shows that there is something about proofs like yours which many (even intelligent) people find *unconvincing* from a *psychological* point of view. I have had much better success if I use my non-rigorous argument rather than your rigorous proof. So please try to take into account my purposes, which are very different from yours. Y. Radai Hebrew Univ. of Jerusalem, Israel RADAI@HUJIVMS.BITNET RADAI@VMS.HUJI.AC.IL ------------------------------ Date: Mon, 08 Feb 93 18:48:44 -0500 From: "David M. Chess" Subject: Re: How to measure polymorphism >From: favor@ecst.csuchico.edu (Michael Favor) >In his paper, did ... Chaitin explain how to 'find' the 'smallest' >program in an objective way? It seems easy enough to measure two >programs and decide which one is smaller or simpler, but how can one >generate these programs in the first place without using all of the >subjective intuition of the programmer? No, and in fact another interesting result he has is that it's in some sense hard to prove that a particular string is random (if I remember it right with this cold, a system that has order-n bits can't prove that a string is more than order-n-bits random; that's very rough). One reaction to this would be "so much the worse for this notion of randomness; I'll find one in which you *can* feasibly prove that things are random". But I think this notion of randomness has lots of nice properties, including intuitiveness (after all, if it's easy to write a short program that produces the string, it's clearly not very random on an intuitive definition, since you can describe the string by outlining the algorithm of the program, and an easy-to- describe string isn't very random). I think it may be just a fact about what we mean by "random" that (while it can be defined quite objectively), it's hard to prove that a thing is random. I was going to put in a long tangent here, but it's not really at home on VIRUS-L. For some mental fun, though, think about what happens if you have a simple test for randomness, and then you use it to produce descriptions like "the smallest random number greater than 10-to-the-100th". Is that number really random? Really? *8) Anyway, to get back to polymorphism briefly, I think that "how long is the shortest known algorithm that reliably recognizes these things?" is a good rough measure of degree of polymorphia (hehe), even though "how long is the shortest *possible* algorithm that..." is a very hard question. - - -- - / We have a little garden, David M. Chess / A garden of our own, High Integrity Computing Lab / And every day we water there IBM Watson Research / The seeds that we have sown. ------------------------------ Date: 07 Feb 93 20:22:41 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: os2-stuff (OS/2) AMN@vms.brighton.ac.uk (Anthony Naggs) writes: > I don't think so, but OS/2 (2.x) DLLs run in the CPU's 'Protected Mode' > and so will not be visible to the DOS box. If the virus is OS/2 aware > then it can interact with OS/2 form the DOS box, but I don't know what > the scope of that is. Yeah, but we were talking about scanners and scanners can detect only known viruses. Since no known virus does what you describe above, this means that we don't need to scan the DLL files - unless they can become infected by mistake. So the point of my question was - can they become infected by mistake by any of the known viruses? > There are three big reasons not to worry at the moment: > 1 OS/2 DLL files have a different internal layout from DOS programs, > preventing DOS viruses from successfully infecting them. > 2 OS/2 (2.x) programs (including DLLs) run in "Protected Mode" which > means that code for the "Real" or "Virtual" modes used by DOS is > unlikely to work. > 3 Even if these could be overcome a DOS virus would fail as soon as it > tried an Int 21h call. None of those reasons would be valid, if any of the known viruses could infect DLL files BY MISTAKE. OK, they will crash, OK, the virus won't run, etc., but if they can become infected, you still must scan them - at least to determine which of them are damaged by the virus. So, I am asking again - can some of the known viruses infect a DLL file (even by mistake, even incorrectly)? I think that none of them will do that, but maybe I am wrong... Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN < PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C e-mail: bontchev@fbihh.informatik.uni-hamburg.de D-2000 Hamburg 54, Germany ------------------------------ Date: Fri, 05 Feb 93 18:59:17 -0600 From: ST29701@vm.cc.latech.edu Subject: Re: Vshield vs Virstop (PC) bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) writes: >bill.lambdin%acc1bbs@ssr.com (Bill Lambdin) writes: > >> Vshield can detect new and unknown viruses except for two types. >>> >> 1. Stealth >> 2. Companion infectors. > > 3. Unknown viruses that patch VShield in memory to deactivate it. > 4. Unknown viruses that patch VShield on the disk to deactivate it. > 5. Unknown viruses that intercept the alert message VShield tries to >output and prevent its output. > 6. Unknown viruses that remove the checksums created by SCAN. > 7. Unknown viruses that patch the database of checksums after they >infect the file, so that the new checksum entry corresponds to the >already infected file. > 8. Unknown viruses that forge the checksum algorithm used by SCAN >and infect the files without changing their size/time/checksum >computed with this algorithm. > 9. Unknown viruses that modify the CONFIG.SYS/AUTOEXEC.BAT files to >prevent VShield from being run (and that optionally put a call to a >fake program that generates a fake message that VShield is loaded and >running). > 10. Unknown viruses which infect only floppies. > 11. Unknown viruses which infect only objects known to be modifiable. > 12. Unknown slow viruses. > >Makes quite a long list of exceptions for a claim "can detect new and >unknown viruses", doesn't it?... Never underestimate what an unknown >virus could do... Isn't this also true for VIRSTOP?????????????????? ------------------------------ Date: Sat, 06 Feb 93 02:08:34 +0000 From: amead@s.psych.uiuc.edu (Alan Mead) Subject: Norton buggy??? (or I have a PROBLEM!) (PC) I think I found a bug in the Norton virus scaner NAV.EXE (dated 5-28-92). I don't know what version or anything. Here's what happened: I wrote a program for my wife's employers. I copied it onto her PC at work about a month ago. Today, I get home and my wife has left this message on our machine about "don't boot my computer" because "we have a virus" and everyone at her work hates her and the Data Processing people are running around muttering stuff like "Now I'm going to have to check every computer in accounting" etc. Mortified, I download the very latest McAuffe scan (1-21-93) and I scan my every file on my only drive, C: (SCAN C: /A /SUB). I get nothing. Susan gets home with the Norton disk. We use the Norton scanner (NAV.EXE) on my C: and it fails to find anything. BUT, it turns out I deleted the file that allegedly carries the virus ("a strain of CVIR"). So I Norton the backup disk and, sure enough, it flags an executable of a Turbo Pascal program of mine. THEN I McAuffe it and I get NOTHING. So already I'm suspicious because how can my whole fucking C: be cool [by BOTH programs] but that one file (that I created) be sick. So I copy the source onto C: and recompile. The byte length of the fresh copy and the old, allegedly infected, copy is exactly the same. And, get this, fucking Norton flags my new, freshly compiled executable again. What do you think? I find it unlikely that I have a virus and (snicker, snicker) I LOVE the fact that these morons are spending their Friday night disinfecting clean machines. Also, I should think Norton would want to know about this. - -alan d mead ------------------------------ Date: Fri, 05 Feb 93 01:10:45 +0000 From: mcafee@netcom.com (McAfee Associates) Subject: Re: PKZIP 2'S AV is cracked (PC) Hello Mikko Hypponen, You write: >The following is ment to inform the participants of this newsgroup. I >am not bashing PKWare nor any other company or individual. > >The "Authentic files Verified" feature of PKZIP 2 has been compromised >and cannot be trusted. [...description of PKWare's Authenticity Verification feature and its uses deleted for brevity...] >The computer undergound has been busy trying to crack the new >AV-scheme. Now it has obviously been done. A file called >MAKAV204.ZIP is circulating around the underground BBS's and with >it anybody can secure an PKZIP 2 archive to any name. > >To demonstrate this, I'm enclosing an UUencoded zip-file, >which will show an AV to "Zip Source: McAFEE ASSOCIATES" when >unpacked with PKUNZIP 2.04c. [...I have deleted the UUENCODE'd file...] >It remains to be seen whether McAfee Assiciotes begins to ship their >products archived (and secured) by PKZIP 2.04c or not. Their latest >release, 9.2V100 was archived with PKZIP 1.1. We will continue to use PKZIP Version 1.10 to compress our files for the forseeable future because 1.10 is still used more frequently then 2.04C, there is no "exportable" version of PKUNZIP V2.04C available from PKWare (yet), and lastly, PKZIP Version 2.04C has several bugs in it that make it undesirable for use in distributing software (PKWare has released a newer version, 2.04E, but we will wait to see how stable that is before we consider using it.). > >It should also be noted that the AV in above zipfile does not match ^^ I am going to guess that you meant serial number here, not the "-AV" which appears after each file is unzipped. >the number shown before the authors name. McAfee's number should be # >NWN405 (at least that was with pkzip 1.1). In fact this faked zip >displays the number "# PKW655" which is the AV-number for PKWare >itself. The cracker probably found a short-cut way by just changing >the name and not the number. > >Please note that the similar "Security Envelope" feature of ARJ 2.30 >has also been broken. The author of ARJ, Robert K. Jung, is currently >working on a new method the secure the ARJ archives. Like many other readers of the comp.virus newsgroup (and its digest counterpart, VIRUS-L), I appreciate it when computer security and integrity are discussed, especially when they relate to our (McAfee Associates, that is) programs. However, I certainly feel that any discussion of such issues much be discussed in a tactful manner--and a competitor pointing out an example of a security risk, complete with actual working example, in another company's product is not necessarily the best way to do this: You need not present the Internet with a forged .ZIP file merely to prove that PKWare's Authenticity Verification for Version 2.04C of their program has been cracked. Reporting that such a risk exists is adequate for the purposes of this newsgroup; one does not include a copy of a new virus or post the source code for a new method of infection to show that it exists. The Authenticity Verification and accompanying serial number generated by the PKZIP program are used by us for providing our users with a degree of security, they are by no means final or absolute. However, it is very unlikely that both the -AV and serial number will match up in a cracked version of PKZIP. I believe that it is far better that some means of protection be provided then none at all. Our programs are directly available from us via our BBS, forum on CompuServe, and mcafee.com ftp site on the Internet, in addition to sites such as the SIMTEL20 archives and garbo.uwasa.fi which I directly send the programs to. If any one ever has a question about the integrity of a .ZIP file they've received, then they should delete it and download it from one of these avenues instead. Regards, Aryeh Goretsky McAfee Associates Technical Support PS: Please (!) direct any follow-up comments to me via e-mail, I have no desire for this newsgroup to become a battleground. :-) - -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - McAfee Associates, Inc. | Voice (408) 988-3832 | INTERNET: 3350 Scott Blvd, Bldg 14 | FAX (408) 970-9727 | mcafee@netcom.COM Santa Clara, California | BBS (408) 988-4004 | CompuServe ID: 76702,1714 95054-3107 USA | USR HST Courier DS | or GO MCAFEE Support for SENTRY/SCAN/NETSCAN/VSHIELD/CLEAN/WSCAN/NETSHIELD/TARGET/CONFIG MGR ------------------------------ Date: Fri, 05 Feb 93 18:26:04 +0000 From: mcafee@netcom.com (McAfee Associates) Subject: Re: can anybody help my little lost computer? (PC) Hello Dan Greenspan, You write: > I run an ibm type machine. Lately my machine began acting up >and now I have three invisible files in my hard drive instead of two. [...deleted...] If you have labeled your hard disk drive with the DOS LABEL command, the label itself will sometimes be reported as a hidden file, depending upon which program you use to look for hidden files. If you are running MS-DOS 5.0, you can get a complete listing of hidden files by typing "DIR /AH /S" from the root directory of your drive. This tells the DIR command to search all subdirectories for files with the hidden attribute. Regards, Aryeh Goretsky - -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - McAfee Associates, Inc. | Voice (408) 988-3832 | INTERNET: 3350 Scott Blvd, Bldg 14 | FAX (408) 970-9727 | mcafee@netcom.COM Santa Clara, California | BBS (408) 988-4004 | CompuServe ID: 76702,1714 95054-3107 USA | USR HST Courier DS | or GO MCAFEE Support for SENTRY/SCAN/NETSCAN/VSHIELD/CLEAN/WSCAN/NETSHIELD/TARGET/CONFIG MGR ------------------------------ Date: Sun, 31 Jan 93 20:57:00 +0100 From: Inbar_Raz@f210.n9721.z9.virnet.bad.se (Inbar Raz) Subject: New Virus (PC) Amir_Netiv@f120.n9721.z9.virnet.bad.se (Amir Netiv) writes: >> It looks like a variant of te WHALE, but larger, and >> harder to remove > Whell, it could be as you say (a variant of the WHALE), but it would > be rather surprising, since the Whale is an old one and from a viral > point of view... an unsuccessful one. Don't be so sure. A lot of 'virus writer wannabe's simply attain virus sources, make some modifications to them (either to avoid detection, to try new techniques or just to save the skeleton writing) and compile them. For someone who's not very smart, the Whale virus would sound like a good work- grounds, because it is fairly known that most of the virus code is dedicated to anti-debugging (which consequently made it very slowing), and that would aledgedly make it harded to detect. Inbar Raz - - -- Inbar Raz 5 Henegev, Yavne 70600 ISRAEL. Phone: +972-8-438660 Netmail: 2:401/100.1, 2:403/100.42, 9:9721/210 nyvirus@weizmann.weizmann.ac.il - --- * Origin: MadMax BBS - Co-SysOp's Point. (9:9721/210) ------------------------------ Date: Tue, 26 Jan 93 13:56:00 +0100 From: Chris_Franzen@f3060.n492.z9.virnet.bad.se (Chris Franzen) Subject: Mr. BIOS (PC) > From: FRAHM@UCSU.COLORADO.EDU (Joel A. Frahm) > I was recently called in to work on a new PC clone, and it had BIOS > from the Mr. BIOS corporation. And if that wasn't weird enough, this > BIOS Hey, MR BIOS (MR is "Microid") is not that weird. It used to spread in new PC boards in Germany (from Taiwan), until everyone returned back to AMI. MR BIOS has a superb setup program, and is very well adaptable to make use of chipset features. The PC integrator I work for (3000 PCs a year) attempted to establish Microid BIOS for all 386- and 486-based boards in the PC line. No success. There were some problems with exotic OSs like Prologue and UNIX, and there were a lot of problems with LCD display cards (for portables). So we dropped it and returned to AMI. > contains some type of antivirus code, perhaps an MBR protector or > something. > Does anyone out there in the real world know anything more about this > BIOS > and the ramifications of BIOS based AV software? The technical dox of the MR BIOS we distributed does not talk about AV code in the BIOS. I do know the current AMI BIOS indeed includes MBR protection. They seem to check if the floppy disk boot sector is being written at boot-up. (This does not make any sense to me, though.) I believe AV should not be built into the BIOS ROM since that just animates virus authors to demonstrate how they can break it. Chris, The Blast I - --- GEcho 1.00 * Origin: COMDATA Box, D-2942 Jever, ++49-4461-757442 (9:492/3060@VirNet) ------------------------------ Date: Sun, 31 Jan 93 20:59:00 +0100 From: Inbar_Raz@f210.n9721.z9.virnet.bad.se (Inbar Raz) Subject: ANSI Bombs (PC) To all of you who are afraid of ANSI bombs, two ways of avoiding them: 1. Replace your ANSI driver. Use something like NANSI, that has a /S command line switch to DISABLE the keyboard redefinition. 2. If you are a BBS, and using the MTS package, people can infect you by simply inserting an ANSI bomb to an ARJ COMMENT, and when the MTS opens the ARJ to its temp dir, the bomb will active. If you are using ARJ, do this: SET ARJ_SW=-JA- If you already have an ARJ_SW, add -JA- to it. Inbar Raz - - -- Inbar Raz 5 Henegev, Yavne 70600 ISRAEL. Phone: +972-8-438660 Netmail: 2:401/100.1, 2:403/100.42, 9:9721/210 nyvirus@weizmann.weizmann.ac.il - --- * Origin: MadMax BBS - Co-SysOp's Point. (9:9721/210) ------------------------------ Date: Sun, 31 Jan 93 21:03:00 +0100 From: Inbar_Raz@f210.n9721.z9.virnet.bad.se (Inbar Raz) Subject: 696 Virus? (PC) mark@walt.CS.MsState.Edu (Mark Rauschkolb) writes: > A co-worker just told me that his home machine is heavily infected byy > the 696 virus (according to McAfee SCAN). I looked for 696 in the > VSUM "program" but could not find it. Did you try locating it through size cross-reference? It's worked a lot of times for me, especially to identify viruses that SCAN didn't find. Inbar Raz - - -- Inbar Raz 5 Henegev, Yavne 70600 ISRAEL. Phone: +972-8-438660 Netmail: 2:401/100.1, 2:403/100.42, 9:9721/210 nyvirus@weizmann.weizmann.ac.il - --- * Origin: MadMax BBS - Co-SysOp's Point. (9:9721/210) ------------------------------ Date: Fri, 05 Feb 93 02:59:04 +0100 From: Malte_Eppert@f6050.n491.z9.virnet.bad.se (Malte Eppert) Subject: New virus in Germany :-( (PC) Hi ALL! There's a new virus around in Northern Germany which was isolated on the Fachhochschule Braunschweig/Wolfenbuettel on Feb. 4, 1993. It was analyzed by Robert Hoerner and has the following characteristics: - - infects COM and EXE - - loves infecting COMMAND.COM on drive A: - - TSR in UMBs (!), stealth - - uses interrupt trace techniques - - slightly polymorphic, WHALE and FISH-like - - uses seconds-stamp for marking infections - - contains the encrypted text "T.R.E.M.O.R was done by NEUROBASHER / May-June'92, Germany" and "MOMENT OF TERROR IS THE BEGINNING OF LIFE" - - Length: exactly 4000 bytes The virus is provisorically referenced as "UMB-1 (Tremor)", until a name has been officially constituted. Thanks to Robert for his fine work. cu! eppi - --- GEcho 1.00 * Origin: Another Virus Help Node - The EpiCentre! (9:491/6050) ------------------------------ Date: Sun, 07 Feb 93 14:35:48 -0500 From: fergp@sytex.com (Paul Ferguson) Subject: DAME/MtE (PC) (Ching S Siow) wrote - > I would like to find out more about this "DAME Virus". > My network has 3 files infected with this virus and > would appreciate some help in cleaning it out. I have > tried netscan and inoculan, both of which failed to > discover the virus. The "Dark Avenger Mutation Engine" (aka DAME ala McAfee syntax) is more commonly known as the MtE. It is not a virus, but rather an encryption envelope to which the virus can be linked. (For more info, see the FAQ.) If you could be more specific concerning which three files were suspect and what you used to come to the conclusion that are indeed infected by a MtE encrypted virus. I cannot speak for McAfee's NETSCAN (however the latest versions of their ViruScan detects MtE encrypted viruses rather well), but we evaluated Cheyenne's Innoculan NLM withh several MtE encrypted viruses with success. Paul Ferguson | Network Integration Consultant | "All of life's answers are Alexandria, Virginia USA | on TV." fergp@sytex.com (Internet) | -- Homer Simpson sytex!fergp (UUNet) | 1:109/229 (FidoNet) | - --- fergp@sytex.com (Paul Ferguson) Sytex Systems Communications, Arlington VA, 1-703-358-9022 ------------------------------ Date: Mon, 08 Feb 93 15:59:02 -0500 From: "David M. Chess" Subject: re: Virus scan on a compressed drive (PC) >From: wongja@ecf.toronto.edu (WONG JIMMY PAK-YEN) > Presently, when I download some ZIP >files, I SCAN the disk containing the zipfile, unzip the files onto my >hard disk, and scan the unzipped files. Will this still work on a >compressed drive? I can't speak for any particular scanner except IBM's, but in general there should be no problem at all here. As long as the scanner is accessing the files via calls that the drive-compressor software supports, the scanner will not see the drive compression at all, and all will go as it should. In general, any application that uses standard calls to access files will see the filesystem as perfectly normal (albeit larger!), if the drive compressor works right. What might eventually be a problem is that if you do get a virus infection of some kind, and want to boot your machine from a diskette to make sure the virus is not active as you clean up, you'll have to have a special diskette that installs the drive-compression software, in order to see the files on your hard disk. That's not generally too hard to do, but it's probably worth practicing to make sure you know how to do it and that you have a working diskette that does it handy. (If you boot from a diskette that doesn't have the right drivers on it, you'll probably just see your hard disk as one huge and non-useful file, or none at all.) - - -- - David M. Chess | Buy Now High Integrity Computing Lab | Pay Later IBM Watson Research | ------------------------------ Date: Sun, 07 Feb 93 19:00:00 -0500 From: Luis Gamero Subject: dame virus (pc) If it's just 3 files, it's probably a false alarm unless you only have 3 executables on disk..:). - -LG - -- Canada Remote Systems - Toronto, Ontario 416-629-7000/629-7044 ------------------------------ End of VIRUS-L Digest [Volume 6 Issue 22] *****************************************