VIRUS-L Digest Monday, 23 Sep 1991 Volume 4 : Issue 170 Today's Topics: precise identifications software approaches Re: Disinfectant and students (Mac) Encryptors and experience Theory and practice Boot selection (PC) Brain Virus (PC) False positives Precise identification Looking for information Re: FAT Infection (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. Please sign submissions with your real name. Send contributions to VIRUS-L@IBM1.CC.LEHIGH.EDU (that's equivalent to VIRUS-L at LEHIIBM1 for you BITNET folks). Information on accessing anti-virus, documentation, and back-issue archives is distributed periodically on the list. Administrative mail (comments, suggestions, and so forth) should be sent to me at: krvw@CERT.SEI.CMU.EDU. Ken van Wyk ---------------------------------------------------------------------- Date: Fri, 20 Sep 91 22:16:44 -0700 >From: turtle@darkside.com (Fred Waller) Subject: precise identifications In an earlier article, I wrote about the Rosenthal Virus Simulator and while on the subject, commented on the methods used by the antivirus publishers, as follows: "I often wonder if we shouldn't credit the virus-naming penchant of antivirus publishers (and the attendant publicity), as well as the quest for "precise identification", with being at least partially responsible for the extraordinary proliferation of new viruses, and the concomitant increase in virus incidents worldwide. I'm not referring to any possible collusion, or virus-production, by anti- virus entities, but to the obvious invitation that "orthodox" virus authors must feel to rise to the challenge and produce new creations that could trick a given scanner, if only ephemerally." Apparently slighted by this conclusion, Vesselin Vladimirov Bonthchev wrote in reply: > The above is just an unfounded flame against the anti-virus > researchers, so I won't bother to comment it. But the above conclusion is not strictly mine. It has been expressed many times before. Many writers have publicly questioned the wisdom of giving such intense publicity to computer viruses as the scanners provide by reason of their design, and to the use of colorful epithets that love to dwell on mythical, satanic and pathological meanings. As an example of such objections, none other than Dr. Solomon, author of the well-known Dr. Solomon's Antivirus Toolkit, objected so much to this habit that at one time he refused to recognize any virus programs except by its byte length. The IBM corporation, surely not one to carry "unfounded flames against the anti-virus researchers", proposed to do the same thing. Many people have expressed the concern that all this "identification" the colorful naming, and the attendant publicity, were bound to challenge virus authors to produce ever-cleverer, ever-subtler viruses in quest of pathological glory. Well, it seems to have caused exactly that! > I'll contend myself only to mention that each science begins with > defining the proper terms, naming, and classification. The fact > that even this is not yet accomplished in the field of computer > viruses, only means that the computer virology is a very young > science. It is very hard to swallow this "computer virology". There is, of course, no such "science", nor is there any need of such. Computer viruses are one minor class of computer programs, and their study falls well within the field of computer science. Programming computers is an engineering task, and an art, not a scientific investigation. Its fundamentals will be found in the science of mathematics and in considerations of physics. There is no research involved - every single CPU instruction found in a virus program has been long known to the designers of the microcircuits and of the OS. No "discoveries" are needed. No "research". One can get the same information by writing a letter to Microsoft, assuming they agree to tell you. But let's not fool ourselves (or others) into thinking we are conducting "research" into some unknown natural phenomenon. Viruses share most characteristics with conventional, non-replicating programs, and can be fully and completely studied in that context. In fact, at the most elementary level, it's impossible to separate virus programs from non-virus programs. Carrying the idea further, I quote F. Cohen (1990): "Please note that the 'DISKCOPY' program is a virus in the mathematical sense"(*). Some commercial programs have now started to implement viral techniques for "good" purposes, and are doing it quite well. All this, in turn, demonstrates the fallacy of wanting to create a separate "science" for the study of viruses. Let us not confuse the commercial aims of antivirus software producers with the goals of scientific research. There is no "research" involved, only software publishing, of an admittedly useful and practical kind. I think we need a "computer virology" as much as we need a "computer wordprocessology" or a "computer filecompressology". --------------------------- (*) Cohen, F., Letters, Virus Bulletin, May, 1990. (p.7) ------------------------------ Date: Fri, 20 Sep 91 22:14:24 -0700 >From: turtle@darkside.com (Fred Waller) Subject: software approaches Regarding the Virus Simulator by Rosenthal Engineering, and in answer to the following earlier comments in my article : "Perhaps the best way to solve it is to move away from string scanning as a viral "detection" technique. The assumption that, in order to *stop* a virus one needs to *identify* it is, in my view, an incorrect assumption." writes bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev): > Why? There are other ways to stop a virus, agreed, but none of > them is universal (except of turning your computer off, of > course). Neither is the scanning approach, but nobody claimed > that. Vesselin Vladimirov writes this, yet he knows that all virus scanners make it a prominent point of announcing many (useless) hundreds of viruses they can "detect", with the obvious intention of impressing the public into (debatable) confidence. He also neglects to take into account the fact that well-known hardware approaches, such as recently described by Padgett Peterson here (posting of 16 Sept 91 on `Interesting Laptop config') provide a much more effective means of protection than software. By definition, software cannot defeat software. All it takes is the next generation of viruses, and the antivirus programs must be updated. And all it takes is the next generation of antiviruses, and the *viruses* must be updated! Certainly, both virus and antivirus combatants have demonstrated tenacity and skill in updating and improving their respective creations. In practice, what has resulted so far is an endless proliferation of viruses, and a seemingly endless proliferation of antiviruses. The end is nowhere in sight, ever remote... a mirage. But both viruses and antiviruses are thriving. It would be nice if we could say that, after all this time, the antivirus publishers have given us some tangible evidence of usefulness, some material proof that they have contributed to diminish the virus threat. Such evidence is missing. Unfortunately, the reverse is true: since the virus/antivirus utilities have appeared, the number of infections, and the number of viruses have both increased dramatically. The number of affected machines is higher, not lower. The overall number of virus types is increasing at a mad pace. The incidence of cases around the world is higher, not lower. These facts cannot be ignored. Clearly, the facts show that software approaches are not the way to deal with the problem. They haven't lessened it. There is no indication that they ever will. On the contrary, in spite of all attempts at control by software approaches, the problem gets increasingly worse, worldwide. > Recognizing known viruses is just one of the ways to stop them. Not according to any statistics that anyone can quote. Exactly the opposite is true. Virus "recognition" as practiced by the "scanners" is shown to be a most counterproductive method to deal with a problem. It wins small battles, but loses the big war. It is not a wise application of resources to solve a problem. Further writes Vesselin Vladimirov: > If the scan strings are carefully chosen, they give few false > alarms and detect many future virus modifications. Oh, yes, and > they also get sometimes fooled by Rosenthal's program... :-) Does this mean, then, that IBM's and McAfee's, and Microcom's, and Skulason's and Central Point's and Symantec's and Jim Bate's and Sophos' and TBScan and.... so many other scanners have all had their strings not "carefully chosen", since they are ALL fooled by the Virus Simulator? Should all of them choose their strings more carefully? Would choosing them "more carefully" prevent false alarms (100% in many cases)? No, I don't think so. Show me. Vesselin Vladimirov further quotes me on the Virus Simulator: >> ..(the Simulator)... will make a lot of people aware of the >> inadequacy of string scanning as a virus-detection technique. and responds: > But it doesn't do that! It most certainly does. That's exactly what it does, and it does it rather well. What better demonstration of the inadequacy of string scanning than Rosenthal's Virus Simulator? It proves that virus scanners can be fooled into giving false alarms at the rate of nearly 100%, an incredible figure. ------------------------------ Date: 21 Sep 91 22:39:01 +0000 >From: petechen@romulus.rutgers.edu (Peter Chen) Subject: Re: Disinfectant and students (Mac) I was taking care of the Mac's at a microlab at Rutgers for two years until early this summer. In general, my policy had always been educating the users as much as possible and making them aware of the problems with virus, since I was getting rather annoyed when my machines kept getting infected by the floppies that ignorant users brought in. We ran both SAM and Disinfectant(I wasn't using Disinfectant's Init). I found SAM's automatic floppy scanning useful for most users, even though some people found it intrusive. Whenever, there is a new virus appear, I usually post a message about it on the local newsgroup and put up signs around the lab. This made most of the users more aware of the situation and more willing to cooperate with the consultants. I am not sure whether this is still done after I left the facility; however it did save us a lot of trouble. PeteChen petechen@cs.rutgers.edu ------------------------------ Date: Fri, 20 Sep 91 22:18:58 -0700 >From: turtle@darkside.com (Fred Waller) Subject: Encryptors and experience Writing some comments to an article by Bill Arnold of IBM, (who wrote that he spent considerable time designing degarblers for antivirus scanners), I suggested: > If I were writing such software, I would seldom bother composing > dergablers. Each encrypted virus has its own degarbler built in. > Why not just use that? It usually works rather well... . > Sliding-window encryptors do not respond well, but the rest do. Commenting on several related issues, Vesselin Vladimirov Bontchev apparently misunderstood my meaning and, addressing his posting to me directly, wrote: > You obviously have very little (or no) experience with really > mutating viruses. Well, perhaps I have a little. Still, I'm not sure that one's assumed personal experience is relevant to someone else's judgement of that posting, but so be it. (But again I wonder: is it desirable, or necessary, to dwell on _ad hominem_ approaches here so much. What do they prove?) My comment on Bill Arnold's post was that, in many cases, it's possible to use the virus itself to obtain decrypted code, since the virus is, obviously, the best degarbler for its own encryption. If one simply lets the virus decrypt itself to memory, the memory image is very frequently an excellent, easy source of decrypted code. Not always, and not in every case, but many times. Something similar to what some (including my commentator) do to obtain decrypted scanning strings... But why dwell on personalities, let's look at some facts instead: Vesselin Vladimirov mentions "V2Px", which I take to mean Washburn's viruses, such as V2P2, V2P6, etc. > Viruses with a highly mutating degarbler (like V2Px) cannot > be matched by a simple (or even wild-card) string and require > algorithmic approach. When Washburn's viruses first appeared, everybody simply accepted Washburn's statement that "only an algorithmic approach" could detect such viruses. This view was adopted by the experienced virus analysts, including Vesselin Vladimirov. At the time, all McAfee did was to look for 1260 bytes of added code and, if found, conclude that it was the 1260 virus. Some algorithm. So the 1260 virus did not seem so tough, but the variable-size V2P6s were another matter. Well-regarded antiviral packages, such as F-PROT, have trouble dealing with the V2P6 even today. Well, to make liars of us all (including Vesselin Vladimirov), Wasburn recently posted on McAfee's BBS a full set of search strings, with global characters, to detect the V2P6 virus! True, the strings were many, but there they were... if anyone wants them here, I'd be happy to repost Washburn's message (messages, actually: there was a series of them, each with 12 or so strings). From the horse's mouth, as it were. It's notable that the widely-experienced virus investigators, who claim to be more familiar with the V2Px viruses, the founders of "computer virology", were not themselves able to derive such essential information. So, I apologize for my modest personal experience, and I'm sorry that it makes such a target for those with richer experience, but perhaps these widely-experienced persons might be somewhat more factual -and less personal- in their expressions? Second request. ------------------------------ Date: Sat, 21 Sep 91 22:43:17 -0700 >From: turtle@darkside.com (Fred Waller) Subject: Theory and practice Writes bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev): > Controlled? Why? Frisk's heuristic analyser only warns the user > that a program does something strange. If it did just that I wouldn't have objected. The "heuristic virus analyzer" boldly proclaims: "A BADLY WRITTEN PROGRAM" when it finds something that, in its opinion, is not the way it should be. But -who cares- what any publisher of antiviral utilities thinks, or doesn't think, about what's a "badly-written" and "not-badly- written" program? Should the fact that someone decided one day to publish a virus scanner give him/her the right to pass judgement on what is "good programming" and what is "bad programming"? Why is he entitled to make such comment on someone else's work, written by people who have been writing successful software well before he ever started to compose his own? Instead of a defense, I would have rather expected some sort of an excuse, or apology, for such manners. > Well, when I tried Mark Washburn's program, it just hung my > system, so I stopped using it at all. Well, to be honest, it > was a rather old version - 2.11 or something like that. I have > to try version 2.30 and see if it works. Perhaps reading the .DOC files might have helped. SECURE will -stop the CPU- at the first notice of infection because even a single instruction that's allowed to be executed after an illegal attempt is detected could be enough to give control to the virus. The freezing is intentional, and is the best defense: to -stop- a virus from infecting, -before- it invades a system, rather than allow infection first, then attempt to "scan" it, then attempt to "clean" it, then see if any remnants of the virus were missed, then restore damaged files, then hope to avoid another infection... SECURE eliminates all that. > It is very easy to write a dedicated virus, which will aim > particularly SECURE and disable or circumvent it. > It is even easier than to construct a fake file which causes > SCAN to report false positives. :-) In the final analysis, it's always possible to defeat software with software. However, it's also possible to make reasonable choices as to what is the -best method- for designing protective software. While it's not easy to disable SECURE, it's indeed possible and has been done in the laboratory. In order to do so, one must have the particular issue of the program which one wishes to subvert. You can't write a program to defeat SECURE ahead of time - you can only do so for versions that have been already published. And it doesn't have to be a virus. A demo program was written that allowed the removal of -one- specific version of SECURE from memory. Since SECURE is updated frequently, this provides more than enough security and SECURE is indeed able to stop every known virus from infecting a system. Whether it is or is not possible to design a bypass to SECURE, the important consideration is that, of the currently known viruses, none can bypass it. In practice, it's almost irrelevant whether some "researcher" can design some way to bypass SECURE's protection. Such theoretical bypass is not infecting computers anywhere. It is not a practical threat. If we further consider that there are only 40 or so -actual- viruses spread in the field [and not the 600/900 that some "scanners" purport (what for?) to "detect"], it becomes even more obvious that a program such as SECURE is by far the wiser choice. In an ideal scenario, if every computer in the world were "scanned", infections would still continue because scanners do not prevent spread of infection, they only detect it after it occurs. But if every computer in the world were protected by programs such as SECURE, infections by viruses as we know them today would cease to occur. These are best-case scenarios, of course, and never likely to occur in reality. They do, however, illustrate interesting directions and possibilities. > I have also to test it against some of the most clever > Bulgarian viruses... Well, I don't know. Would these be still unpublished ones? If you have any viruses that can bypass SECURE, you should make a copy of them available to the author, so that he can improve his program and eliminate any loopholes you might have found. If you have found any loopholes. > Just try to use PC Tools or Norton Utilities, without > registering them properly in the database file... :-) The immense majority of computer users do not employ programs designed to edit executables. Those who do, usually have enough knowledge of computers to deal with virus threats in a much more effective manner anyway. > And if you -do- register them and give them the appropriate > rights to modify executable files, a virus which infects them > will gain the same rights. Only to infect -one file-! As soon as *that file* tries to infect another, it will be stopped for good. No more virus spread. No damage to program or data files. No crosslinking of clusters. No scrambling of FATs. No encrypting of hard disk contents. No deletion of valuable files. No loss of data. No further spread to friends or associates. No virus. > I strongly suggest you to read the paper "Computer Viruses - > Theory and Experiments" by Fred Cohen. It explains the very > basic things in computer virology - a knowledge that you > really need to avoid some theoretical traps when dealing with > the computer virus problem. I strongly suggest you read the .DOC files that come with the programs you try to use. :-) Doing so may help you understand the difference between theory and practice. By the way, consider this my third request to ease up on _ad hominem_ comments. ------------------------------ Date: 22 Sep 91 15:32:52 -0400 >From: Jon Freivald <70274.666@CompuServe.COM> Subject: Boot selection (PC) > On arrival, it was certainly a laptop and not a notebook & >requires a diaper bag for transport but had some interesting and >unnannounced features built into the BIOS: > >1) Password boot protection >2) Password keyboard locking while operating >3) Floppy/FD boot selection >4) Partition table validation Zenith computers have had a similar feature (to #3) for years and have recently (last year or so) implemented #1 as well. In general, I dislike Zenith systems, but those features have proven nice in some instances (we have ~70 Zenith machines in our organization...). ------------------------------ Date: 23 Sep 91 00:37:06 +0000 >From: psgrbbc@prism.gatech.edu (Brian Cooper) Subject: Brain Virus (PC) Thanks to all those who responded to my questions regarding the Stoned Virus. I now scan all disks before copying files to my hard drive. I do have another problem; one which I believe is a false alarm. I have been using Central Points Vdefend (comes with PC Tools V7). It is a TSR which is loaded via my autoexec.bat. I have been using McAfee's SCAN for about two weeks with no problems. However, while running SCAN today, I received the message that the Pakastani/Ashar [Brain] virus was found in memory. The message suggested that I power down and boot from a clean floppy and run SCAN to determine the extent of infiltration. I powered down, rebooted from a floppy, and ran SCAN; however, SCAN did not detect any infected files. Being extremely curious as to what was happening. I rebooted from my hard drive and ran SCAN. No virus was detected. I ran a couple of programs and ran SCAN about an hour later. BRAIN virus detected in memory. I removed PC Tools desktop from memory (it was the last TSR loaded) and ran SCAN. BRAIN virus detected in memory. I then removed VDefend from memory and reran SCAN. No Virus was detected! Is it fair to assume that I am getting a false positive as a result of running SCAN while Vdefend is loaded as a TSR? Is the BRAIN virus one which can hide from scanners (in which case I'm in trouble)? Thanks in advance, Brian Cooper - -- Brian Cooper Georgia Institute of Technology, Atlanta Georgia, 30332 uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!psgrbbc Internet: psgrbbc@prism.gatech.edu ------------------------------ Date: Sun, 22 Sep 91 21:04:35 -0700 >From: turtle@darkside.com (Fred Waller) Subject: False positives Writes bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) responding to a post by Ray.Mann@uunet.uu.net (Ray Mann): >> grossly inadequate. By the way, Rosenthal's virus simulator >> seems to have disclosed a real weakness in the area of false >> alarms... > > Of FALSE POSITIVE alarms. These are in no way dangerous and I > really don't see what the discussion is all about. ------------ At least from my end, this discussion is about false positives, about the unreliability of virus scanners and about the Virus Simulator of Rosenthal. False positives are -very- annoying, cause much waste of time and resources and are highly undesirable. Within an organizational environment, false positives are nearly intolerable! The Virus Simulator proves that it's possible to cause the virus scanners to have a 100% false alarm rate. If the Virus Simulator can achieve this, so can malicious software, self-replicating *or not*. The Virus Simulator proves that anyone who wants to do so, can make the virus scanners issue false alarms, as often as he wants to. Therefore, as technical curiosities the virus scanners are very interesting, but as security products they are not useful. ------------------------------ Date: Sun, 22 Sep 91 21:03:29 -0700 >From: turtle@darkside.com (Fred Waller) Subject: Precise identification Writes bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev): >> But why do we need "precise identification"? > > Precise identification is undispensable if your program has to > disinfect the infected media. If it tries to disinfect the wrong > virus variant (even if it differes by only one or two bytes), it > may damage that file beyond repair. ------- If providers of antiviral measures are incompetent enough to allow infection in the first place. But why not *avoid* infection instead, rather than dedicating all our resources to just curing it? Isn't that the reasonable approach? Of course, preventing infection would tend to stop the spread of viruses while curing it does not. The question then is: what is the ultimate goal of the virus scanners: to prevent viruses from spreading or simply to be widely-used but not very efficacious utilities? In the final analysis, no software approach can ever be expected to provide a complete defense. A software attack will defeat it, then the next round will start... _ad infinitum_. There is no end to this sort of thing. Software defenses and software attacks will alternate forever, to the great joy of the antivirus publishers, but to the detriment of users worldwide, large and small. Only hardware/firmware defenses can definitively stop such software attacks. Hardware defenses can be much *less expensive* in the long run, and even in the short run, do not encourage the production of ever-improved viruses and do not need to be frequently upgraded. Hardware defenses stop viruses. Software defenses do not. ------------------------------ Date: Sun, 22 Sep 91 07:50:46 +0700 >From: Hank Nussbacher Subject: Looking for information I am looking for introductory online information about viruses. I remember seeing a list of all viruses, how many there are, how many strains, etc. I am also interested in the history of viruses - when was the first one spotted on a PC, on a Mac, what was its name, which virus is the most deadly, etc. I seem to remember seeing lists of this nature, but that was a year or two ago. Any help would be greatly appreciated. Thanks, Hank Nussbacher ------------------------------ Date: Fri, 20 Sep 91 18:43:09 -0500 >From: Otto Stolz Subject: Re: FAT Infection (PC) On Wed, 18 Sep 91 15:18:00 +1200 Nick FitzGerald said: >At this point there is much potential for confusion. Some BSI/PTI >viruses _affect_ (NOT infect) the FAT. This happens with Stoned and >most of its derivatives, due to the "assumption" by its creator, that >sector 0,0,7 is never used. This is true on HD's FDISK'ed with ... In this case, the virus may be affected in turn. This spring, I saw an example. A secretary at our university had a Stoned virus on her hard disk in a DOS 2.11 (or 2.7? -- I know there was a prime number after the dot) system. I told her to use only diskette drive B (to confine the virus) and to do a backup of all her files, before I came to dis-infect her environment. This lady was very scrupulous about her files, so she went through all the directories, deciding what files to backup and DELETING the other files. Now, DOS faithfully changed what it thought was the FAT, but what partly was the original master boot record saved by the Stoned virus to sector 0,0,7! This continued, until the computer did not boot any more from the hard disk. Another observation from the same incident bears on the epidemology of the Stoned Virus. That group has two secretaries equipped whith identical computers. Both had Stoned on their hard disks. When I checked all diskettes in that environment, I found that one secretary had infected more than half of her stock, while the other one had infected but 1 diskette. It turned out, that one usually worked whith drive A, and the other one usually whith drive B of her computer. Regards Otto ------------------------------ End of VIRUS-L Digest [Volume 4 Issue 170] ****************************************** Downloaded From P-80 International Information Systems 304-744-2253