From lehigh.edu!virus-l Sat Jan 23 07:21:19 1993 Date: Fri, 22 Jan 1993 12:22:11 -0500 Message-Id: <9301221631.AA12947@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 #10 Status: RO VIRUS-L Digest Friday, 22 Jan 1993 Volume 6 : Issue 10 Today's Topics: Re: Sale of Viri Re: Measuring polymorphism Re: How to measure polymorphi Re: Math Models of Polymorphic Viruses Re: Infection question (was: Viral Based Distribution System) Re: How to measure polymorphism Export restrictions on anti-virus software Re: on the definition of virus Virus Calendar Re: A-V virus Re: OS2SCAN99 checked (OS/2) Re: DOS Viruses under HPFS (OS/2) Re: how to get rid of the Naughty Hacker-1? (PC) Re: Monkey [Mon] and Multi-2 [M12] viruses (PC) Re: How do MtE utilizing viruses detect themselves? (PC) CLEAN removing Jerusalem (Was: Re: Jerusalem (Israeli) Virus (PC)) Re: Clash between FDISK/MBR and scanners (PC) Mr. BIOS (PC) Re: Problems with PCs (PC) Re: New way of opeing files??? (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: 14 Jan 93 17:16:05 +0000 From: frisk@complex.is (Fridrik Skulason) Subject: Re: Sale of Viri alby@access.digex.com (Albatross) writes: > Is there any law in the USA the prohibits the Sale of Virus >software to the Public? Or any type of distrubution of such software >with the sole intent to create business revenew? I'm no lawyer...just a techie :-)...but my answer would be "Unfortunately no". In fact, this has been done, well sort-of...just consider the "little black book". Maybe some day some enterprising soul will gather all the viruses available on the various Vx BBSes - put them on a CD-ROM and offer them for sale. As things are now, I don't see any way to stop that - It is difficult to write a law that would prohibit writing/selling viruses...and any such law might be challenged as violating the first amendment (isn't that the "free speech" thing ?)...It is much easier to make laws prohibiting introducing viruses into somebody's comeputer system...but still... As I have said before - the lack of any action against virus writers is the primary reason why viruses are a problem today. - -frisk Fridrik Skulason Frisk Software International phone: +354-1-694749 Author of F-PROT E-mail: frisk@complex.is fax: +354-1-28801 ------------------------------ Date: 14 Jan 93 11:36:38 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Measuring polymorphism barnold@watson.ibm.com writes: > - - Difficulty of analysis. By this metric, the TPE is simpler than the > Whale, and the Whale is simpler than the MtE. I disagree with those of your arguments. It is a metric for armouring, not for polymorphism. The other arguments were very interesting; I'll think on them... 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: 14 Jan 93 10:46:30 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: How to measure polymorphi bill.lambdin%acc1bbs@ssr.com (Bill Lambdin) writes: > How about releasing a polymorphic virus on a test machine with several > thousand bait files that are identical. 2-5 thousand bait files should be > enough. > infect these bait files, then use a program that would generate CRC's of > all of the infected files then delete the duplicates. > > If the MtE generates fewer dupes than the others, call it the most > polymorphic Not good enough... A virus that puts a single word (two bytes) of random garbage in the decryptor will be flagged as more polymorphic than MtE by your scheme... 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: 14 Jan 93 11:25:41 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Math Models of Polymorphic Viruses ygoland@edison.SEAS.UCLA.EDU (The Jester) writes: > The picture of this process is a tree graph where each node is a > mutation of the root with a theoretically unlimited number of > children (You can just increase K to some arbitrary size when you > wish to increase the number of mutations) each of which is itself a > node with children and so on and so forth. Further more the graph > does NOT have to be directed. It is possible for a child to produce > its parent given the appropriate key. The graph obviously IS directed, with the different keys marking the directed edges. You probably mean that the graph does not have to be a TREE, i.e., there might be loops. > The question is:Given functions VX() and VY(), can I determine if > they are both members of the same tree? Further, if this problem More exactly, the question is: given nodes VX and VY, it there a way to determine whether a node VZ exists, from which there are paths to both VX and VY? > The application of this problem is obviously to polymorphic viruses. > V() is the polymorphic virus function and K is whatever the virus is > using to determine its next mutation. So if I have some known virus > VX() and I scan the system, I can compare code against VX() and > determine membership. Also, it might be possible to apply the solution to the problem of measuring polymorphism... For instance, polymorphism could be measured as average length of the loops in the graph, or as average "valentness" of the nodes, etc. 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: 14 Jan 93 11:04:37 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Infection question (was: Viral Based Distribution System) celustka@sun.felk.cvut.cs (Celustkova-k336-doktorand(Richta)) writes: > Cite from your paper "Possible Virus Attacks Against Integrity > Programs and How To Prevent Them", EICAR Conference,Munich,December > 1992 (stresses are mine): [citation deleted] > Cite from Virus-L FAQ : [citation deleted] Well, having in mind that I have participated the writing of both my paper and the Virus-L FAQ, I obviously know what's written in them... :-) > Companion viruses don't modify files but information about them and > create new files which is executed instead of the intended, i.e. they > modify the previous state of the system. In that way they could cause Yes, I know that, of course... I was just pointing out that the "common" understanding of the term "virus" (by the end user) as "something that messes with my files" is not always correct, even for the currently existing types of viruses on the IBM PC. These viruses (boot sector infectors, file system infectors, companion viruses) do not match even Dr. Cohen's natural-language definition of the term "virus", unless you define "program" and "attach" too broadly. And IF you define them broadly enough, a "worm" will fit in the definition of the term "virus" too. They are essentially one and the same thing, from the mathematical point of view... Nevertheless, for reasons of convenience, we prefer to differentiate between them in practice. 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: 14 Jan 93 10:54:40 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: How to measure polymorphism maloned@ul.ie (Declan Malone) writes: > Let me explain. What polymorphism is, essentially, is a term > describing randomness, true? Now how do you measure randomness in an > objective way? You can't really, and the irony of it is that the more > you try, and the more objective/detailed your description becomes, the > more you are taking away from the central essence of the word `random' > or sending your definition in the wrong direction. It seems to be the Well, yes, but if you show two polymorphic mechanisms to a human virus expert, he is usually able to tell which one is more polymorphic... I was thinking about some objective way to provide such evaluations... > You say that there is a real need for an objective way of measuring > the level of polymorphism, but why is that so? If a user has a new > virus running loose on his system, it is of little interest to him > whether it is more or less random than another virus. Even to scanner > manufacturers, I think, the point is largely irrellevant - so long as > they can produce a scanner to detect the virus, its level of > polymorphism is purely academic. Of course, it is academic issue... Actually, such an evaluation criteria would be more useful to the anti-virus researchers than to the end user... But it wouldn't be completely useless even to the end user. The ability to detect extremely polymorphic viruses reflects the quality of the R&D department of the company that produces a scanner. The users might want to know "how good" that company is in detecting "difficult" viruses. For that purpose, there needs to be a way to measure the "difficultness" (i.e., the polymorphism) of the virus objectively. Why do you think users keep asking whether some scanner detects MtE, instead of asking whether it detects Cascade... Regardless that Cascade is rather common and none of the MtE-based viruses has been found in the wild yet... > Even so, taking it that there can be no a-priori measure of > polymorphism, for specific purposes, measures can be defined that, > while not measuring randomness, give something that is useful in the > context. Yes, it would be useful if we can achieve at least that... > 1 Is every byte of every sample constant? (a simple CRC will identify it) > 2 Is there a fixed (no wildcards) signature that will identify it? > 3 Is there a simple wildcard signature (constant length) to identify it? > 4 Is there a complex wildcard signature to identify it? ( signature matches > variable length strings) > 5 etc Right, this is something like the "classes" scheme described in my original message... However, the real problem is how to differentiate the polymorphism of the viruses that are in category "5 etc"... :-) > in terms of scanning. Still, it's really only of use at low levels of > polymorphism - after that things would start to get really hairy . . . Exactly... > fascinating stuff. One metric that I think might be interesting would > extract the total number of useful signatures from a program (or as a > ratio of the total possible signatures for that file) - not only would > you get some idea of polymorphism, but you'd also get some idea of how > well a signature picked at random for the virus would withstand random > modifications to the virus. This could give stats for how likely a > signature would be of detecting various new variants with increasing > modifications. Because it's signature-based, the effect of moving > sections of code around from original to variant is much less over Hmm, that sounds interesting... Could you write some program that implements this idea? Would be nice to test it in practice... 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: Thu, 14 Jan 93 19:43:47 +0000 From: robert.heuman@rose.com (robert heuman) Subject: Export restrictions on anti-virus software Date Entered: 01-14-93 13:33 aryeh@mcafee.com (McAfee Associates) posted part of the material re Export controls and then asked a question as follows: > Question: Does "In the public domain" mean a program that is not > copyrighted, e.g., "free" as in the context of "public domain" > software, or does it just mean a program is widely available to the > public, and thus not subject to export controls--even if it is > shareware, e.g, publicly-available but copyrighted? I asked the bureaucrats this same question, and was told it meant what it said, and that they would not define it any further - and would interpret it on a case by case basis.... however, they also said that something being widely available, or even imported electronically, did not mean a thing.... If it had a price attached to it, and was not marketed according to the strict interpretation they had for packaged software, it came under the rules. Therefore although I had 'imported' F-PROT electronically, I could not send it electronically to our offshore locations.... That would be a violation of the act. I know it is silly... you know it is silly (and unenforcable)... but that is the way THEY intrepret it, and THEY MUST be right, right? Even sillier was that I then asked that if I did apply for the export permit, could I export it electronically once the permit was obtained, and was told - NO! It had to go through Customs, with the permit attached, and couldn't if in a communication! (Of course they are correct - it can't, but who needs postal delays on time sensitive material?) I do not suggest that any of the rule makes sense - it doesn't in the context of either F-PROT or SCAN/CLEAN, etc. These posts are for everyone's information. However, I do ask if someone could check the latest rules for the US and other COCOM countries, and see if they have the equivalent. I suspect they do, and wonder how each bureaucracy would interpret this same issue. Bob - --- RoseReader 1.70 P001886: This Canadian has an Opinion...His Own! RoseMail 2.00 : RoseNet<=>Usenet Gateway : Rose Media 416-733-2285 ------------------------------ Date: Thu, 14 Jan 93 17:54:31 -0500 From: fc@turing.duq.edu (Fred Cohen) Subject: Re: on the definition of virus In a recent virus-l, someone wrote that they liked Alan Solomon's redefinition of a `real virus' as `a program that replicates without the user's awareness and cooperation' (p602 V11N7 Computers and Security). There are some minor problems with this definition that I would like to point out. 1) If a user is aware of the `Brain' virus on a floppy disk, and inserts it anyway and boots, it is a virus? According to Solomon's definition it is NOT a virus because the person was: a) aware b) cooperative HOWEVER - If another user does exactly the same thing without knowing that the disk contains a virus, then it IS a virus! My problem is that I now have to assess the state of mind of the user to determine whether the thing we call `Brain' is a `real virus' or not. We know for certain that it is a `virus', but whether it is a `real virus' changes as the user's awareness level changes. Careful - if you go to sleep - it's a `real virus' - but don't worry - when you wake up it isn't. How about in a multiuser environment? The same sequence of bytes is both a `real virus' and not a `real virus' because one user is aware that it replicates and another is not. If `backup' a `real virus'? It was a few days ago, but now that you are all aware that it is a `virus', it is no longer a `real virus' for you. What about fully automated systems, where there are no `users', EVERY replicating program is a virus, because there is no user awareness. How about designer awareness? Administrator awareness? I guess that my maintenance viruses are `real viruses' because the users aren't aware of them. Even if I tell them about the viruses - they are still `real viruses' because the users don't have to explicitly cooperate in order for the maintenance to take place. So I guess we can have benevolent `real viruses' as well. What is all this leading to? The environmental factor that determines what meets Solomon's definition of Solomon's `real virus' has to do with the state of mind of the `user'. That means that there is no objective test to determine whether or not something is a virus because two different observers could draw completely different conclusions and both be right. Solomon then goes on to state that ``useful (antivirus software) differentiates between (`real viruses') and non(`real viruses')''!!! But this means that useful anti-virus software can differentiate between the states of mind of different users! Fantastic!!! It read's your mind, and only warns you if you aren't already aware or you aren't cooperating! Of course, in testing, it never tells you about a virus, because there are no `real viruses' in a test - after all, you know about the test and you are cooperating. HUMOR ON!!! (I wouldn't want to offend anyone's sensibility) Is that why Solomon's toolkit does so poorly in tests? (NOTE Solomon's toolkit is really quite good at detecting known viruses - even in tests). We must conclude from this that Solomon's antivirus products are not useful - by his own claims. But I think he wants us to believe that they are useful, so I am anxious to find out how they detect the state-of-mind of the user. ... Sorry - they don't do that yet. HUMOR OFF!! Maybe Solomon's product is very good - but his definition isn't. __________________________________________________________________________ 8:30AM-2PM Eastern Protection 2PM-8:30PM Eastern US+412-422-4134 Experts US+907-344-5164 FAX US+412-422-4135 -OR- 907-344-3069 24 hours - 7 days __________________________________________________________________________ ------------------------------ Date: Fri, 15 Jan 93 00:39:05 -0500 From: Big Foot Subject: Virus Calendar To all those experts out there, I'm trying to compile a calendar, specificing just those virusses that hit on [a] certain day[s], like Payday on every friday except 13th. I already have the list from VSUM. I think I have heard others on this list trying to do the same, but never heard anything about a completed (as far as that's possible, with viri getting created in bunches .. :-( ) one. So, I would like al of you who gave up (?), or just have some information to e-mail me. At the moment, I'm compiling month by month, and think I got next Februari covered ... Second, is there a way to scan the VIRUS-L backlogs. Listserv@lehigh did not understand my mails (I got several ideas from HELPNET, but no way ..) I just wanted to find the ones containing "calendar" or something similar [Moderator's note: Yes, there is a way to scan the backlogs. All postings to VIRUS-L/comp.virus, since day one, are archived on cert.org in pub/virus-l/archives. The old listserv@lehiibm1 no longer has any VIRUS-L archives on it.] Third, a Dutch magazine mentioned the Hymn virus, which seems to hit on the day with the same number as the month, so Jan. 1th, Feb. 2nd, etc ... VSUM and F-prot did not know about it ?!? aTdHvAaNnKcSe, - -- Marc du Bois .--------_____ _/ Systems & Network operator EDP-CC |__o __ == AT&T Network System Netherlands bv. `---\\---- ------------------------------ Date: 15 Jan 93 05:10:14 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: A-V virus fc@turing.duq.edu (Fred Cohen) writes: > I think that an alternative to off-line checksums is access > control. This has worked in IT for several years, and defeats all of the > other attacks against the crypto-checksum I am aware of. I disagree, for several reasons: 1) As you admit yourself, access control requires the proper hardware that is able to provide memory protection, and proper software that actually uses these possibilities that the hardware provides... In practice it means - not an MS-DOS, or MacOS, or AmigaDOS, etc. system. But the current viruses are a problem exactly in these systems - if you switch to something else, they are not (at least not yet) a problem. Not that they are impossible - they are just not a problem. However, what to do with the -current- systems? They are going to be with us at least for the next ten years... 2) Wasn't it you who has proven that discretionary access controls are unable to stop the virus spread, unless they limit the sharing or the transitivity of the information flow? They can at most slow down the spreading of the virus, or limit to a cluster of users (if POSets are implemented)... 3) Access controls do not prevent at least one of the virus attacks against integrity checkers I can thin of. They are unable to stop the slow viruses. In fact, the first slow virus was developed exactly as an attack against monitoring programs and only afterwards it was noticed that it is also very effective against integrity checkers... Maybe something could be done by introducing strongly typed labeled objects and strict distinction between code and data... I've heard that such systems tend to be pretty clumsy and unusable... > >Actually, that definition isn't useful. If the "environment" includes > >a user typing "copy", then any file is a virus. > I disagree strongly. You are right that under my definition, if > the environment is such that all programs are always copied, then all > sequences of symbols are viruses. I published this result in 1985 in > some detail, and showed a Turing machine example where all sequences are > viruses. You are not right that just because one user copies one > program one time, it makes the copied program a virus. The reason is > that the copied program won't necessarily copy itself when you run the > copy. That is the reason we have the `ad infinitum' at the end of the > linguistic version of the definition. To qualify as a virus, given a > proper environment, the program must ALWAYS reproduce. Well, consider the following example: Program: XCOPY.EXE Proper environment: a) MS-DOS computer, which is turned on, contains the file XCOPY.EXE in the current directory on the current drive and has a formatted empty diskette in drive A: b) user, typing XCOPY XCOPY.EXE A: Under this "proper environment" the program XCOPY.EXE always reproduces itself. So - is the program XCOPY.EXE a virus in this environment? 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: 14 Jan 93 12:00:49 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: OS2SCAN99 checked (OS/2) KARGRA@GBA930.ZAMG.AC.AT writes: > OS2CLEAN: at least I found no problems, when I tried to clean my system from > [JERU]. Are you -absolutely- certain about that? You see, Jerusalem makes some silly assumptions about the format of the EXE files. As a consequence, it destroys some EXE files it infects (e.g., WordPerfect). It is my understanding, that it will destroy all Windows applications, and I think that OS/2 applications have a similar structure. Therefore, no disinfector would be able to recover such files, although some intelligent disinfectors warn the user that these files are destroyed. > Is there a reason, why you still > don't scan *.DLL? At least I do not know any virus that could infect them... And since SCAN is able to detect only known viruses, it doesn't make sense to scan objects that the known viruses do not infect... > You added new extensions, of which I never thought, they > would contain executable code (*.PIF). So I learned some new things. If The .PIF files contain a pointer to an executable file. Therefore, it is possible to apply a companion-type attack to them - change the pointer to another executable that contains the virus body and let the virus itself execute the original program. However, no such virus exists yet, which means that there is no need for a scanner to scan these files. They should be checked by the integrity checkers, however. 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: 14 Jan 93 17:24:35 +0000 From: frisk@complex.is (Fridrik Skulason) Subject: Re: DOS Viruses under HPFS (OS/2) antkow@sis.uucp (Chris Antkow) writes: > Being a virus researcher myself, I find it sometimes suicidal to test >out and disassemble new stealth and polymorphic class viruses on my >DOS based PC. I'm deathly paranoid that it's going to escape on one of >my floppies and infect the rest of my house... Even though I know my >ASM a bit better than the average Joe, who knows what might happen. Well....what you need is a "clean room" - say, a setup like the one I saw at Symantec - a room full of XTs, ATs etc, and several guys working full-time in there analysing/testing viruses...and not allowed to take them out of the room. Realizing that this might not be practical in your case, I would suggest a special, dedicated machine, just for running viruses. If that is too expensive, consider adding a switch to the outside, to make the disk read-only while you are looking at the viruses. - -frisk Fridrik Skulason Frisk Software International phone: +354-1-694749 Author of F-PROT E-mail: frisk@complex.is fax: +354-1-28801 ------------------------------ Date: 14 Jan 93 17:06:33 +0000 From: frisk@complex.is (Fridrik Skulason) Subject: Re: how to get rid of the Naughty Hacker-1? (PC) cournoye@ere.umontreal.ca (Cournoyer Louis-Georges) writes: >Norton anti-virus as reported the presence in my computer's memory of >the virus Naughty Hacker-1. The Nav program says to boot with a disk >which has the same system, which in this case is ms-dos 3.3. That i >have done... >however, doing so, the nav program is not able to recognize the virus... >What should i do? Well, one suggestion might be "Get another A-V" program :-) >Another funny thing is happening: if i take the ansi.sys out of my >config.sys file, the nav isn't able to find the virus... It looks to me as if this might be a false alarm, but I was not aware of NAV causing this particular false alarm. You could start by calling them, and checking if this is a known problem with the version of NAV that you are using. - -frisk Fridrik Skulason Frisk Software International phone: +354-1-694749 Author of F-PROT E-mail: frisk@complex.is fax: +354-1-28801 ------------------------------ Date: 14 Jan 93 11:41:05 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Monkey [Mon] and Multi-2 [M12] viruses (PC) LIBBIE@pucc.PRINCETON.EDU (Libbie Counselman) writes: > The first one discovered was the Monkey [Mon] virus. It affects the > File Allocation Table. SCAN discovers it, but does not disinfect, but > Norton Disk Doctor will recover the clean FAT. > The second is known as Multi-2 [M12]. It has a predecessor called > Multi [M-123], also not recognized by F-Prot. This one infects .COM > files, .EXE files, overlays and becomes memory resident. CLEAN > apparently disinfects it. Sigh... Yet another identification problem... SCAN 99 does not report as [Mon] or [M12] anything from our virus collection, so obviously we do not have these viruses. SCAN 99 reports as [M-123] the virus with CARO name SD-123. This virus -is- detected by F-Prot 2.06a, so obviously you mean a different one... 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: 14 Jan 93 10:36:56 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: How do MtE utilizing viruses detect themselves? (PC) Malte_Eppert@f535.n240.z2.fidonet.bad.se (Malte Eppert) writes: > Can anybody tell me how MtE utilizing viruses detect themselves in an > infected file? It depends - the different MtE-based viruses use different methods. The variants of Dedicated pad the infected files to the next multiple of 256 when infecting it and do not infect files with size that is an exact multiple of 256. Pogue puts an 'M' in the first byte of the infected COM files and uses this as an infection marker. And so on. Because those viruses to not have an exact MtE-detection mechanism, this means that they might not infect some infectable files (they will think that those files are already infected). This is sometimes called "sparse infection". > Or do they reinfect the file each time they attack it, > like old Jerusalem? No, they are not -that- stupid... :-) > Can't an algorithmic scanner use the method used > by MtE itself to detect it? Unfortunately - not. The virus author does not care if his virus does not infect some infectable files, while a producer of an anti-virus program cannot permit himself to erroneously flag a perfectly valid file as infected... The only thing that can be done is to use the infection marker of the virus as an heuristic to sieve out the files that are obviously not infected. For instance, if you need to detect only Pogue, you can check if the file is a COM file and its first byte contains the character 'M'. If it is not or it doesn't, then you know that it is not infected by Pogue and don't need to spend more time checking... Only if it looks like a Pogue-infected file, you'll have to apply your algorithmic detection... 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: Thu, 14 Jan 93 18:17:09 +0000 From: mcafee@netcom.com (McAfee Associates) Subject: CLEAN removing Jerusalem (Was: Re: Jerusalem (Israeli) Virus (PC)) Hello Vesselin, You write: >Due to the infection method that this virus employs, it destroys EXE >files with internal overlay structure (e.g., WordPerfect). Such files >will crash when executed. They will still crash after disinfection, >although McAfee's Clean does not warn you about that. If you have an ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >outbreak of this virus, the best solution is to delete all infected >files and to replace them with clean copies. CLEAN-UP does have a limited ability to check a Jerusalem virus infected file and warn the user that the virus can not safely be removed. It will then ask the user if he (or she) wants to overwrite-and-delete the file instead. Regards, Aryeh Goretsky McAfee Associates Technical Support - -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 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: Thu, 14 Jan 93 14:24:13 -0500 From: "David M. Chess" Subject: Re: Clash between FDISK/MBR and scanners (PC) > From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) > ps It is my understanding (David ?) that OS/2 uses selection through a > replacement of the DBR (OBR ?) *not* the MBR and requires a more complex > approach... There are two multi-boot arrangements available with OS/2. One (called "Dual Boot") works about as you say: when you boot the machine, it comes up under whatever OS you last had. If you want the other one, you use the BOOT command, which swaps OSBRs (not the MBR) and reboots. The other one is Boot Manager, which sits in the bootable partition on the disk, gets control from the (normal) MBR, puts up a menu asking what OS you want to boot, and when you answer it loads and executes the corresponding OSBR. Neither of them does anything to the MBR when you change OS's, that I'm aware of. Note that I'm anything but an Official IBM Spokeshacker on this subject, though. I just have a messing-about knowledge of it. - - -- - David M. Chess mI' jIHbe' jay'! High Integrity Computing Lab loD tlhab jIH! IBM Watson Research -- qama''e' ------------------------------ Date: Thu, 14 Jan 93 21:34:27 +0000 From: FRAHM@UCSU.COLORADO.EDU (Joel A. Frahm) Subject: Mr. BIOS (PC) 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 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? Thanks in advance, Joel A. Frahm, Joint Institute for Labratory Astrofizzics. ------------------------------ Date: Thu, 14 Jan 93 21:39:18 +0000 From: pmm34393@uxa.cso.uiuc.edu (Paul M. Minutillo) Subject: Re: Problems with PCs (PC) Thanks to those who responded to my original post. I contacted the McAfee people concerning my problems and apparently I have a virus that is not caught by Scan v. 99. Here are the symptoms: Every executable or com (maybe others) that is run, increases in size the first time it is run if the virus is in memory. Every so often I get a sharing violation on drive C (my hard drive), sometimes I get overflow or divide errors. I don't think anything is being deleted, but a couple of executables won't run because they have been modified. For the most part I can still run everything. I never get errors while within programs, but after I exit a program and try to do something else I will occasionally get a sharing violation error. If anybody has any other virus program or knows of a way to get rid of this please let me know. If there was a way to compare an infected program and a non-infected one to find what is different, would I be able to take the difference, plug it into Scan and delete that part from my executables? As before, please respond by e-mail. - -- Send e-mail to: pmm34393@uxa.cso.uiuc.edu ------------------------------ Date: 15 Jan 93 05:50:16 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: New way of opeing files??? (PC) antkow@sis.uucp (Chris Antkow) writes: > Apparently, there is a new way of opening files which some AV > Utilities don't catch. I've heard that the NuKE group is starting to > use function AX,6C00h/INT 21h to open files... First, the method is not new - it was introduced in DOS 4.0. Second, it is not backwards compatible - if a virus uses it, it will not run under DOS 3.30 and below. Third, there are already viruses using this function (or intercepting it) - since quite a lot of time... :-) Fourth, the knowledge of the members of the NuKE group about the internals of DOS is not very impressive, if one takes a look at the incredibly boring and silly viruses they continue to produce... > Can anyone confirm the > use of this function and are there any AV programs that trap this > function? I don't know, but why bother? First, even if a monitoring program traps this function, it can be easily bypassed, using one of the many tunneling techniques. Second, with this function it is possible only to open or create (i.e., destroy) a file. If the virus wants to infect it, it has to Write to it, and most monitoring programs I am aware of, do trap the write operation... 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 ------------------------------ End of VIRUS-L Digest [Volume 6 Issue 10] *****************************************