VIRUS-L Digest Monday, 7 Oct 1991 Volume 4 : Issue 184 Today's Topics: Hardware v. Software Help in selecting an anti-virus utility for the PC (PC) Re: Anti-virus sources off the nets? Hardware, hardware... Forget Turing... Help! Viruses infecting only floppies (PC) New NOVELL virus? (NOVELL) (PC) Info on Solomon's A-V? (PC) Re: Why Bulgaria? Re: Bulgarian virus writers (PC) Re: New Virus Warning (PC) Overwriting viri File infectors Update to Product Test on Norton AntiVirus, version 1.5 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: Sat, 05 Oct 91 11:36:00 -0400 >From: WHMurray@DOCKMASTER.NCSC.MIL Subject: Hardware v. Software [Origin of the following is lost to me in the thread]: > the enemy uses for attack. Hardware defenses are needed to put a > stop to viruses. Software defenses can never do that. Hardware > defenses cannot be subverted by software. Bontchev: >Prove your claim. Describe a hardware defense that cannot be >subverted. These are two extreme positions of the same argument. Cohen has described a hardware mechanism that cannot be subverted by software. It is called the application machine. It is a computer such as your pocket calculator, the arcade machine, or the automatic teller machine. It is a machine whose capabilities no longer include programming. That is, it has been bound so as to resist any further change. Cohen argues that in a world of such machines we might enjoy most, but not all, of the advantages of the modern computer. Most of us would resist such a world. We recognize that progammability is too valuable to give up simply in the name of resisting viruses. However, the argument demonstrates that what is at issue here is a trade-off. We must strike a balance between early and total binding, such as we might accomplish by burning a function into hardware, and reserving so much freedom to the end-user that he damages himself and others. It is the classic and eternal argument between authority and freedom, order and chaos. These problems do not lend themselves to global solutions. While the hardware solution is attractive, it is Draconian. Of course, it is also ineffective in the short term. The virus problem is not a problem of the machines that we sell today, but of those that have already been deployed. We have seen examples, described here, of machines that include features that make them more resistant to viruses. While they may offer some protection to the owners of those machines, they have a vanishingly small effect on the global problem. Since the population of machines in the world is obviously large enough to guarantee the success of some viruses, and since that population is likely to persist for a decade or more, new hardware features are not likely to have much effect. Note also that any hardware features that make a new machine incompatible with current software will cost such machines a significant part of the market. Viruses are just a special case of that software. While it may be possible to design features that exploit the small differences between viruses and other software, both Cohen and experience to date suggest that such mechanisms can be only partially effective. The desire for hardware mechanism is part of the desire for measures that are totally effective. In security in general, and virus protection in particular, we have learned that all such measures, hardware or software, have infinite cost. The issue is not preventing the execution of all viruses all of the time. Rather, it is resisting the execution of most viruses most of the time. Such a strategy is capable of making the population sufficiently resistant to most viruses that they cannot prosper and spread. Software can contribute to this more readily than can hardware, if only because it can be readily retrofitted to the existing population, where the problem is. That is why it is called "soft," rather than "hard," ware. In this case, it is better to have a partially effective solution widely deployed than a totally effective solution sparsely deployed. One final comment: many complain that IBM and Microsoft are ultimately responsible for the virus problem because they failed to make the systems more resistant. In fact, our systems are vulnerable for the same reasons that they are popular. They make it easy to get a program executed at the right time. While many of us would be willing to give up some of the features that viruses exploit to get themselves executed, none of us would be able to give up all of them, and we would not be able to agree on a list. "Be careful what you ask for; you might get it." William Hugh Murray, Executive Consultant, Information System Security 21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840 203 966 4769, WHMurray at DOCKMASTER.NCSC.MIL ------------------------------ Date: 05 Oct 91 15:41:00 -0400 >From: "Michael Nieman" Subject: Help in selecting an anti-virus utility for the PC (PC) I am fairly unfamilar with ibm pc and their clones and I was wondering if anyone out there could help me. I am looking for some good antivirus utilities for the pc. Any suggestions are welcome and I would prefer suggestions that I could get from an ftp site. Thanks for your assistance Michael Nieman ------------------------------ Date: Sun, 06 Oct 91 00:50:48 +0000 >From: magik@chinet.chi.il.us (Ben Liberman) Subject: Re: Anti-virus sources off the nets? lunde@casbah.acns.nwu.edu (Albert Lunde) writes: >I will be talking to some people on virus prevention. They are from >business, and don't have much access to the "academic" nets like >bitnet, internet and uucp. > >What is available from sources like Compuserve, GEnie, Delphi, BIX? I >know Disinfectant is posted to a lot of these systems, but I have no >idea about PC stuff, or about where (what SIG or library, etc.) this >stuff would be kept. McAfee's anti-virus software for PC's can be downloaded directly from their BBS. 408 988 5138 (HST 9600 baud) - -- ------------ ------ ---------------------- Ben Liberman USENET magik@chinet.chi.il.us ------------------------------ Date: Sat, 05 Oct 91 20:43:15 -0700 >From: turtle@darkside.com (Fred Waller) Subject: Hardware, hardware... bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev), quotes from an article of mine: >> But hardware alone is enough. To illustrate: there's no virus >> in the world that can bypass a simple hardware device called >> a write- protect tab. This humble little piece of black paper >> doesn't care one bit about Cohen's theories. Disobeys them >> every time. :-) and replies: > Wrong. Completely wrong. There is a Bulgarian virus, called > Darth Vader, which infects COM files only when you copy them. Darth Vader can infect only AFTER becoming TSR in the system. HOW did that virus (of which I have some copies) would manage to become TSR on the system? During COPY? Certainly not. So why the attempt at confusing the issue with such misleading remarks: "Wrong. Completely wrong"..? In other words, the operator must not only intentionally defeat the hardware protection before the virus can get through it, but s/he must also EXECUTE the virus. Otherwise, it can't reproduce. That's not surprising, is it? It's not the virus who's defeating hardware protection, it's the operator. Darth VAder may infect during COPY, or it may infect while one sings La Donna e'Mobile in the shower, but only after becoming TSR and it CANNOT by itself ever bypass that little piece of cheap black paper called a write-protect tab, *as long as the tab is in place*. That was my point. Which illustrates that no software scheme, no matter how elaborate or complex, can *ever* defeat even the simplest hardware protection. And viruses are just software. > Another Bulgarian virus, the Compiler, infects files only when > they are created (by the compiler/linker) or when their size is > about to change. In both cases either the respective media is > not write-protected, or the user will remove the tab as soon > as s/he sees the "Write protected" error message. Again, assuming it has first become TSR, which in turn means that hardware protection was removed, an infected file brought it and the virus was then allowed to execute on the machine that had just been unprotected. No virus can defeat hardware protection by itself. It's physically impossible. No reasonable person could hold otherwise. Software protection, however, can always be defeated by other software (such as viruses). It's not necessary for an operator to disable it for a new virus to bypass it. Permanent software protection against viruses is impossible. Fred (W) turtle@darkside.com --------------------------------------------------------------------- Hardware vulnerari non posse. :-) --------------------------------------------------------------------- ------------------------------ Date: Sat, 05 Oct 91 20:47:30 -0700 >From: turtle@darkside.com (Fred Waller) Subject: Forget Turing... bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) writes: > Remember, Cohen proved that on machines with Turing capability, > shareing of information, and transitivity of information flow, > the viruses are possible, and unstoppable in general. (Such faithful reliance on theory... But all theories die, sooner or later. If Turing's original conceptualization is an obstacle, why not just change it a little? :-) If the theory doesn't fit the facts, change the theory, don't change the facts...) I remember _something_, but am not sure that THAT's *exactly* what Cohen said... And, if he did, then I wonder if he missed something... Did he consider a variant of the multitape Turing machine (say, two- tape) in which one of the tapes was only partially enabled, operating under a specific (MS DOS) regime..? It should be possible to make such a machine emulate a more conventional Turing machine (i.e., it should compute the same functions that a conventional, one-tape Turing-based machine can compute, perhaps with minor modification in some cases) and yet it could be made resistant to viruses. Strict demonstration that the original Turing model and all the modified models, including the multi-tape machine, can each compute the same class of functions was done by showing that for every "variant" machine there exists some form of "standard" Turing machine that can emulate its behavior, and viceversa. In other words, all proposed modifications of the Turing machine are "convertible" to the standard machine, and viceversa. However, for our concept to be practical, it has to mean that a modified two-tape Turing machine in which one of the tapes is only partially enabled (at the "physical" level) would be not-completely equivalent to any possible form of the standard machine. This would also mean that such a variation of the Turing machine might actually be considered as a different kind of abstract computing device which, unlike other modifications of the Turing machine, cannot be *fully* emulated by a standard Turing machine. As a practical test, physical realization of a computer having such characteristics could be taken as indication that such a Turing-based machine was a valid concept. If implemented, the design could lead to a virus-resistant machine because it could be made to allow discrimination between stored code and stored data not only temporarily, but permanently as well. As it turns out, under certain limited circumstances, it IS possible to implement a design that is based on such a modification of the multitape variation of the Turing model. Such a design relies on currently-available properties of *both* software and hardware, but is initially enabled by hardware modifications alone. The new machine is able to perform unique functions by restricting certain other functions of the standard model. One of the abilities it acquires is equivalent to resolution of von Neumann's ambiguity over long periods (under MS DOS and similar OS regimes). A machine possessing such characteristics has been easily and inexpensively built. As expected, it has indeed proven itself to be virus-resistant _per se_ (at the hardware level) when used properly *and* of being capable of running conventional (MS DOS) computer programs at the same time. The partially-enabled tape becomes a new kind of element in the machine (i.e., one of the two "read/write heads" in the two-tape modification becomes a "read-only" head). Of course, such elements (not originally included in Turing's definition) or their functional equivalents, have been commonplace for a long time, since the introduction of optional write-protection in computers. (To my knowledge, no one has claimed that our PCs "ceased being Turing- based machines" while write-protection was in use, but if anyone insists in viewing things that way, I won't object). The characteristic that distinguishes my machine from conventional Turing-capable microcomputers is that the partially-enabled tape (= disk) is permanently dedicated to storage of instructions, while the fully-enabled tape (= disk) is dedicated to storage of data. Under an MS DOS regime, this duality allows resolving von Neumann's ambiguity in practice (at least as far as MS DOS is concerned!), because it provides permanent, physical separation of code and data. Although this condition contradicts Turing's original definition, it is achieved without significant detriment to the functionality of the machine as an MS DOS computer in practical applications. This quality also makes the machine virus-resistant. Even if a file infector were to be intentionally allowed on the partially-enabled drive, it would not be able to replicate there. (Intentionally- allowed Boot viruses could still infect new diskettes inserted into the machine, because the Boot sector is an exception to our rule that executable code be restricted to the protected drive. This breach of the rule can also be stopped by simple, but additional, hardware means). Thus, under selected circumstances (MS DOS regime), it's possible to implement in practice a computer based on a variation of the Turing machine which can emulate most functions of a conventional Turing-based computer but which, in turn, cannot be fully emulated by one. Such a machine is inherently virus-resistant. The resistance is achieved by selectively restricting some of the qualities of the `standard' machine. A main reason this design is possible in practice is that MS DOS does not use ALL the Turing-like capabilities of the standard machine. It may allow them, but does not require them. Therefore, it is a simple matter to design a physical system, capable of running MS DOS and its applications, in which the not-required functions are restricted or eliminated. Making the restriction permanent limits certain desirable functions (ability to update programs), so it is made temporary, i.e., the resolution of von Neumann's ambiguity is discontinnuous over time, but the periods of resolution are made so long (weeks, years) as to be considered permanent for practical purposes. (The design described here was originally suggested by practical necessity during work with viruses. I have made no detailed search of the literature. However, it seems that the desirability of physically separating code from data in a manner similar to the one described above has been perceived by others before me. Unfortunately, the idea seems to have been dismissed as impossible or impractical as an antivirus measure, on purely theoretical grounds and without practical investigation. But the design of hardware systems cannot be logically derived from purely symbolic considerations, which seems to be what some earlier proponents tried to do.) Returning to the practical aspect, it's also interesting that: 1. Such machines may be built at extremely low premium over the cost of a comparable conventional microcomputer and 2. existing MS DOS microcomputers can usually be easily, quickly and inexpensively converted to the new design. 3. The one-time cost of such modification compares favorably with the long-term cost of software protection, which is also much less effective. 4. This type of machine is useful not only in standalone applications, but in multi-user file servers as well. :-) Since the machine is vulnerable to virus attack only during very short and clearly identified periods, it is much easier to carry out thoughtful profilaxis. Additional security may be achieved automatically to a very large, if not absolute degree, by use of firmware or other restrictors that would allow copy but not execution while the machine is in unprotected state. When the machine is restored to its "protected state", it is invulnerable to virus attack AND to virus propagation by MS DOS viruses. Such additional security during the unprotected state is slightly more expensive. Fred (W.) turtle@darkside.com ------------------------------------------------------------------ Now, a *hardware virus*, that would be a little more difficult... ------------------------------------------------------------------ ------------------------------ Date: Sun, 06 Oct 91 12:27:21 -0700 >From: p1@arkham.wimsey.bc.ca (Rob Slade) Subject: Help! Viruses infecting only floppies (PC) wdh2866@zeus.tamu.edu (HAWKINS, WILLIAM DARYL) writes: > Does anybody out there know of a virus which affects only floppy drives, > and not hard drives? Whenever I try to read, write, or format a floppy > disk in either a 5 1/4" 1.2 MB or a 3.5" 1.44 MB drive, I get errors > ranging from data errors to track 0 bad..... I am cuurently running Given that you are seeing these problems on HD floppies, it may be a result of the Stoned virus. Many early versions overwrote portions of the system areas of HD floppies. However, your posting really gives very little information. Have you tried checking your system with FPROT or SCAN? ============= Vancouver p1@arkham.wimsey.bc.ca | "If you do buy a Institute for Robert_Slade@mtsg.sfu.ca | computer, don't Research into CyberStore | turn it on." User (Datapac 3020 8530 1030)| Richards' 2d Law Security Canada V7K 2G6 | of Data Security ------------------------------ Date: Sun, 06 Oct 91 12:06:25 -0700 >From: p1@arkham.wimsey.bc.ca (Rob Slade) Subject: New NOVELL virus? (NOVELL) (PC) RONNIE@ECUAFUN.BITNET writes: > Today, a network under NOVELL 3.11, was hit by a unknown virus, at > least in our environment, the virus only affects the server, when you > issue the command "load monitor", few minutes later, the screen clears > and a worm composed by block characters showing different levels of > gray begins to run across the screen, the creature disappears when you > press the ESC key. Actually, there is little in the details that you have provided to indicate that what you are seeing is coursed by a virus at all. The fact that the display is seen only in relation to one program would indicate that it is not spreading, and that would suggest that you have a trojan (unlikely, since you don't mention any damage) or a prank. Have you checked for a SERVER.COM or SERVER.BAT file, possibly hidden? Have you tried reinstalling SERVER.EXE? Have you checked the SERVER.EXE file size, date and image against the original? > We're checked the server under DOS with CPAV v 1.0, and installed the > VSAFE.SYS program in memory, then run the program SERVER.EXE, issue > the "load monitor" command, and few minutes later, the worm appears on > the screen, and the VSAFE program says nothing, the CPAV program > doesn't say anything, and the worm continue to run across the screen. CPAV and VSAFE, as used by most, check for known viri. My memory being what it is, I don't recognize this beast from the description. That isn't proof, but maybe you *do* have a new virus. In that case, you should use the option for change detection that CPAV provides, and see if any files are changing size or image. The other possibility is that you have some type of boot sector infector. You can test that by "feeding" the suspect machine with new floppies, and checking the boot sector before and after with DEBUG. Alternately (and my own preference) would be to check the partition boot record of the server with something like FPROT's F-PBR. (You will have to get an older version of FPROT: F-PBR is not shipped with version 2.00.) ============= Vancouver p1@arkham.wimsey.bc.ca | "If you do buy a Institute for Robert_Slade@mtsg.sfu.ca | computer, don't Research into CyberStore | turn it on." User (Datapac 3020 8530 1030)| Richards' 2d Law Security Canada V7K 2G6 | of Data Security ------------------------------ Date: Sun, 06 Oct 91 19:25:37 -0600 >From: Jesus Miguel Garcia Subject: Info on Solomon's A-V? (PC) Anyone has Tryed Dr. Solomon's Anti-Virus? How is it? I Heard about its great. How can i get it? Here in Mexico, i think that we dont have a store for buy it. Should i go to Usa for buy it? :) Thanks? Write me Mail. Regards, Miguel. ************************************************************************* ************************************************************************* * M T C * * O H R J. Miguel Garcia Rodriguez * * T E U Apartado Postal 2399-J * * L E 64841, Monterrey, N.L. * * E M E X I C O * * y ... Bl163193@Tecmtyvm.Mty.Itesm. Mx * * miguel@lagtec.lag.itesm.mx * * * ************************************************************************* ************************************************************************* ------------------------------ Date: 07 Oct 91 10:03:35 +0000 >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Why Bulgaria? ROsman%ASS%SwRI05@D26VS046A.CCF.SwRI.EDU writes: > I have noticed that a large number of viruses are listed with Bulgaria > as their origin. Does anyone have a notion why? Is it that the > Bulgarians aren't on the net to defend themselves? A twisted sense of Indeed, the Bulgarians are not on the net... There are -very- few Internet sites in Bulgaria and I guess that they do not read comp.virus... > national pride? A single prolific and perverted programmer? What? In short: (1) a lot of very qualified and low paid young programmers (2) total lack of legislature concerning the virus problem; (3) incorrect public oppinion; (4) easy access of information of a particular kind; (5) perverted wish for fame... All these are result of a combination of particular social, economical and political conditions, described in my paper. Regards, Vesselin - -- Vesselin Vladimirov Bontchev Universitaet Hamburg, FB Informatik - AGN Bontchev@Informatik.Uni-Hamburg.de Schlueterstrasse 70, D-2000 Hamburg 13 New address after October 1, 1991: Vogt-Koelln-Strasse 30, D-2000, Hamburg 54 ------------------------------ Date: 07 Oct 91 09:00:35 +0000 >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Bulgarian virus writers (PC) XPUM04@prime-a.central-services.umist.ac.uk (Anthony Appleyard) writes: >f these two disastrously productive virus writers are operating openly, as >eems from the above, can't the government or law courts of Bulgaria act against >hem?? like the USA courts did with Morris and his Internet worm that time. Nope. According to the Bulgarian legislation, there is no such thing as ownership of computer information (or copyright either). If I go and destroy somebody's computer information, s/he cannot sue me unless I physically damage his/her computer. Also, the creation and wilful spread of computer viruses is not regarded as a crime in Bulgaria - yet. That's one of the reasons why virus writing is so popular there. I spoke with two people's representatives from the Parliament and they both showed good understanding of the problem and promised to help, but until now nothing has been done... :-(( > [Ed. This message is closely related to Rich Osman's > (ROsman%ASS%SwRI05@D26VS046A.CCF.SwRI.EDU) question in today's digest. > Vesselin Bontchev presented his paper, "The Bulgarian and Soviet Virus > Factories", at last month's Virus Bulletin conference. The paper > addresses both of these questions.] Several people requested this paper. May I make it publicly available? I mean, does this break any copyright laws? As far as I understood, the authors of the papers, presented on the VB conferense retain full copyright on their respective articles. Besides, the version of the paper that I have is a slightly improved version of what has been printed in the proceedings. So, maybe it is possible to provide it? Ken? [Ed. We're working on this and hope to have the file available shortly.] Regards, Vesselin - -- Vesselin Vladimirov Bontchev Universitaet Hamburg, FB Informatik - AGN Bontchev@Informatik.Uni-Hamburg.de Schlueterstrasse 70, D-2000 Hamburg 13 New address after October 1, 1991: Vogt-Koelln-Strasse 30, D-2000, Hamburg 54 ------------------------------ Date: 07 Oct 91 09:23:38 +0000 >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: New Virus Warning (PC) PHYS169@csc.canterbury.ac.nz (Mark Aitchison, U of Canty; Physics) writes: > Am I safe in assuming that just looking at the directory entries, and at > absolute sectors on the disk (or even via int 25h) will not cause a virus > to infect a file that wasn't infected before? (Other than the boot sector ) > For that matter, any tips on "safe" simple tests would be appreciated > (yes, I've already thought of the 6-byte method). It is my understanding that we're speaking about the Dir II virus. In this case - yes accessing the directory via INT 25h will cause infection of all directory entries that belong to COM and EXE files, which can be found in the accessed directory sector. If the virus is resident in memory, of course. Besides, this virus does not infect the boot sector - you probably mean the last cluster of the disk. If this virus is resident and active in memory, there are no safe tests. Any disk access will cause the virus body to be written to the last cluster, and any directory access will infect all directory entries that are contained in the directory. > While I'm on the scrounge for information... has anyone tested those > programs that automatically squash data on your disk (Stacker & > DrDOS's SuperStore) to see what various viruses do. My guess is that > file infectors either won't work or will totally mess up the whole > compressed partition, but even more I'm worried about disinfectant > programs ruining the disk. I do have SuperStore, a few viruses, but > not enough nerve to risk my data on the tests! I use only STACKER, so I can supply information only about it. Stacker is completely transparent to the DOS file functions (and even to the sector access functions), so most viruses spread without problems on a stacked volume. Especially Dir II won't infect anything on such a volume, since it doesn't infect partitions that are accessed through a loadable device driver. There is, however, another danger. Consider a destructive virus (like the Dark Avenger), which causes destruction by bypassing all programs which have intercepted INT 13h and writing a sector on a random place on the disk. This will have the same effect on a stacked volume, as changing a few random bytes in the middle of a ZIP archive. Fortunately, the STACKER package contains a powerful equivalent of PKZIPFIX - it is called SCHECK. However, I also didn't tested how well it is able to repair a stacked volume, if a whole disk sector has been modified. Regards, Vesselin - -- Vesselin Vladimirov Bontchev Universitaet Hamburg, FB Informatik - AGN Bontchev@Informatik.Uni-Hamburg.de Schlueterstrasse 70, D-2000 Hamburg 13 New address after October 1, 1991: Vogt-Koelln-Strasse 30, D-2000, Hamburg 54 ------------------------------ Date: Sun, 06 Oct 91 22:37:43 -0700 >From: p1@arkham.wimsey.bc.ca (Rob Slade) Subject: Overwriting viri FUNPIV2.CVP 911006 Viral code insertion There are four ways to attach code to an existing program: overwrite existing program code, add code to the beginning of the program, add code to the end of the program and not add code to the existing program. Overwriting viral programs are a very simplistic answer to the problem of how to add code to an existing program without changing the file size. By simply overlaying code which is already on the disk, the original size remains unchanged. There are a few problems with this approach. The first is the problem of how to get the virus "called" when the infected program is run. If the code is just inserted anywhere, it may not be in a part of the program that gets used every time the program is run. (Every programmer is aware of the Pareto Principle's application here: 20 percent of the code does 80 percent of the work. Some code never gets called at all.) It is possible, by an analysis of the code of the target program, to find an "entry point" which is used extensively. It is also possible, and a lot easier, to place a jump at the beginning of the program which points to the viral code. The second problem is much more difficult to deal with. If the virus code overwrites existing portions of the program code, how do you know the loss of that program code is not fatal to the target program? Analysis of this type, on the original code, would be very difficult indeed. "Successful" overwriting viri tend to be short, and to look for extensive strings of NUL characters to replace. (The NUL characters tend to be used to "reserve" stack space, and thus are not vital to the program.) Even if the original code is not vital to the program, it may, if replaced, cause the program to exhibit strange behaviours, and thus lead to detection of the viral infection. Thus, while overwriting viri solve the problem of file size, they bring with them some inherent problems which appear, at this time, to severely limit their effectiveness "in the wild". To this date, while many overwriting viri have been written, none have enjoyed great "success", or become a widespread and major problem. (The Zen-like nature of the opening paragraph will be explained in future columns.) copyright Robert M. Slade, 1991 FUNPIV2.CVP 911006 ============= Vancouver p1@arkham.wimsey.bc.ca | "If you do buy a Institute for Robert_Slade@mtsg.sfu.ca | computer, don't Research into CyberStore | turn it on." User (Datapac 3020 8530 1030)| Richards' 2d Law Security Canada V7K 2G6 | of Data Security ------------------------------ Date: Sun, 06 Oct 91 22:36:30 -0700 >From: p1@arkham.wimsey.bc.ca (Rob Slade) Subject: File infectors FUNPIV1.CVP 911006 File infecting viri File, or program, infecting viral programs, while possibly not as numerous as boot sector infectors in terms of actual infections, represent the greatest number of known viral strains, at least in the MS-DOS world. This may be due to the fact that file infectors are not as constrained in size as BSIs, or that file infectors do not require the detailed knowledge of system "internals" which may be necessary for effective boot sector viri. File infecting viri spread by adding code to existing executable files. They have the potential to become active when an infected program is run. Whereas boot sector infectors must be memory resident in order to spread, file infecting programs have more options in terms of infection. This means that there is greater range in the scope for writing file infecting viri, but it also means that there may be fewer opportunities for a given virus to reproduce itself. File infecting viral programs must, of necessity, make some kind of change in the target file. If normal DOS calls are used to write to it the file creation date will be changed. If code is added to it, the file size will change. Even if areas of the file are overwritten in such a way that the file length remains unchanged, a parity, checksum, cyclic redundancy or Hamming code check should be able to detect the fact that there has been some change. The Lehigh and Jerusalem viri, the first to become widely known to the research community on the Internet, were both initially identified by changes they made to target files (the Jerusalem being widely known by its length as "1813".) "Change detection", therefore, remains one of the most popular means of virus detection on the part of antiviral software producers. Because change detection is a means of virus detection that requires no sophisticated programming (in some cases, no programming at all), virus writers have attempted to camouflage changes where they can. It is not a difficult task to avoid making changes to the file creation date, or to return the date to its original value. It is possible to "overlay" the original code of the program, so that the file is not increased in size. Most recently, virus authors have been using "stealth" programming: a means of "shortcutting" the operating system, and returning only the original, unchanged, values at any request for information. copyright Robert M. Slade, 1991 FUNPIV1.CVP 911006 ============= Vancouver p1@arkham.wimsey.bc.ca | "If you do buy a Institute for Robert_Slade@mtsg.sfu.ca | computer, don't Research into CyberStore | turn it on." User (Datapac 3020 8530 1030)| Richards' 2d Law Security Canada V7K 2G6 | of Data Security ------------------------------ Date: Fri, 04 Oct 91 15:08:41 -0600 >From: Chris McDonald ASQNC-TWS-R-SO Subject: Update to Product Test on Norton AntiVirus, version 1.5 ******************************************************************************* PT-28 February 1991 Revised October 1991 ******************************************************************************* 1. Product Description: Norton AntiVirus is a virus protection utility for the IBM PC and its compatibles. The product includes virus detection, disinfection, and protection. This revision addresses version 1.5. 2. Product Acquisition: Norton AntiVirus is available from Symantec Corporation, Peter Norton Group, 10201 Torre Avenue, Cupertino, CA 95014-2132. The retail price is $129.95; but there are numerous secondary sources with single copy prices that have ranged from $78.00 to $83.00 in trade publication advertisements. Site licenses are also available. 3. Product Testers: Chris Mc Donald, Computer Systems Analyst, White Sands Missile Range, NM 88002-5506, DSN: 258-4176, DDN: cmcdonal@wsmr-emh03.army.mil or cmcdonald@wsmr-simtel20.army.mil. [Ed. The remainder of this product review is available by anonymous FTP on cert.sei.cmu.edu in the pub/virus-l/docs/reviews directory.] ------------------------------ End of VIRUS-L Digest [Volume 4 Issue 184] ****************************************** Downloaded From P-80 International Information Systems 304-744-2253