Received: from barnabas.cert.org by abacus.hgs.se (5.65c/1.5) id AA16900; Wed, 3 Feb 1993 21:01:52 +0100 Received: from localhost.cert.org by barnabas.cert.org (4.1/2.3) id AA25747; Wed, 3 Feb 93 15:04:17 EST Message-Id: <9302032004.AA25747@barnabas.cert.org> To: mikael@abacus.hgs.se, mil@solace.hsh.se Subject: Re: issue 15 In-Reply-To: Your message of "Wed, 03 Feb 93 20:31:24 +0100." <199302031931.AA14805@abacus.hgs.se> Date: Wed, 03 Feb 93 15:04:16 EST From: Kenneth R. van Wyk Status: RO VIRUS-L Digest Tuesday, 2 Feb 1993 Volume 6 : Issue 15 Today's Topics: Virus Calendar Measuring polymorphism re: On the definition of viruses Re: On the definition of viruses Re: What is a virus ? Re: Heuristic Scanners Re:Mainframe viruses? [Sam Wilson:06/13] + - viuses re: Os2scan checked (OS/2) CANSU V-SIGN at GA Tech (PC) DOS CHKDSK bug: How to show it with a small hard disk (PC) (Re) Cansu virus plague revisited (PC) Re: windows virus (PC) DON'T DO THIS! (was: False positives, disk buffers, and IO.SYS) (PC) Virus???? (PC) VSHIELD, VIRSTOP, ... comparison ? (PC) Re: NOINT Virus (PC) PKZIP204e (PC) Re: 696 Virus? (PC) Re: False positives, disk buffers, and IO.SYS (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: Tue, 26 Jan 93 03:17:00 +0100 From: Fil_Grushevsky@f0.n744.z9.virnet.bad.se (Fil Grushevsky) Subject: Virus Calendar Hello! > From: mdbois@hvlpx.ns-nl.att.com (Big Foot) > 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. A lot of "Soviet" viruses "love" xUSSR holiday (like 23 February, 1 May, 7 November, etc.). If you like more information, ask please... > > 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 ?!? Family of this virus contains 3 viruses (1865, 1962, 2144 bytes lenght) Virus infected Com & EXE files when file run, open, rename, create, change attr. Virus correct run only in DOS v3.30. Very dangerous viruses.When day = number of month, virus demage boot sector of "C" drive, display picture (some version) and false play HYMN xUSSR. When boot sector demage by this virus: - - boot up PC/XT stay impossible (!) from HD and from normal boot floppy. You need to create special boot disk with special boot sector. - - on PC/AT and other PC with CMOS, boot up from HD stay impossible too, but you may boot up your PC from floppy disk with MS-DOS version => 4.0 Sincerely, Fil Grushevsky - --- RA-Echo/beta * Origin: MiKrOB Point (9:744/0) ------------------------------ Date: Sun, 24 Jan 93 16:41:00 +0100 From: Malte_Eppert@f6050.n491.z9.virnet.bad.se (Malte Eppert) Subject: Measuring polymorphism Hi Frisk! > MtE: 174 lines Wow! You managed to correctly scan any MtE mutation by using 174 wildcarded scan strings? I thought this was impossible, because the MtE makes viruses _ very_ polymorphic, and you must use an algorithmic approach? Are you going to detect the TPE in the same way, with even more scan strings? cu! eppi - --- Via SCANTOSS V 1.37 * Origin: Another Virus Help Node - The EpiCentre! (9:491/6050) ------------------------------ Date: Thu, 28 Jan 93 07:52:01 -0500 From: fc@turing.duq.edu (Fred Cohen) Subject: re: On the definition of viruses Y. Radai writes > 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? Only at runtime! > > To illustrate the generality of the situation, I'll even offer a >choice between three reasonable informal definitions of "virus": > >(a) a virus is a sequence of instructions which replicates on *every* > execution; Replicates is probably not general enough - perhaps procreates would be a better term - intending to include evolution. Also, instructions is a relative term. I prefer to discuss sequences of symbols. These symbols can be interpreted by any number of mechanisms. This may seem subtle and unimportant, but it is vital to have a `ground state' - something that corresponds to a physical reality, not something relative to something else. Instructions are different things in different environments (e.g. 11101011 is a `jmp' on an 8080 and an `addm' on a 6800), but symbols from the symbol set of the machine are not (a 11101011 on either machine is still a 11101011). > >(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. > >(c) A sequence of instructions is a virus in a given run-time environ- > meant if and only if it replicates in that environment. > Looks better - same as (a) above. > 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. >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!!!'. > If the definition is (a) or (b), then we can do even better: we can >show that in some cases the question cannot be decided even by running >the program any finite number of times. For example, suppose the >program asks the user to input four positive integers i, j, k, n >(where n must be > 2). If you choose definition (b), I shall take > to be "i^n + j^n = k^n". > > Now for all anyone knows, it may be that this condition is *never* >actually satisfied. (The statement that there are no such integers is >Fermat's "Last Theorem", for which he *claimed* he had found a proof, >but he didn't produce it and no mathematician since him has found >either a proof or a counter example.) 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. > If you choose definition (a) instead, I take to be the >negation of the above statement, and the same argument works. Again not right for the same reason. > In any case, there are some situations in which you can't decide >whether a given program is a virus. 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. > We can substitute for Fermat's >Theorem any other unsolved problem. If you could write a program >which could decide whether the resulting programs are viruses, then >you would become famous for having solved all the world's heretofore >unsolved problems!! (Well, at least those which can be expressed by a >computer program.) Thus it is intuitively clear that the property of >virality is undecidable, at least for all practical purposes. As above. 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? > Of course, one can take the position that it's just an historical >accident that these problems have not yet been solved, and that in >principle they may all be solved some day. However, it can be shown >that there are infinitely many problems which can *never* be solved >(although that apparently requires use of one of those "paradoxical"- >type proofs which I've been trying to avoid here). 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. > Comments are welcome (especially Fred's). You should know better! A general comment may be in order here. The problem with your way of looking at this issue is that in order to make claims about mathematical problems, you need a mathematical model. Your model isn't mathematical enough to do proofs. 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. If we use: If then we force the detection program to solve a potentially unsolvable problem. In the proofs I wrote, I demonstrated a virus that could evolve ANY result that ANY Turing Machine could compute - hence showing the generality of viral evolution. The dual purpose of this was to show that in order to determine whether a program is a virus, we must be able to determine whether ANY Turing Machine will halt. Hence the undecidability of viral detection. Perhaps a more interesting measure would be how much computing power is required to solve the virus detection problem for a machine of any given size. This then is covered by the complexity theory in widespread use. Given some seemingly reasonable assumptions, we can show that many types of evolution yield NP-complete detection. I wrote a paper on this (soon to be released?) in Computers and Security. Most of the problems you have described fall into that category, and are for practical purposes unsolvable for most computers today. I am not saying that your presentation isn't interesting or useful, only that when you try to get down to the mathematical level, it runs into a brick wall. The wall is made up of undefined terms and loose assumptions. It may appear to be easily bypassed, and many may wish to walk through it as if it weren't there, but they may, in doing so, make mistakes that result in real world decisions that are later judged inappropriate. Perhaps we will soon have zero-knowledge viruses! FC __________________________________________________________________________ 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: Wed, 27 Jan 93 16:50:16 -0500 From: Jerry Leichter Subject: Re: On the definition of viruses In VIRUS-L Digest V6 #11, Y. Radai presents an argument that general virus detection is impossible, for any reasonable definition of "virus", based on code of the following form: if then By making non-computable, Radai makes it impossible to determine whether the code (ever | always | in some known set of circumstances) actually 's, hence rendering any definition of "virus" that relies on being able to prove that the program infects non-computable. There are at least two problems with this approach: - It has nothing to do with viruses! Suppose I attempt to recognize "programs that print the number 4". What does "print the number 4" mean? Well, it might mean "ALWAYS prints 4" or "SOMETIMES prints 4" or "in some well-defined circumstances prints 4". But the program if then print 4 cannot be computably tested under ANY of these definitions. The non-computability is in the ; the fact that you can attach it to just about any predicate says nothing about the predicate. - None of the definitions that Radai gives really tell us what we really want to know about a program. If the in if then can be satisfied, then certainly we don't want the program around (assuming is an operation we don't ever want carried out). If we can prove that CAN'T be satisfied, then perhaps the thing isn't "really" a virus, but it's still dead code, and we'd prefer that it not be there. However, we can live with it. (Such code can actually arise as the result of a successful disinfection.) If we can't prove either that IS satisfiable, or that it is not, then I can't imagine any circumstances in which we would treat this as anything BUT a virus. A reasonable PRACTICAL definition of a virus is that it is code such that SOME path through it (which we cannot PROVE is impossible) infects. Such a definition is, unfortunately, dependent upon our current ability to prove things. The easiest solution is to remove that part of the definition: A virus is code such that some path through it (i.e., some set of choices of choices at all conditions, even those choices that are "obviously" impossible) infects. You could formalize this by replacing your machine model with a non-deterministic machine which, in effect, tries every possible choice at every possible conditional. Nondeterminism is intended exactly to model such "there exists some path such that ..." kinds of conditions. Note that I haven't attempted to define "infect". That's where the real heart of the problem lies, and that's where Fred Cohen's definitions and proofs really come into play. -- Jerry ------------------------------ Date: Thu, 28 Jan 93 13:00:08 -0500 From: "William Walker C60223 x4570" Subject: Re: What is a virus ? There seems to be much confusion over what constitutes an accurate natural-language definition of a computer virus (confusion in general-- no one has any confusion over his own posting ;-) ). Several writers agree that the mathematical definition is clear enough. Maybe so, but many people don't (or won't) understand mathematical definitions. I would like to define what I understand to be a computer virus (I'll put "virus" and "worm" in quotes to refer to the "popular" definitions, and virus without quotes to refer to Dr. Cohen's definition). As Padgett pointed out, Dr. Cohen's definition of a virus includes not only what is popularly known as a "virus," but also what is popularly known as a "worm." The popular definitions separate the two by whether or not a specific "host" program is needed: a "virus" needs a host program, a "worm" does not. A host program could be an MBR/PBR or a stand-alone program. A "virus" could gain control by overwriting the host, attaching to the host, relocating the host and taking its place, or by intercepting a call to a program without directly affecting the host. A "worm" is a stand-alone program that is executed at some point, whether by the parent program, the user, or some other circumstance. However, even by this definition there is still some confusion. Some Macinstosh "viri" propagate by creating new INITs or other resources where none existed before, so even by the popular definition they should be "worms" instead. At this point, the distinction between a "virus" and a "worm" blurs, and there should be one encompassing definition for both. Well, here goes: A computer virus is a sequence of instructions which, when executed under certain conditions, will make a functional duplicate of itself and will place this duplicate where it will intercept program execution at a later time under certain conditions, and may or may not return control to the original program execution at the point it was intercepted. A virus may also have additional functions, but only the above functions are necessary for something to be called a virus. I believe that this definition will apply to all known "viri", and "worms" as well. By "functional duplicate," I mean a duplicate which may not be an exact copy, but operates the same as the original. This would allow for polymorphic and multipartite viri. The key to this definition is "intercept program execution." Most other natural- language definitions say "attach themselves to other programs," then have to make exceptions for BSIs, companion viri, and others. However, all viri must intercept program execution at some point and replicate; how they do it is irrelevent as far as the definition is concerned. Also, a virus does not have to return control at the point it intercepted it. Overwriting viri are perfect examples of this. They intercept a call to a particular program, but never return control to that program -- because it doesn't exist anymore. This definition seems to be free from subjectivity, so even Dr. Cohen might agree with it. I don't expect it to remain unmodified, or even to survive at all, but I would like to see how it holds up under the intense scrutiny it's about to receive. "Incoming!" "Fire in the hole!" Bill Walker ( WALKER@AEDC-VAX.AF.MIL ) | OAO Corporation | This .signature does NOT contain Arnold Engineering Development Center | a stealth .signature virus! 1103 Avenue B | Arnold Air Force Base, TN 37389-1200 | ------------------------------ Date: 29 Jan 93 08:50:37 +0000 From: frisk@complex.is (Fridrik Skulason) Subject: Re: Heuristic Scanners antkow@sis.uucp (Chris Antkow) writes: > ...or anyone who wants to develop a better heuristic scanner! Gee >you're paranoid... Paranoid ? Well, considering the discussion on some virus-exchange BBSes on how to defeat my heuristic scanner, and considering that some of the latest viruses contain code which only serves the purpose of confusing heuristic scanners, I would rather say I was just being realistic. After all, the original posting did not ask for information on how heuristic scanners worked, what their limitations were or how they could be improved, but how they could be defeated - which I am most certainly not interested in helping anyone with. My heuristic scanner may not be foolproof, but it is is able to identify the vast majority of new viruses (which regular scanners cannot do) before they are run (which integrity-checking programs cannot do). Of course it is not able to detect all viruses, without ever giving false alarms...(which is theoretically impossible anyhow), but naturally, the virus authors see this as a threat, and I am not going to do anything to make the life easier for them - directly or indirectly...I hope you understand my position. - -frisk - -- - -- Fridrik Skulason Frisk Software International phone: +354-1-694749 Author of F-PROT E-mail: frisk@complex.is fax: +354-1-28801 ------------------------------ Date: Fri, 29 Jan 93 05:21:28 -0500 From: brunnstein@rz.informatik.uni-hamburg.dbp.de Subject: Re:Mainframe viruses? [Sam Wilson:06/13] 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". Since about 10 years, I happen to supervise several large IBM mainframes for security and backup procedures, but I have NEVER seen, in several disasters due to bugs, inadequately installed or used programs, hacker attacks and few chain letter happenings, ***ANY real mainframe virus*** (I know of some tests performed by some system engineers to see whether viral methods may work and be detected but such "test virii" were carefully guarded). Did I really miss real life experience? Did I miss reports in other European countries? Where to get the material which UK press reports? (Or may this be the same style as UK mass media report on their politicians -:? Klaus Brunnstein, University of Hamburg (January 29,1993) ------------------------------ Date: Fri, 29 Jan 93 06:32:16 -0500 From: KARGRA@GBA930.ZAMG.AC.AT Subject: + - viuses Hi all, 2 things I'm missing in the discussion over viruses, benevolent or not: a) is it necessary to perform a task b) does it try to hide by all means ad a) If a program needs a viruslike program ( can be a worm too) to do what it is supposed to do, and the manuals state clearly, that there is a part of this software acting on its own, then I would not call this a virus in a common sense. ad b) If a program tries to hide by all means, then it is shurely a virus. This is somehow similar to some TSR's, but you can still use even the shurely not very sophisticated "MEM" to see it. JMHO, Alfred ############################################################################### Alfred Jilka # Geologic Survey, Austria # Shall I raise the white towel or throw the flag ??? KARGRA@GBA930.ZAMG.AC.AT # ############################################################################### ------------------------------ Date: Thu, 28 Jan 93 10:20:30 -0500 From: KARGRA@GBA930.ZAMG.AC.AT Subject: re: Os2scan checked (OS/2) Hi all, sorry, I was not clear enough on Cleaning Jerusalem. There WAS no, there IS no and hopefully there WILL NEVER BE a jerusalem in my system. I tried to clean a NONEXISTENT virus, just to see what will happen. OS2CLEAN reported correctly, that no Jerusalem was found. So: no files were damaged... BTW: I checked OS2SCAN once again with gammatech SENTRY on. It locks the boot- sectors and some important files against writing to them. Everything was fine, NO false errors or complaints about a locked file. Alfred ############################################################################### Alfred Jilka # Geologic Survey, Austria # Shall I raise the white towel or throw the flag ??? KARGRA@GBA930.ZAMG.AC.AT # ############################################################################### ------------------------------ Date: Tue, 26 Jan 93 13:30:41 -0500 From: keith.watson@stucen.gatech.edu Subject: CANSU V-SIGN at GA Tech (PC) I have had three confirmed reports of the CANSU or V-SIGN virus on the Georgia Tech campus. At least one workstation in the computer science department was infected. There is no formal reporting system on campus so I suspect that this is just the tip of the iceberg. Keith R. Watson Georgia Institute of Technology, Atlanta Georgia, 30332-0453 uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!kw3 Internet: keith.watson@stucen.gatech.edu ------------------------------ Date: Wed, 27 Jan 93 09:28:37 -0500 From: fwf@gisa.uucp (Frank W. Felzmann) Subject: DOS CHKDSK bug: How to show it with a small hard disk (PC) >From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) > (VIRUS-L Volume 5 : Issue 203) >Assuming that this is causing the problem, DEBUG will find the string: > > 8b 4f 0f 8b f9 (MOV CX,[BX+0F] MOV DI,CX) .... in the "old" and > 8b 7f 0f 32 ed (MOV DI,[BX+0F] XOR CH,CH) .... in the "new" > >CHKDSK.EXE. Both are 16,200 bytes long. This is also correct for the German version of CHKDSK.EXE, (16,984 bytes long) at offset ds:2A4D. You can force this bug also on a small hard disk (smaller than the documented 128 Mb or multiples) by doing the following steps: 1. Corrupt with a disk editor the FAT by changing the information of the first entries (e.g. write "test" in hex dump sector 1 of FAT). 2. Change the entry "number of sectors per FAT" in the boot sector to 256. (Hex address 16 17 to x'00 01') 3. Boot the PC from a floppy disk 4. Start the unfixed CHKDSK.EXE with parameter /F - and 5. You can see intensive writing on the hard disk: 256 copies of 256 sectors (1. FAT copy), i.e. 32 Mb of unwanted FAT copies are written out from the start of the first FAT. Frank W. Felzmann - ---------------------------------------------------------------- G German I Information <> Voice +49-228-9582-248 S Security <> FAX +49-228-9582-400 A Agency - ---------------------------------------------------------------- "It's a Snark!" ... Then the ominous words, "It's a Boo---" - ---------------------------------------------------------------- ------------------------------ Date: Thu, 28 Jan 93 03:28:46 -0500 From: schmitz@gisa.uucp (Hubert Schmitz - Bundesamt fuer Sicherheit in der I nformationstechnik) Subject: (Re) Cansu virus plague revisited (PC) Here are some remarks about V-Sign-Virus (alias Cansu, alias Sigalit) Description of the virus V-Sign (alias Cansu, alias Sigalit) has two parts, the boot sector and the virus body. The boot sector contains only a short routine (about 38 Byte), which loads the virus body into memory and transfers control to it. The virus body is located in: Zylinder 0, Head 0, Sector 4 + 5 Harddisk Track 0, Head 1, Sector 2 + 3 5.25" DD Track 0, Head 1, Sector 13 + 14 5.25" HD Track 0, Head 1, Sector 4 + 5 3.5" DD Track 0, Head 1, Sector 14 + 15 3.5" HD On floppy disks these sectors represents the last two sectors of the root directory. If control is transferred, the virus goes memory resident and hooks interrupt vector 13 (for controlling diskettes and hard disks). After this the virus restore the original boot sector and transfers control to it. The PC normally boots. Because there is a bug in V-Sign, floppy disks, which are infected in drive B: don't work correctly. If you boot with such an infected disk, the virus try's to load the virus body not from drive A: but also from drive B:. If there is not an identical infected disk, you will get a System Hangup. V-Sign has two variants which differs in the payload trigger. After 64 (variant 1) or 32 (variant 2) infections in a non interrupted system (you don't have to power down the PC) it will display a "V" (Victory) sign on screen and the computer hangs. To remove the virus whitout any tool, cold boot the computer from a noninfected, write-protected boot diskette first! Format floppy disks with the option /U. On hard disks use the undocumented option /MBR with FDISK-command (FDISK /MBR, only with MS-DOS 5.0). This option writes a new partition record without changing the partition table. About your problem The virus is not transferred into memory only by executing the DIR command on floppy disks. That means, that the PC is already infected (and the virus is active) by executing DIR and running McAfee's SCAN. V-Sign goes memory resident only by booting from an infected floppy disk or hard disk. About SCAN - CLEAN There are two possibilities 1. You run SCAN in a clean system (V-Sign is NOT in memory): SCAN reports a virus on a floppy disk. If CLEAN warns you about "Virus active in memory", this is a false alarm. There is a virus image in memory (from SCAN), but not active. 2. You run SCAN in an infected system (Virus is active in memory): Then SCAN reports the virus in memory. If you run CLEAN now, it will also warns about "Virus active in memory". Hubert Schmitz, GISA (German Information Security Agency) Postfach 20 03 63 W-5300 Bonn 2 Germany Internet: hsm@bsi.de ------------------------------ Date: 28 Jan 93 09:35:07 +0000 From: frisk@complex.is (Fridrik Skulason) Subject: Re: windows virus (PC) S.M.Baines@sheffield.ac.uk writes: >I am sorry to be a nuisance, but several users of Windows at Sheffield >appear to have been hit by a virus that isn't detected directly. Which scanners have you tried ? >Using >memory resident virus checkers only detect a write to a protected file >or disc, but not the name. Scanning the disc and memory also fails to >show up the 'virus'. It appears only to infect the Windows files, and >these fail to run. Now, this would rather seem to indicate that it was *not* a Windows virus, but just a regular DOS virus, which was unable to handle Windows executables properly, because it is not aware of the "new executable" format. - -frisk - -- - -- Fridrik Skulason Frisk Software International phone: +354-1-694749 Author of F-PROT E-mail: frisk@complex.is fax: +354-1-28801 ------------------------------ Date: Thu, 28 Jan 93 19:54:53 -0500 From: Anthony Naggs Subject: DON'T DO THIS! (was: False positives, disk buffers, and IO.SYS) (PC) A. Padgett Peterson, , writes: > [...] > > I have run some tests using SCAN (v95 and v100) and F-Prot (2.05 > and 2.06a) and in each case if a DIR was done of an infected > (STONED) floppy prior to scanning, a positive indication of the > "virus in memory" was generated. If a DIR was done on a clean DOS > partition thereafter (without reboot) memory came up clean. > > Next I tried the following: did a DIR on an infected disk - > infection warning was generated. Used debug to clear the IO.SYS > buffer in memory (again without reboot) - scans now reported > system OK. This was proof to me as to what was being detected. And entirely to be expected if you read Microsoft's documentation, (yes they have got somethings correctly documented, :-). Try the "MS-DOS Encyclopedia" [Section I; Section II Articles 2, 3, 15], or "Microsoft MS-DOS Programmer's Reference" [Chp 9], both from Microsoft Press (distributed by Penguin outside North America). Other sources give similar or supplementary information. > In no case was there any indication that the signature was found > in low memory (segment 0000, first 64k) rather each scanner > finished its examination of memory and then reported the virus. > For some time we have been thinking that somehow a virus > signature was being introduced into the disk buffers but the lack > of repeatability caused much confusion. ... Padgett, I am really most disappointed, you usually take the trouble to research topics properly before posting. I keep my PC clean, although I have viruses stored on it, I only run a very small, fixed set of software. So I don't often use the a-v utilities that I occasionally fetch from ftp sites to distribute, otherwise I may have spotted some time ago this misunderstanding about 'DOS buffers'. > ...In no case in my testing > did I ever find a DBR in the buffers, only root directory > entries. However in every case following floppy disk access as > described above, the DBR was found in the IO buffer in segment 0. This is how DOS is designed, only the Block Device Drivers (ie those that interface DOS to disks, tapes, CD-ROMS, etc...) actually check the DBR. They may use the common temporary buffer provided by IO.SYS, or their own private buffers. > Just as a suggestion to a-v developers: since I have not observed > any ill effects from clearing this buffer other that a reload on > the next floppy access and it is a source of false positives, why > not just clear the buffer before starting a memory scan ? Please, please, please DON'T DO THIS. Firstly, it is very bad practice to mess with the private data of any other program. Secondly, Block Device Drivers use the data in this buffer to detect disk changes - altering it may damage open files or make DOS unstable. Thirdly, products that produce such a false alert demonstrate an inherent weakness in their design. It is surely better that developers understand DOS properly when producing their products, than that they frig around with other program's data to get around poor design and testing. Hope this clarifies things a little, 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: Fri, 29 Jan 93 05:23:18 +0000 From: toejam@Panix.Com (Toejam) Subject: Virus???? (PC) I was wondering if anyone has seen this before: I turned on my PC a little while ago and.....what everyone fears happened, it didn't boot all the way, it sorta hung in the middle of the BIOS. Now this happen to me before about a year ago and it turned out to be a virus I picked up from the wonderful user room at my school. I eventually got to the hard drive and tried to salvage what I could but most of the files were corrupted, so I scrapped everything and started fresh. Now the same exact thing happened this time but with one exception 2 of my drive partitions (which I salvaged with Norton) had address listings where my files used to be. The addresses listed were all in the local New York City area but I didn't know any of the people listed. I don't log into local BBS's at all and I'm positive I didn't have a record of these address on my hard drive...so I'm assuming this was a side effect of the virus. BUT WAIT ...it gets even stranger... Since I didn't feel like reinstalling all my files I decided to put it off for a day.....and today everything is back to normal......no strange addresses all over the place the files are all ok...everything booted up ok....this is driving me up the wall.. Has anyone seen this before? I think the first virus that infected my machine was called Witch or the Bloomington virus or something to that effect. Norton AV didn't find anything when I scanned the drives. Has anyone had these addresses appear on their screen. Thanks for any help. =============================================================================== || L I V E F R O M N E W Y O R K I T 'S . . . - Alex Diamantis || ||------------------------------------------------\ Email: ToEjAM@pAnIX.cOM || ||"I don't know if there are men on the moon, but \________________________|| || if there are, they must be using Earth as their lunatic asylum." - Shaw || =============================================================================== ------------------------------ Date: Thu, 28 Jan 93 04:17:00 +0100 From: Nemrod_Kedem@f101.n9721.z9.virnet.bad.se (Nemrod Kedem) Subject: VSHIELD, VIRSTOP, ... comparison ? (PC) Sorry for the delay in reply... > 3) VShield uses much more memory than VirStop. >> >>But may be loaded to high memory, and then needs less then 1K of >>conventional memory. > Implying that Virstop cannot?! Virstop can be loaded high, and then > requires no conventional memory. No, I'm not... I just wanted V.B. to know (or if he doesn't - then check) the many options VShield have. I, presonally, do not use any TSR against viruses. Instead I scan every diskette of program before running it. > And still, VSHIELD will use more high memory that Virstop, reducing the > number of other things you can have loaded high simultaneously. > Even with loadhigh in DOS 5.0, smaller is still better when it > comes to memory-resident programs. Not always... Sometimes smaller meens less options (not implying anything..). I prefer to keep the extra memory I have for more important things. I consider any TSR for a PITA. I run a very complex system and ALL TSR's made lots of problems conflicting with other programs. I simply adopted the habit to check every program with at leats two virus scanners and with a CHK4BOMB program. I wasn't hit by a virus since there were two or three of them ...;-) Regards, Rudy. - ---------------------------------------------------------- Nemrod.Kedem@f138.n403.z2.fidonet.org (Nemrod Kedem) FidoNet: 2:403/138 VirNet: 9:972/0 CI$ ID: 100274,73 (972)3-966-7562 (14.4K) (972)3-967-0348 (Voice) P.O.Boc 8394, Rishon Le-Zion, Zip 75253, Israel. - ---------------------------------------------------------- - --- FastEcho 1.21a/Real! * Origin: Make Safe Hex! (9:9721/101) ------------------------------ Date: 29 Jan 93 08:29:16 +0000 From: frisk@complex.is (Fridrik Skulason) Subject: Re: NOINT Virus (PC) MCKNIGHM%UNION.decnet@gar.union.edu (UNION::MCKNIGHM) writes: >Several of our lab machines have become infected with a virus that has >been identified as: > NOINT (STONED) F-PROT 2.05 > A new variant of STONED F-PROT 2.06 > NOINT CPAV (version that came with > PCTOOLS 8.0) >Why is F-PROT able to detect but not disinfect NOINT and are there plans >for F-PROT to eventually handle the virus? The reason that Version 2.05 identified the virus but 2.06 did not is as follows: One of the changes between 2.05 and 2.05 was the addition of a checksum-identification of boot sector viruses. This was done to provide accurate identification, which is necessary to properly disinfect any virus. Unfortunately, in one case Stoned.NoInt the area the checksum was calculated for was wrong (it included a variable byte), so in some cases the program would identify a Stoned.NoInt infection as a "new variant of Stoned", and therefore refuse to disinfect it. This problem has been fixed, and 2.07, which is due any day now does not have this problem. - -frisk - -- - -- Fridrik Skulason Frisk Software International phone: +354-1-694749 Author of F-PROT E-mail: frisk@complex.is fax: +354-1-28801 ------------------------------ Date: Fri, 29 Jan 93 03:28:31 -0500 From: Pim Clotscher Subject: PKZIP204e (PC) L.S., Got PKZIP204e.EXE today, and remembering the discussions on this list about 204c, I would like to know if this updated version (yes, it claims the problems with 204c being solved...) is official and reliable. No validate info was included. -AV verification upon self- extraction lokked O.K. Any info available? Thanks a lot, Pim Clotscher Erasmus University Rotterdam - NL E.R.C. - Computer Support Hoboken E-mail (Internet): clotscher@coh.fgg.eur.nl ------------------------------ Date: 29 Jan 93 09:01:09 +0000 From: frisk@complex.is (Fridrik Skulason) Subject: Re: 696 Virus? (PC) mark@walt.CS.MsState.Edu (Mark Rauschkolb) writes: >A co-worker just told me that his home machine is heavily infected by >the 696 virus (according to McAfee SCAN). I looked for 696 in the >VSUM "program" but could not find it. To start with, there is no "696" virus - or rather, there are three viruses which happen to be 696 bytes long. The name "696" was originally used to refer to an East-European virus, which is now properly known as "On 64". This virus is now (V99) "identified" as the FamR virus by SCAN. The second "696" virus is one of the new PS-MPC-generated viruses - the "Page" virus to be exact. I haven't checked what SCAN calls it. What Scan calls "696" is a variant of the "Screaming Fist" family, the Screaming_Fist.II.B variant to be exact. - -frisk - -- - -- Fridrik Skulason Frisk Software International phone: +354-1-694749 Author of F-PROT E-mail: frisk@complex.is fax: +354-1-28801 ------------------------------ Date: 29 Jan 93 09:09:56 +0000 From: frisk@complex.is (Fridrik Skulason) Subject: Re: False positives, disk buffers, and IO.SYS (PC) padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) writes: >the next floppy access and it is a source of false positives, why >not just clear the buffer before starting a memory scan ? I have (mostly) fixed this problem in version 2.07 of F-PROT. It will now ignore boot sector virus signatures found in the lowest part of memory, so just doing a DIR of an infected diskette and then running the scanner should not produce this problem any more. - -frisk - -- - -- Fridrik Skulason Frisk Software International phone: +354-1-694749 Author of F-PROT E-mail: frisk@complex.is fax: +354-1-28801 ------------------------------ End of VIRUS-L Digest [Volume 6 Issue 15] *****************************************