From lehigh.edu!virus-l Sun Jan 31 07:00:13 1993 Date: Thu, 28 Jan 1993 14:43:55 -0500 Message-Id: <9301281855.AA17905@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 #13 Status: R VIRUS-L Digest Thursday, 28 Jan 1993 Volume 6 : Issue 13 Today's Topics: Re: on the definition of virus Re:Viral Code Access [Yaron .. Goland] Re: Heuristic Scanners Re: Internet Worm Functions - part 2 (CVP) Re: How to measure polymorphism Re: What is a virus ? Re: Good use of (possible bad) viruses [V-L v6 #3] Measuring polymorphism protecting the checksum file Re: Infection question (was: Viral Based Distribution System) Re: on the definition of virus Thanks to Symantec (PC) False Alarms (was: Cansu...) (PC) Any know virus/trojan with the following results? (PC) V-Sign on printer diskettes (PC) Re: Virus Simulator MtE (PC) 696 Virus? (PC) Possible new virus: Dudley! (PC) Stoned_NSW; New boot sector virus (PC) 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: Thu, 21 Jan 93 00:10:23 -0500 From: fc@turing.duq.edu (Fred Cohen) Subject: Re: on the definition of virus I am gratified at the wonderful discussions going on about definitions of the term virus. Two particular writers were especially lucid, and I thought I would respond to them - even though I cannot include their postings in my response due to circumstances beyond my immediate control. The linguistic definition could use some work. Part of the problem is that the mathematical definition of a virus is `a member of a viral set'. So what is a viral set? Well - you might try reading `Computer Viruses' for the real details, but I'll try anyway. The real equation (taken from that text) is (in abbreviated form): M v ===> V which means (loosely) that any virus v which is a member of the viral set V for machine M, when run on machine M, writes a, possibly different element of V somewhere else on the Turing machine tape at a subsequent time. This definition makes `evolution' an inherent part of the virus definition. Another way of stating this is: (M,v) => (M,V) As to `worms' being a subset of `viruses', I agree. In fact, I recently published a journal article with a formal definition of worms. In this definition, worms are a subset of viruses, and several properties of worms were shown. I am not certain that my definition captured the meaning that is commonly held for worms, but in essence, it called a worm a virus where at least one of the replicas is guaranteed to `run' after it is written. This leads to all sorts of things, but perhaps I should see your definitions. The idea of partial viruses is indeed covered by restrictions on the environment - but perhaps this leads to interesting classification schemes. Many viruses run on a very large number of different M, but perhaps we can look for the necessary and sufficient conditions on M and use that to classify the viruses. One of the side effects of the mathematical definition leads us to the issue of polymorphism. Without debating the definition of that term, it seems sensible from a mathematical view to classify viral sets in terms of their sizes and perhaps other things of interest. Singleton sets are obviously not polymorphic. Finite sized sets with a few billion varieties might be classified in terms of the complexity required by an algorithm to detect members of the set. A viral set of which any member can be detected with a polynomial time algorithm is easily classified. This also leads rather directly to the figure most people are interested in - scanning time. Most current polymorphic viruses are probably constant time - and the rest are almost certainly sub-linear. For larger sets (i.e. potentially infinite sets), we can use other measures of complexity. You might read one of my recent papers in Computers and Security that (very weakly) classifies some evolutionary techniques in terms of complexity. Mathematical definitions have their advantages, but one of their (dis?)advantages is that you have to think about all of these issues BEFORE you have an even marginal mathematical definition. One of the issues that I had to think about was how to differentiate programs from other information using Turing's model of computers. Of course I could not because there is no difference. Information only has meaning in that it is interpreted - and on a Turing machine, there are potentially infinite numbers of different interpretation mechanisms. This is one of the reasons that the definition encompasses so-called companion viruses, boot sector viruses, et. al. A good mathematical definition should serve you well for a very long time - at least a few thousand years! For the reader interested in even more of this stuf, I have written several books on the subject. For additional information, you might FAX me. Which reminds me - I am just finishing a new book you might be interested in titled: It's Alive!!! Those who object to revealing the source code of viruses will probably not want to read it - it shows some viruses written in `Life' and RedCode! __________________________________________________________________________ 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: Thu, 21 Jan 93 18:37:19 +0100 From: brunnstein@rz.informatik.uni-hamburg.dbp.de Subject: Re:Viral Code Access [Yaron .. Goland] Yaron (The Jester) Goland complains that some institution which he asked for virus code was not willing to send any; he moreover asks whether "..this (is) 'open and free exchange of information' ". As a university teacher and researcher, I absolutely believe in "Free Exchange of Information", and I have often given arguments against principles of "Secur- ity by Obscurity". We follow FEI principles as long as no serious obstacles request less-open, more-restrictive policies. Virus Test Center of the Faculty for Informatics of Hamburg University has therefore always been open to inform users about potential damage (see Computer Virus Catalog) and related problems. Regarding the *transfer of malicious code*, there are restrictions which also a university lab must observe. In German law (Penal Code), it is a crime "to endanger a dataprocessing unit which is essential for the work for an enterprise, as state agency or any individuum". It is also a crime to attempt such damage, as it is a crime to assist in the attempt or in the establishment of a damage. Though there have not been much court cases here (I contributed expertise in few cases myself), we must assume that installation of a virus,willingly or unknowingly, may constitute such a crime ("Computer Sabotage", section 303b, German Penal Code). If a virus infection would follow from any virus-infected medium which originates from VTC, we may be prosecuted for assistance. Though I have only referred to German law, legislation in other countries either exists or is being developped which directly or indirectly adresses virus infections as a "illegal activity" (not to use the term "crime" here). In this situation, even university people must reduce the degrees of freedom in the "free flow of information". In order NOT to reduce this to ZERO, we have agreed that we understand the situation as follows: if a person whom we know as trustworthy (=on whose ability to avoid damages to other systems we can rely), then we may transfer to her/him viruses as no offense against a legal code may result with sufficient probability; also in such cases, we apply proper safety measures, such as encryption. In this context and in rare cases, VTC has helped people to improve the quality of methods (we have regarded this as our duty to protect the broad user community from inadequate AV behaviour). Sorry for vasting the bandwidth, but the community has any right to know why even university people believing in "Free Flow of Information" sometimes have to restrict access. Klaus Brunnstein, University of Hamburg, Germany (January 8, 1993) PS: within the International Federation for Information Processing (IFIP), there is one Working Group (WG 9.6) which works on Harmonization of Computer Crime Legislation (including virus problems). There will be a 1st conference in August 1993, on a ship plying between Stockholm and St.Petersburg. Information available from me. ------------------------------ Date: Thu, 21 Jan 93 18:15:22 +0000 From: antkow@sis.uucp (Chris Antkow) Subject: Re: Heuristic Scanners >Yeah...thanks.... > >Anybody who knows anything at all about heuristic scanning (like myself) >is almost certainly not interested in helping you - after all, the only >people that could benefit from the software you might develop would be >virus authors. ...or anyone who wants to develop a better heuristic scanner! Gee you're paranoid... Chris antkow@eclipse.sheridanc.on.ca ------------------------------ Date: Fri, 22 Jan 93 11:43:24 +0000 From: cowboy@trans.csuohio.edu (Joe Rosenfeld) Subject: Re: Internet Worm Functions - part 2 (CVP) Olivier MJ Crepin-Leblond (o.crepin-leblond@ic.ac.uk) wrote: : >Date: Thu, 07 Jan 93 16:51:07 -0800 : >From: rslade@sfu.ca : [...] : [...stuff deleted...] : : The worm used to check if it had already infected the remote computer : and if it indeed had, then it would not infect it again. However, in : order to curb any attempt by system managers to "inoculate their : machine by running a similar process", each after each 10 : interrogations, a machine would return a negative answer, thus letting : the worm re-infect it. RTM's BIG mistake was that number. He greatly : underestimated the speed of the internet. For a lower probability of : detection of his worm, he would have had to use a number at least 100 : times bigger ! : When he came back from a break after having released the worm, the : internet had been brought to a near standstill. Anyone know whatever happened to RTM? I read _Cyberpunk_ which was very interesting, and despite the woes he unleashed onto the internet and all of us, I more or less felt sorry for him Regards- Joe | Joe Rosenfeld cowboy@trans.csuohio.edu | CSU Law Library joer@inca.law.csuohio.edu | "We look for things ... to make us go!" ------------------------------ Date: Fri, 22 Jan 93 11:15:27 -0500 From: "David M. Chess" Subject: Re: How to measure polymorphism > From: ncoast!arnold@usenet.INS.CWRU.Edu >ncase You Have Not Tried It TPE 1.1 Is Very Very Good..I have not >Found a Pattern That Can be scanned with a simply Wild Card Scanner >Yet..I think it is better than MTE..And I believe it is totaly >Polymorphic.. I suppose we all have our own definitions of "good"! *8) We've completely analyzed TPE (1.0-1.3). It's roughly comparable to MtE; simpler in some ways and more complex in others. You won't find a pattern of bytes and wildcards that will reliably detect infected files; like the MtE, it takes an algorithm. Various approaches are possible, but none are as simple as a signature or two. - - -- - David M. Chess For Best Results, High Integrity Computing Lab Consume Before Above Date IBM Watson Research ------------------------------ Date: 22 Jan 93 17:50:34 +0000 From: Sam Wilson Subject: Re: What is a virus ? I'm following up Pagett's posting just because the Subject seems particularly apposite for the following not because I actually want to comment on or add to what he says. In this week's 'Computing' (a UK weekly trade paper, and usually fairly well informed) is an article, reproduced below without any permission at all. It seems as though people may now be writing 'cause: probable virus' in operations reports instead of 'cause: unknown'. Also the headline and summary seem to bear little relation to the actual text - the report cited may be a lot more sensible than this rather misleading (so far as I can tell) article. Sam Wilson Network Services Division Computing Services, The University of Edinburgh Edinburgh, Scotland, UK - ----------------------------------------------- Mainframes hit by epidemic of viruses ===================================== Mainframe systems are more at risk from viruses than from any other form of computer disaster. - ------------------------------------------------------------------------ Users across Europe and North America have reported an alarming increase in the frequency of virus attacks. And, according to research carried out by UK analyst Xephon, viruses accounted for over half of all computer diasters last year. A survey of 816 European and North American mainframe sites showed that 35.5% of users had reported disasters, 60% of which had been due to viruses. The figures, published last month, show a marked increase on 1991, when viruses accounted for 44% of disasters. In 1990 the figure was just 23%. 'Although the number of virus attacks has increased sharply since 1990, the number of incidents of hacking has remained relatively constant. It seems the antisocial element in the computer fraternity now favours the use of viruses, which incur little risk of detection and little expense,' Xephon said. Fault-tolerant computer manufacturer Tandem suffered an embarrassing set-back last year when many of the its sytems were brought to a halt by a software bug. A Tandem spokesman said the bug was probably caused by a virus. Crime proved the most costly disaster in the Xephon sample, followed by fire and viruses. However, the average cost to victims of viruses halved last year, indicating that users had become more adept at dealing with them. For example, British Airways armed 90 field engineers with anti-virus disks last November to run health checks on its 9,000 PCs in preparation for a possible Friday the 13th virus ('Computing,' 12 November). The average cost of a disaster in 1992 was $17,800 (pounds sterling 11,560), a little over half the 1991 figure. IBM's VM operating system chalked up the biggest tally of disasters, proving especially prone to hacking. The breakdown by region showed the UK to be the most disaster-prone, being particularly subject to flooding and hacking. ------------------------------ Date: Fri, 22 Jan 93 14:16:41 -0500 From: "Tom Zmudzinski" Subject: Re: Good use of (possible bad) viruses [V-L v6 #3] In V-L v6 #3, Suzana Stojakovic-Celustka (celustka@sun.felk.cvut.cs) says: > [...] If such virus *by > accident* escape from my lab I already have a response and there is no > ethical problem at all. WRONGAMUNGO! While this could be argued at great length [somewhere else], let's cut to the chase: even if your planned response is 100% safe, effective, universally available and free [fat chance!], you would still have to "make whole" the victims of your *accidental* escapee. Otherwise you will have done damage (regardless of degree) to persons who did not accept (co-)responsibility for your actions. > [...] There is slight similarity in this > idea with reaction of human immunity system. Anyone has ethical > problem with her/his own immunity system ? The question sets up a meaningless strawman. One of the definitions of "ethical" is "conforming to accepted and esp. professional standards of conduct". Setting theology aside, the human immunity system wasn't designed by a person so there are can be no standards of conduct and thus, no ethics. Now if you want to talk [again, somewhere else] about MODIFYING the human immunity system, you can (and must) get into ethics. Tom Zmudzinski Internet: ZmudzinT@CC.IMS.DISA.MIL Disclaimer: Well, what do you expect from a Global Village Idiot? ------------------------------ Date: Fri, 22 Jan 93 19:07:05 -0500 From: Jerry Leichter Subject: Measuring polymorphism Before defining "polymorphism", I suggest it's important to decide WHY we want a definition. What property of "highly polymorphic" viruses are we trying to capture? I'll suggest two very different definitions that illustrate why this is an essential first step. 1. Polymorphic viruses can appear in many different forms; the more possible forms, the more polymorphic the virus. Of course, these allows for trivial polymorphism: Any virus can be made highly polymorphic by simply appending 16 random bits to it. So, we could try saying, well, the virus is K bits long, let's look at the fraction of all possible K-bit strings that the virus could appear as. Unfortunately, this fraction can be made to take on any value you like by adding a lot of random bits, or a lot of fixed but irrelevant bits. The next step is to ignore the "irrelevent" bits. For example, define the kernel of a program to be those bits in the program text which can actually be executed as code in some execution of the program (for all possible inputs, such as values of the date/time). Computing this is very nontrivial in general, though in most particular cases it's fairly easy. If we then measure either the number of bits in the kernel of a virus, or the density of the kernel among all possible bit strings of the appropriate length, we will have a measure that at least says something about the program, rather than about noise. One interesting property of this definition is that it ignores text strings, which is probably appropriate. Then again, if the question you want your "polymorphism" measure to answer is "In how many distinct ways can the virus APPEAR to an end user", then every different set of displayed text strings presents a different appearance. 2. The only reason that polymorphism was introduced by virus writers is to make life hard for virus scanners. Definition 1 is purely "intrinsic": It looks at the virus itself, not how it interacts with scanners. Suppose we wanted to capture the notion that a virus was "hard to scan for". It's easy enough to look at how hard it is for particular existing scanners to find it, but that gives you a poor definition; what we really want to capture is the notion that highly polymorphic viruses make life hard for ANY POSSIBLE scanner. It turns out there is a notion in the theory of computation which can be used to get at this idea; in mentioning randomness, Declan Malone started out on the right path. Kolmogorov-Chaitin complexity theory (I'll just call it KC from now on) defines a way to measure the complexity of a string of symbols. The idea is really simple: The complexity (or, equivalently, randomness) is defined as the length of the shortest program that will produce the particular string as its output. In KC theory, we don't care how long the program will take to produce the output, or how much scratch space it uses; we care only about the length of the program. Of course, to have a notion of "length", we have to settle on a machine model first. In K-C theory, you choose a universal Turing machine, and provide it with a program on its input tape; the length of the machine description is the length of the program. While different universal TM's may give you different lengths, it turns out that this has no significant effect on the resulting measure, except for a finite number of special cases. (You can hard-code some strings into your TM, but only finitely many.) I suggest that the polymorphism of a virus be similarly measured as the length of the shortest program (with respect to any fixed universal TM) which can reliably detect the virus in all its forms, without error. As a purely mathematical definition, I think that's what we really have in mind under the notion of "hard for a scanner to detect". As a PRACTICAL measure, however, it's pretty useless. First of all, it's impractial to compute it. Beyond that, "length of program" is not the only significant measure. If a short program can detect a virus, but it requires huge amounts of time to do so, that program will not make a useful detector. On the other hand, a quite large, but fast table-driven program might be very practical. Or one might want to relax the requirement of "total correctness" and allow some small fraction of false positives (or, in some circumstances, even of false negatives). Such changes could lead to a very different measure of the polymorphism of some viruses - though I have no idea whether for practical polymorphic viruses it would really make much diffference. BTW, it would be nice if there were KC theory that looked not just at program length but also, say, at running time. Unfortunately, if you add such additional measures, the mathematics of KC theory breaks down, and the resulting measure is no longer independent of the details of the model in any useful way. That doesn't mean that one can't find a PRACTICAL KC-like measure with respect to some particular set of models and measures, though. -- Jerry ------------------------------ Date: Fri, 22 Jan 93 21:13:12 -0500 From: fc@turing.duq.edu (Fred Cohen) Subject: protecting the checksum file Bontechev 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: > ... >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)... The point I was trying to make is that access controls can stop the corruption of the checksum file and prevent users from examining or modifying the integrity key used to generate checksums. For these functions, we can isolate the integrity maintenance area, as is done in IT, without otherwise impacting operations. > >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... > You are right of course - so against slow viruses, you need additional defenses. Specifically, you need to protect the operating system from participating in the infection - then you can use the techniques described in the Computers and Security Paper which defined integrity shells. Somewhere in there, there was a `one process at a time assumption' - watch out for it - it's a bit tricky. .. AND on the definition of viruses: > >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? It is not a virus - because, to be a virus, the replica must also replicate in the environment - as must it's replicas, etc., ad-infinitum. All of the replicas (as described above) are on the `A:' drive. When you the run `Xcopy Xcopy.Exe A:' from the A: drive to get the replica to replicate, I don't think it will work right (i.e. make an additional copy at a different place on the A: disk) - although I haven't tested it. Furthermore, to call Xcopy a virus in this environment, it must ONLY be used in this way - the alternative uses mean that it does not ALWAYS replicate. I have no doubt that you can eventually find an environment where Xcopy is a virus because it has the capability of replication - given a proper environment. Consider now the difference between your example with Xcopy and my example with backups. Backup programs are rarely used for more than one function (i.e. backups - there's usually a separate program for restores). The defaults for backups usually include the backup program in the copy. Backups done to network drives are on-line and can be run easily from the backup media. Backups typically overwrite previous information as they are created - so they are dangerous. Thus, we have a replicating program that has a large class of available environments in which it operates. Consider this from the standpoint of what we commonly see in malicious viruses. Most malicious viruses are written to operate in a very large portion of the existing environments (e.g. all DOS machines, all PC's with similar BIOS's, all MacIntosh's, etc.). Viruses that only operate in a limited number of systems are commonly called `buggy' by the virus defense industry. The Internet virus was directed to spread only in a particular subset of the Unix machines it entered. But perhaps these viruses are just directed at a finer subset of the available machines. Nowadays, a virus writer may be more successful by writing a virus that infects fewer machines (particularly types of machines that the defenders don't have lying around), because fewer defenders will bother looking for viruses that don't work in their machines. Imagine a very well designed slowly mutating virus that doesn't replicate in your machine until the 100,000the replica. You will likely not even call it a virus, and you may not want to bother figuring out how to detect all of the mutations. Many people may never bother to scan for it. Now suppose it has no obvious side effects for 18 months. It may spread throughout the world mutating slowly, and be a pandemic before anyone ever takes it seriously. Now consider how to make safe viruses for benevolent purposes. All you have to do is make the environments in which they are viral suifficiently restricted, and they are no threat to other environments. For example, have them replicate with a system call that requires that a `Viral Computing Environment' be installed. This is what is done when we use the computer simulation called Life, or Core War, and this is how I make most of my benevolent viruses safe. You don't seem to object to Dawkins's evolutionary environment that runs on a MacIntosh. These are not only viruses, but are intended to explore the nature of evolution in biological systems. You wouldn't want them spreading all over the world, but you should be happy to see them in systems where the user installs the proper environment. ------------------------------ Date: Sat, 23 Jan 93 00:08:46 -0500 From: hutchinson@wrair-emh1.army.mil Subject: Re: Infection question (was: Viral Based Distribution System) bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) writes: > 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 Then maybe "program" is the wrong word. Maybe it should be something like "function" or "process" instead. F'rinstance, a boot sector infector doesn't exactly attach itself to any program. But it *does* attach itself to the boot *Process*. > 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. I've been thinking about this one lately. Is there a really good reason why worms must be considered entirely separate? I think the distinction is based not so much on the definition of a virus, but on a popular notion of what a virus is (or was). A few years ago the difference was fairly clear because our notion of a virus was relatively limited. But some of these newfangled viruses are changing that notion somewhat. These days, we speak of, i.e., companion "viruses", even though they are completely different beasts than the viruses of yore. Why, then, aren't worms considered just another type of virus? -Hutch - -------------------------------------- Bob Hutchinson Walter Reed Army Institute of Research (hutchinson@wrair-emh1.army.mil) ------------------------------ Date: Sat, 23 Jan 93 00:08:58 -0500 From: hutchinson@wrair-emh1.army.mil Subject: Re: on the definition of virus fc@turing.duq.edu (Fred Cohen) writes: > 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! [Much more deleted than I think I should've had to...] > Maybe Solomon's product is very good - but his definition isn't. Then allow me to make a minor adjustment: `A program CAPABLE of replicating without the users awareness and cooperation'. Would that sit any better? -Hutch - -------------------------------------- Bob Hutchinson Walter Reed Army Institute of Research (hutchinson@wrair-emh1.army.mil) ------------------------------ Date: Thu, 21 Jan 93 12:55:51 +0000 From: Paul.Gronke@lambada.oit.unc.edu (Paul Gronke) Subject: Thanks to Symantec (PC) Just wanted to note that Symantec Tech Support sent me a uuencoded file with updates to NAV 2.0 virus definitions. (Thanks to the other user who sent one along as well). Thanks for responsive tech support, Symantec. - -- The opinions expressed are not necessarily those of the University of North Carolina at Chapel Hill, the Campus Office for Information Technology, or the Experimental Bulletin Board Service. internet: laUNChpad.unc.edu or 152.2.22.80 ------------------------------ Date: Thu, 21 Jan 93 13:46:43 +0000 From: gerald@vmars.tuwien.ac.at (Gerald Pfeifer (Prak Gusti)) Subject: False Alarms (was: Cansu...) (PC) ianst@qdpii.comp.qdpi.oz.au (Ian Staples) writes: >Does anyone *know* how this virus works? If you simply read the >directory of an infected floppy and then run McAfee's SCAN (version >99), you will get a warning "Virus active in memory" - which sure >scares folk! Well, both McAfee Scan (99) and Frisk's F-Prot (2.06 or 2.06a) suffer from this problem, while TBAV (TBScan 5.0x) does not. REASON: If you issue a DIR for a floppy disk, that floppy's boot sector - -in this case containing a virus- is read into one of DOS' (sector) buffers. These buffers reside in memory, scanners scan memory -> False Alert. SOLUTION: Please McAfee, Frisk,... scan these buffers only for viruses known to install themselves there (when active!)! Hope I put it right, no flaming please! Gerald PS: F-Prot's warning message, however, is less scaring and per se correct, as it just says "signature of ... found in memory" (or similar), not "Virus active in memory". But it does also say "power down" (or similar) what is of no use in this case! ........................................................................... . Gerald Pfeifer (Jerry) Technical University Vienna, Austria . . gerald@kongo.vmars.tuwien.ac.at Home: Mondweg 64, 1140 Wien, Austria . ........................................................................... . Sorry, I'm not a native speaker (flames to /dev/null) . ........................................................................... ------------------------------ Date: 21 Jan 93 18:24:30 +0000 From: leoh@hardy.hdw.csd.harris.com (Leo Hinds) Subject: Any know virus/trojan with the following results? (PC) I have 3 PC's (two at home & 1 at work) and all three have developed similar symptoms & I was wondering if it was a coincidence or the act of some malignant code: Power on - (use vshield 99) nothing reported Access floppy a couple of times - no problem access floppy (either drive) with something like xcopy that re-reads multiple times to read all the data & the initial access is fine, but when it comes back for the second time, it complains that there is no floppy in the drive. On one machine the floppy is accessible via DOS, but windows believes there is no disk in the drive. Any thoughts? - -- leoh@hdw.csd.harris.com Leo Hinds (305)973-5229 Gfx ... gfx ... :-) whfg orpnhfr V "ebg"grq zl fvtangher svyr lbh guvax V nz n creireg ?!!!!!!? ... znlor arkg gvzr ------------------------------ Date: Thu, 21 Jan 93 18:36:52 +0100 From: brunnstein@rz.informatik.uni-hamburg.dbp.de Subject: V-Sign on printer diskettes (PC) Shortly before Christmas, Virus Test Center of Hamburg University and MicroBIT Virus Center of Karlsruhe Technical University were asked to assist in the analysis of 4 diskettes (out of 6) which FUJITSU Germany distributed to customers with boot sectors infected with V-Sign virus (called CANSU by McAfee's SCAN). It was verified that 4 diskettes were infected with V-Sign which is "mildly polymorphic": the "oligomorphic" part is 38 bytes long, with 3 MOV instructions being circularly rotated and 2 other instructions interchanged, thus resulting in n=6 different generations. Depending on some mask (value=1F implying 32 repetitions, value=3F implying 64 repetitions), "Victory" sign will appear on the screen (for details: see Computer Virus Catalog entry in next CVC edition). While the first 3 diskettes were infected on an English MSDOS 3.3 system, the 4th diskette was infected on some German MSDOS 5.00 system. The diskettes were infected while in drive B:. Fortunately, there is a bug in the virus. Due to this bug, all diskettes infected in drive B: are trying to load the second part of the virus body from that drive. Therefore, the only way to become infected by such a diskette is to have two infected diskettes WITH THE SAME DENSITY in both drives A: and B: and accidentally try to boot the computer. If there is no other infected diskette in drive B: (or if it is not the same kind of diskette), the virus will hang the machine, without infecting the hard disk. All the 4 infected diskettes distributed by Fujitsu have been infected in drive B:... Following strong "suggestions" of the German Information Security Agency, GISA, Fujitsu warned its customers, and it sent a press release to some media. This press release was prepared by some marketing people who said that "the virus which sits of these diskettes and which can only be detected with the most recent antivirus programs, was inactivated with expensive security methods": this is the first bug which I have seen cited as "security method"! Klaus Brunnstein (VTC, Univ Hamburg, January 11, 1993) ------------------------------ Date: Wed, 20 Jan 93 20:38:33 -0500 From: as194@cleveland.Freenet.Edu (Doren Rosenthal) Subject: Re: Virus Simulator MtE (PC) E-mail as@cleveland.freenet.edu (Doren Rosenthal) Doren Rosenthal voice Phone 1 805 541-0910 Rosenthal Engineering 3737 Sequoia San Luis Obispo, CA USA 93401 A new Virus Simulator supplement, to be used as a training aid that enables users to better understand and protect themselves from computer viruses, is currently under development. This new Virus Simulator supplement is expected to receive wide distribution in government, business, industry and education. Producers of anti-virus products, publications or services are encouraged to please contact me. Comments and constructive criticism would be greatly appreciated. Thank you Doren Rosenthal ------------------------------ Date: Thu, 21 Jan 93 19:36:29 +0000 From: mark@walt.CS.MsState.Edu (Mark Rauschkolb) Subject: 696 Virus? (PC) 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. He said that when he ran clean on his PC, it ran for a while, then told him to turn off the system. (He didn't know if it gave a reason why, he just turned it off and left it off) Any hints? Thanks Mark Rauschkolb mark@cs.msstate.edu ------------------------------ Date: 22 Jan 93 04:10:43 +0000 From: j.laidman@cowan.edu.au (Jeremy Laidman) Subject: Possible new virus: Dudley! (PC) We've been given an infected program from an infected site. Scan v99 and F-Prot v2.06a miss the virus. This virus infects COM and EXE programs differently each time, with a file size increase of around 1200 bytes. The first three hundred bytes of the loader code decrypt the code following, for a count of 481h bytes. In the decoded virus one can see the string "<[Oi Dudley!][PuKE]>" which can be used to find it in memory. McAfee's scan can be given the following signatures to find it: # Dudley string: <[Oi Dudley!][PuKE]> "3C 5B 4F 69 20 44 75 64 6C 65 79 21 5D 5B 50 75 4B 45 5D 3E" Dudley-Unencrypte d # Encrypted Dudley - decryption code "B9 81 04 *(30) 31 *(30) FE C0 *(30) FE CC *(20) E2" Dudley-Encrypted The virus hooks INT 21h, checking for functions 5454 (for self detection), 4B00, 3D, 56 and 6C (all hex). After the first infected program is executed, the virus decreases the size of the free memory block by 1200h bytes (exactly), where it puts itself (in the last 1200h bytes of 640k). It attempts to infect COMSPEC, whatever it points to. From here, it infects every program that is executed or copied. To avoid signature detection the decryption code is sprinkled liberally with various code sequences that effectively do nothing, such as JO $+2. If this is a new virus, I'd be grateful to find out who's being infected. Cheers - --------------------------------------------------------------------- Jeremy Laidman, Analyst Programmer School of I.T. and Mathematics Phone: (61 9) 370 6648 Edith Cowan University Fax: (61 9) 370 2910 Perth, Western Australia j.laidman@cowan.edu.au ------------------------------ Date: Fri, 22 Jan 93 02:35:12 -0500 From: "Roger Riordan" Subject: Stoned_NSW; New boot sector virus (PC) We have just received samples of a new boot sector virus from two sites in NSW. The virus itself is very unremarkable; it has no messages, and no warhead. However it is likely to cause considerable alarm, as it is identified by Scan 8.9V97 as "ExeBug". ExeBug rewrites the CMOS RAM, with the intention of preventing you from booting from a clean disk, and may be able to achieve this on some PCs. Thus it is potentially very serious, and it is unfortunate that this relatively trivial virus is identified as it. F-Prot 2.06a reports "Possibly a new varient of Stoned" Dr. Solomon's Toolkit 6.07 (19/11/92) does not find it. Unlike Stoned, the virus starts with a relative jump. The MBR is saved at sect 7, and floppy boot sectors are saved at head 1, sect 3 or 14, depending on size. It is stealth, and will divert any attempt to read or write the boot sector to the good copy. The virus can be found with the signature: A1 13 04 B1 06 48 A3 13 04 D3 E0 8E C0 A3 86 7C at offset 5B in the boot sector. We have tentatively named this virus Stoned_NSW. VET 7.114, released today, will detect it in memory and disable it, and will remove it from infected floppies & hard disks. Roger Riordan Author of the VET Anti-Viral Software. riordan.cybec@tmxmelb.mhs.oz.au CYBEC Pty Ltd. Tel: +613 521 0655 PO Box 205, Hampton Vic 3188 AUSTRALIA Fax: +613 521 0727 ------------------------------ Date: Fri, 22 Jan 93 16:40:10 -0500 From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) Subject: False positives, disk buffers, and IO.SYS (PC) >From: ianst@qdpii.comp.qdpi.oz.au (Ian Staples) >Subject: Cansu virus plague! (PC) >An outbreak of the Cansu virus (boot sector) was discovered at >one of this organisation's centres today. It apparently had >been around for awhile and was really only discovered because it >(or something else, fortuitously?) was interfering with 32-bit >disk access under Windows 3.1 on one machine. 32BitDiskAccess does provide a good warning of *any* program which is intercepting disk access at the BIOS level (viruses, access control programs, disk compression routines). The reason is that MS-DOS at present requires the PC to be in "real" mode to be used for disk access. Since switching from "protected" to "real" and back is a time consuming process, Windows 3.1 gains a significant improvement to its speed (or reduction of the lack thereof) by using its own "protected" mode routine (32Bit...) when possible. To do so, Windows makes a number of checks to determine exactly what the disk access method is and posts a warning when confused. Since the default installation is "32BitDiskAccess=FALSE", few people have encountered this. >Does anyone *know* how this virus works? If you simply read the >directory of an infected floppy and then run McAfee's SCAN >(version 99), you will get a warning "Virus active in memory" - >which sure scares folk! I have been running some tests on this effect and there seems to be certain criteria: When DOS 5.0 accesses a disk, two things happen: 1) The Boot Record (logical sector 0 of the partition or floppy) is read into memory at a location contained within the resident portion of IO.SYS (IBMIO.COM) in segment 0. Since this is overwritten every time a disk is changed current viruses cannot use this space for residency. However, if the disk had an infected boot record, this code is now in the this buffer. 2) On access, the root directory is read into the disk buffers. How many sectors are read seems to depend at least partially on how many buffers DOS has allocated. If DOS 5.0 is loaded "high" one of the things that DOS tries to put in the High Memory Area (segment FFFF) are the disk buffers. Note that this only happens if *DOS* accesses a disk (e.g. with a DIR) just changing the default does not seem to trigger a read. Further, if the disk is read by some other driver (Disk compression routine e.g. SuperStor, removable media driver such as for a Bernoulli, DMDRIVER) then the last DOS access remains in the buffer. (This caused me some confusion at the beginning since my test machine has SuperStor partitions and I only observed floppy DBRs in the buffer despite intervening C: & D: access). 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. 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. 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. 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 ? Warmly, Padgett ------------------------------ End of VIRUS-L Digest [Volume 6 Issue 13] *****************************************