VIRUS-L Digest Wednesday, 25 Sep 1991 Volume 4 : Issue 173 Today's Topics: Azusa Virus hits University of Kentucky (PC) Re: Belch_Virus? (Mac) re: Boot variations (PC) Precise identification (PC) Reaction and Philosophy Seeking test file...... (PC) A Question (PC) Precise identifications Software protection? Infectable Areas (PC) Re: Brain Virus (PC) Re: Various (PC) (Novell) Re: More info on Compuserve Accidentally Distributing Viruses (PC) Re: BIOS Viruses (PC) Re: Comment 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: Mon, 23 Sep 91 21:04:33 +0000 >From: morgan@ms.uky.edu (Wes Morgan) Subject: Azusa Virus hits University of Kentucky (PC) For those who track such things, the Azusa virus was discovered at the University of Kentucky today (9.24.91). The Azusa virus infects the boot sector of floppy disks, the partition table of hard disks, and stays resident in memory. It causes corruption of data files, general system slowdown, and generally wreaks havoc. McAfee SCAN found it, and McAfee CLEAN removed it. However, on several occasions, the data on the floppies was unrecoverable. - -- morgan@ms.uky.edu |Wes Morgan, not speaking for| ....!ukma!ukecc!morgan morgan@engr.uky.edu |the University of Kentucky's| morgan%engr.uky.edu@UKCC morgan@ie.pa.uky.edu |Engineering Computing Center| morgan@wuarchive.wustl.edu ------------------------------ Date: Tue, 24 Sep 91 14:45:31 +0000 >From: dana%are.Berkeley.EDU@ucbvax.Berkeley.EDU (Dana E. Keil) Subject: Re: Belch_Virus? (Mac) Or possibly someone made the file invisible? Use ResEdit or some other utility to make sure there is not some invisible file in the system folder. It could be sndcontrol which has an option called "idle talk" that will produce a sound periodically. - -- Dana E. Keil Department of Agricultural and Resource Economics dana@are.Berkeley.EDU University of California, Berkeley ------------------------------ Date: Tue, 24 Sep 91 11:07:04 -0400 >From: padgett%tccslr.dnet@mmc.com (A. Padgett Peterson) Subject: re: Boot variations (PC) >From: p1@arkham.wimsey.bc.ca (Rob Slade) >Zenith computes have always had a fairly distinctive boot sequence. >Latterly, Zenith BIOS will allow you to specify whether the computer is >to be booted from the floppy or the hard disk, and which disk. >This is a handy safety feature (and equally handy for virus research.) Almost & you have to be careful - this will only work if the Zenith setup knows that there is a hard drive present and matches one of the "TYPE"s stored in the BIOS. Many hard disks require use of their own controller BIOS and then the Zenith SETUP reports "NOT PRESENT" for the two hard disk drives. In this case the Zenith BIOS will ALLWAYS try to boot from floppy first no matter how the SETUP screen is set. TANDON (wonder if I can buy stock) goes one step further and actually checks the selected partition table for validity in addition to being able to boot from hard disk first or only. >Formerly, however, Zenith computers, among others, would change the boot >sector on every startup. This was sometimes used as a pseudo "clock backup". >The fact that the boot sector was changing at all times, however, conflicted >with change detection software which checked the boot sector. As far as I know, this writing was only done by Zenith 158s and 159s (XT-class) and HP Vectras. One thing I found was that if the writing area was nulled (all zeros - location varied with OS version) it would no longer write (maybe). >s copyright Robert M. Slade, 1991 FUNBOT4.CVP 910920 Padgett ------------------------------ Date: Mon, 23 Sep 91 23:23:13 -0400 >From: padgett%tccslr.dnet@mmc.com (A. Padgett Peterson) Subject: Precise identification (PC) Reaction and Philosophy >From: turtle@darkside.com (Fred Waller) > 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? Don't flame the vendors for responding to the demands of the market ! IMHO If the IBM-PC had contained all of the integrity management tools of a mainframe, PC viruses would not exist because no-one would have bought any. TI tried a closed architecture and the 99/4 (a superior 16 bit machine) wound up being sold at Toys-R-Us for $49.95 (I have one & a Sinclair & a Trash-80: all good but not good enough - the IBM-PC is good enough - see Quantum Economics). Several packages of hardware and software have been produced in the past that would provide the type of protection mentioned, but to date, none have succeeded beyond niche markets. In particular, the Anti-Virus vendors have nothing to do with these access control tools. The popular ones have evolved from SCANners because that is what people have been willing to buy. A simpler solution already exists: OS/2. If there is an OS/2 virus, it certainly has not spead very far (but then neither has OS/2 ). I agree about the concept of avoiding viruses in the first place. That's why I wrote NoFBoot and made it freeware (four weeks and no reported problems: KISS works). It does nothing to stop viruses, it doesn't know anything about viruses. All it does is to prevent an accidental warm boot from a floppy with a three finger salute & probably would have prevented the STONED secretary infection mentioned later in issue 170. Already, several BIOS manufacturers (Tandon, Zenith) are building such protection into the setup, something one would hope will spread. Hardware solutions ARE better but cost - the JDR board (haven't tried it but is cheapest I've heard of) is $49.95 + s&h + it takes up a slot + it has to be installed. This is *more* than a DOS upgrade (if you ask nicely) and harder to justify for 5000 machines. Meanwhile, back at the posting: A) > 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_. B) > Hardware defenses stop viruses. Software defenses do not. Here I feel like I am being hoisted on my own etc. since it is part of a statement made before, however while (a) is true (b) is not. Only hardware can block a cold boot from a floppy (and should be BIOS selectable as mentioned above. Software can block everything else (and detect or hide from the first). The fact that no single product does everything (yet) is just a matter of time and is the only economically feasible solution. It is also the only necessary solution. What wasn't said was that Software AND reasonable procedures can stop viruses. Period. As previously mentioned, right now I use four separate products to accomplish this on my personal PC and since a virus has no way of knowing what they are, and two of them use a different validation seed/algorithm on each installed PC, software would have a heck of a time getting past them. With some effort, I could break it but only because they are installed in low-threat mode. (Unlike two password/security products looked at in the last month which not only were breakable in under 10 minutes, but which I could write a short .COM file to break either in seconds. - no, I am not going to name them, please do not ask). More important, unless an exception occurs (usually when loading a new package) I never know they are there. And I have over 630k bytes of free RAM (even on the laptop that only has 1 Mb of memory. It CAN be done.) Consider the implication of a system with a fixed disk separated into tworeoccuring system crashes - the whys would take all day and considerable lubrication) and contains all executables. DataDisk holds only non-executable files. In fact executables are not permitted to load from DataDisk (see PATH). Need to update a file or install a new package ? (e.g. run INSTALL from "A"), type BYPASS A:INSTALL and you are prompted for a password. With the right password, A:INSTALL and any spawned files are permitted to write to ProgramDisk (INSTALL could be a .BAT also). The write protect turns back on when INSTALL terminates & always protects the MBR/hidden sectors/Boot Record. No BYPASS, no write to disk. KISS - but no limit to legitemate actions. Not 100% perfect no, but probably 99 44/100ths. At EGGHEAD today - no again but the technology demonstrator exists. If enough people ask for it, the vendors will tool it up and you will be able to buy it from Norton and Mace and Central Point and Digital Research and Microsoft and no two will be alike. - care to write a virus to beat that scenario ? Think about it. Padgett All of the above is my opinion, but what else do we have ? ------------------------------ Date: Mon, 23 Sep 91 17:28:28 -0600 >From: John Kida (Vienna) Subject: Seeking test file...... (PC) Looking for a way to test Our NETSCAN program.... The customers, for good reason do not wish a live virus loaded on to a network. However they want to be asured that the thing works at the same time. IS there a TESTING file out there in the data world? I understand the reason for guarding the sreach strings, But how do I assure a customer to trust that it works....? I have tried implanting several know signatures in COM & EXE files, but this does not seem to work. I used NORTON's HEX editor to do it. It seems the signatures used by other SCANNERS are not the same as Mc Afee's so it has failed to date. ------------------------------ Date: Mon, 23 Sep 91 20:58:44 -0400 >From: padgett%tccslr.dnet@mmc.com (A. Padgett Peterson) Subject: A Question (PC) Am proceeding with more experiments with partition tables/hidden sectors and would appreciate some feedback if anyone has encountered things ( custom BIOSes, peripheral controllers, software) that write to the hidden sectors of a hard disk partitioned on even track boundaries (e.g. FDISK 2.0 and later). At present, the only one that I am aware of is the tendancy of the Western Digital RLL disk controller #WD10002A-27X with the SuperBios when installed in an XT class machine to write to a short area preceeding the partition table on track 0 head 0 sector 1 (whew!). I would appreciate a note from anyone who has knowlege of things writing to any sector in track 0 head 0 (other than viruses of course). Note: this refers to those sectors that the BIOS considers trk 0 hd 0 not the actual sectors if a translating controller is in use and would appear as such to MS-DOS. Padgett ------------------------------ Date: Mon, 23 Sep 91 21:24:19 -0700 >From: turtle@darkside.com (Fred Waller) Subject: Precise identifications Writes padgett%tccslr.dnet@mmc.com (A. Padgett Peterson), on the subject of "precise identification": > Depends on your point of view. As a user, you could probably > care less - - all that is necessary is to know that > *something* has happened. But for the tech who comes out > in response to the bleat for help, more is necessary. If it > is me, I try to collect all information possible before > proceeding & then, veeerrry cautiously until I know > exactly what we are dealing with since my purpose is to > recover the machine, not scramble it hopelessly, and > hopefully without a FORMAT. That is precisely the point. We are so used to thinking in terms of "curing infections" that the idea of _preventing_ them no longer seems to cross our minds. But it's obviously more desirable to _prevent_, rather than cure, virus contamination. Virus scanners are programs designed to detect infection after it has occurred. One wonders, why is it necessary to wait so long? Why not look for approaches that prevent rather than cure? Hardware protection approaches are more effective than software approaches, which are only temporary at best, never foolproof, need to be constantly upgraded... That's why I was asking, slightly tongue-in-cheek, "why do we need to "make precise identification"? The answer is: we don't. ------------------------------ Date: Mon, 23 Sep 91 21:27:44 -0700 >From: turtle@darkside.com (Fred Waller) Subject: Software protection? Writes mrs@netcom.com (Morgan Schweers): > It's my firm opinion that the virus problem will not go away > until the operating system manufacturers move their OS into > protected mode, and implement file protection checking in > protected mode. This would also, of course, assist in > implementing multiprocessing, etc. Now, viruses would still > propagate under earlier versions of the OS and earlier processors > than the 80386, but it would *STOP* the continual increase of > viruses. Without trying to detract from the desirability of having better Operating Systems for our machines, I'd like to point out that it isn't necessary to have such a major change in order to stop the ever-mounting increase of virus infection. And changing OS, while highly desirable, is not a universal solution. I've had people offer to write for me a "protected-mode virus". I turned them down, but others surely will not. The current PC population, estimated at 40 million machines, consists largely of pre-386 units, many of them pre-286. That's an enormous "market" for viruses that the new OS would not protect. Most of those machines are not currently infected, but the number of infected machines among this population increases continuously. Should these machines be abandoned? Should their owners be forced to throw them away and buy new machines in order to have protection? Yet, simple hardware changes are possible that offer considerable protection against viruses and other undesirables, at a lower overall cost than continuously-upgraded software. Some of these devices have already been briefly written about in this newsgroup. Every software attack can be defended against, but every software defense can be defeated - always. This is the vicious circle upon which the anti-virus industry is based and on which it relies for future expansion. This vicious circle must be broken. Hardware protection must become the final solution that will break the vicious circle. There is no software (and viruses are software) that can bypass it. ------------------------------ Date: Mon, 23 Sep 91 21:26:06 -0700 >From: turtle@darkside.com (Fred Waller) Subject: Infectable Areas (PC) Writes mrs@netcom.com (Morgan Schweers), commenting on a post by Vesselin Bontchev: > There is a limited set of areas that can be infected by a virus. > Essentially, the files, the MBR and the Boot Sector. May I point out that there is another area which is none of the above but has been used by viruses to store executable code: extra tracks formatted on diskettes. Strictly speaking, this is not "file space", since it is not defined in the FAT, nor does it have a directory entry, nor, obviously, is it any part of the Boot Sector. It is new, non-DOS space, which the virus creates for itself. Since, within wide limits, diskettes have no hardware definition but are defined purely by software, other changes are possible which would not fit the areas mentioned by Mr. Schweres. A similar trick is usually not possible on hard disks, but some hard disks do have a so-called "engineering cylinder", recognized by the controller, where executable data might be stored. > There are some things that viruses have not been written to do > yet, thankfully. There are some things that viruses CAN not be > written to do, simply because it's impossible. (INFECTING the > FAT is one of these.) I think this depends on how one defines the word "infecting". Conventional file space on a DOS disk may contain either user data, OS data or executable code. The distinction is made by software (the OS), not by any characteristic of the recording. Similarly, the FAT (or any other portion of the disk) may contain data or executable code. Such data may not be directly executable by the OS, but the virus may still be able to call it for execution as part of itself. May we say, in such case, that the FAT has been "infected"? Or is it more appropriate to say that the virus has "stored code in the FAT"? Isn't "storing code" the same as "infection", especially if it is executable, in one way or another? That is, after all, a definition of what the Joshi, etc. does. And what should be the definition of the method used by DIR-2..? > Other side comments: Mr. Bontchev mentioned that to his awareness > VirX was the only program which scanned inside of PKLite'd files > as well as LZEXE'd files... That's not true. McAfee Associates > places high import on the ability to scan inside of compressed > executables. PKLITE and LZEXE detection have been standard inside > our programs for some time now. Mr. Schweres is modest. McAfee's SCANV program was the =first one= to decompress and scan inside LZEXEd files, very shortly after LZEXE appeared. For a very long time, it was the =only one=. I'm surprised that Mr. Bontchev didn't remember this. ------------------------------ Date: 24 Sep 91 14:52:08 +0000 >From: cssr@hippo.ru.ac.za (Sajid Rahim) Subject: Re: Brain Virus (PC) > 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)? This alarm is due to vdefend. It seems to keep the strings which it uses to recognise the viruses in an unencrypted form. It is this that SCAN picks up and there is no reason to fear an infection. Sajid - -- ============================================================================ Computer Science Dept, Rhodes University, Grahamstown, South Africa Internet : cssr@hippo.ru.ac.za - ---------------------------------------------------------------------------- ------------------------------ Date: Tue, 24 Sep 91 10:06:15 -0600 >From: kev@inel.gov (Kevin Hemsley) Subject: Re: Various (PC) (Novell) In VIRUS-L V4 #171 Steven R. Klepzig (sklepzi@ssb1.saff.utah.edu) writes: >A few messages back someone mentioned something about Novell servers >using DOS interrupts. In pre-386 versions of Netware DOS was >replaced, interrupts and all, by Netware. With the 386 versions DOS >may be unloaded from the server after Netware is started with the >SECURE CONSOLE command or from the RCONSOLE screen. I don't know if >that removes/replaces the DOS interrupts. Since you can return to DOS >after downing the server (assuming you didn't secure the console) I >suspect it doesn't replace them. It is true that DOS can be removed from the console's memory with the SECURE CONSOLE command. This measure will prohibit a BSI virus, which has infected the file server, from infecting disks accessed in a floppy drive connected to the server. This is an extremely rare incident because a floppy drive, if even attached to a server, is rarely if ever used. As for BSI infection of the server from an infected workstation, this is not possible using standard NetWare disk device drivers. Standard drivers do not support direct sector addressing through normal DOS and BIOS interrupts. Although it is possible for such a driver to exist, let us hope that one will not become popular. Even if a BSI virus were able to infect the server from a workstation, it would not be a trivial task for such a virus to infect workstations attached to the network. This would probably require a NLM/VAP. Although this is technically possible, it is extremely unlikely. The risk to networks, therefore, is from file infecting viruses, not boot sector/partition table viruses. NetWare provides excellent protection from malicious software if protection measures are PROPERLY implemented. A proper implementation includes a formal network security plan, and prudent enforcement of that plan. Proper assignment of NetWare rights will be fruitless if someone with SUPERVISOR or SUPERVISOR EQUIVILANCE executes a file from an infected workstation. I suggest that security measures not rely on NetWare attribute security. Careful assignment of rights will provide a better protection against virus propagation. There is a clear distinction between NetWare RIGHTS and ATTRIBUTES. Attributes are an emulation and an extension of regular DOS file attributes. Viruses can change NetWare attributes which exactly emulate DOS attributes. Only one NetWare attribute does not seem to be modeled exactly by NetWare. This is the System attribute. In testing, I found that the use of NetWare's System attribute prohibited viral infection. The Execute Only attribute will prohibit infection, but the problem is that it often prohibits file execution as well. This side affect is documented in the NetWare manuals. Rights security provides substantial protection against malicious software. Viruses cannot directly alter assigned effective rights. I recently presented a paper on virus protection to a group of network administrators. Most if not all of these people relied on the Read Only ATTRIBUTE to protect files. This measure is just as ineffective as setting the DOS Read Only file attribute. Most parasitic viruses simply alter these bits before infection. - ------------------------------------------------------------------------------- Kevin Hemsley | Information & Technical Security | If you think that you have someone Idaho National Engineering Laboratory | eating out of your hand, it's a (208) 526-9322 | good idea to count your fingers! kev@inel.gov | - ------------------------------------------------------------------------------- ------------------------------ Date: Tue, 24 Sep 91 18:17:00 +0100 >From: "Olivier M.J. Crepin-Leblond" Subject: Re: More info on Compuserve Accidentally Distributing Viruses (PC) [...] >The following is the statement now being carried on the >CompuServe VIRUSFORUM: [...] > Accordingly, we are urging all 9 people who >downloaded this file to contact McAfee Associates for >instructions or assistance. [...] Doesn't CompuServe or McAfee Associates keep track of identity of uploads and downloads ? I'm surprised that the people who downloaded the file were not contacted directly after finding their account nr. in a log file of some sort. Olivier M.J. Crepin-Leblond, Research Student, Elec. Eng. Dept. Imperial College of Science, Technology and Medicine, London, UK. ------------------------------ Date: Tue, 24 Sep 91 18:48:16 +0000 >From: gary@sci34hub.sci.com (Gary Heston) Subject: Re: BIOS Viruses (PC) privsec!guillory@uunet.UU.NET (guillory) writes: = [ ... ] =Last night I was reading my most recent PC Magazine. In an article =titled "50-MHZ 486 Debuts in Dell Powerline File Server" discuses end =users upgrading system BIOSes by floppy disks. Quoting from the =article: "The Powerline 450SE also features a proprietary firmware =system that uses Intel Flash memory to store the system BIOS. In the =future users will be able to upgrade system BIOS by installing a new =file from a floppy disk." The concept is old, it's just finally being applied to PCs. =The one thing you could always trust to be safe from viruses was the =system BIOS. Can this be exploited by virus writers? If so, how long =before they do? Yes it could be exploited; it probably never will, though. Consider: This is a high-end machine being discussed. Dell will probably sell 10-15,000 of these next year. Contrast this with the number of '286, '386, and '386sx systems they're producing--probably shipping 10-15,000 of these per MONTH, not per year. Not to mention all the other clone vendors cranking out these commodity systems. What propagation would a virus that only targeted a tiny fraction of a percent of the systems out there have? None, I think. Before you worry about other vendors implementing reprogrammable BIOS memories, I'd almost guarantee that all of the hardware designs will be different, so a virus would have to be written for *EACH* design. A tiny fraction of a tiny fraction would propagate these viruses. Don't expect to see this feature on commodity machines, either--the EEPROM chips cost substantually more than EPROMS, not to mention the extra circuitry to support the reprogramming mode. The only hazard I see here is malice on the part of a vendor employee, which would be very difficult to guard against. I'd want a way to make a BIOS restore disc that would include the necessary reprogramming code, and would let me save the existing contents of the BIOS chips to it for disaster recovery purposes. I'd also have the basic boot-from-floppy code in an EPROM, where it could never get tampered with. This feature is nothing to worry about. - -- Gary Heston System Mismanager and technoflunky uunet!sci34hub!gary or My opinions, not theirs. SCI Systems, Inc. gary@sci34hub.sci.com Become a pheresis donor. Loan your blood to the Red Cross for a couple of hours. They, and cancer patients, will appreciate it. ------------------------------ Date: 24 Sep 91 12:29:00 -0500 >From: "William Walker C60223 x4570" Subject: Re: Comment Please excuse the non-virus-related topic. I just feel that this needs to be presented. >From: Ray.Mann@ofa123.fidonet.org (Ray Mann): > Since the moderator has approved the postings, we must assume they > meet his guidelines for suitable material. I'm just wondering if all > that "judgmentarism" is really necessary. It detracts from the > decorum of this professional newsgroup. > I believe all issues in this discussion could be exhausted without > the frequent injection of personality we are receiving from [any of > several people], who seems otherwise sincere and well-informed... [changed to be general rather than about one person - WWW] Well, we've got to have SOME personality in our postings, lest we lose our individuality, opinions, and possibly ideas that we express here. But, we have to limit HOW MUCH personality goes into our postings before we stomp on someone else's individuality, opinions, and ideas. If someone disagrees with something, he should provide legitimate reasons for disagreeing with it, and provide them in a way which would allow the reader to evaluate them for himself, not force-feed them to the reader. Recently, however, there's been a lot of "That's really stupid" or "That's totally useless," with little else to accompany the flaming opinions. Instead, writers should write, "I don't think that [something] is a good idea because..." or "Because of [reason], [something] cannot be used for..." Borrowing from comp.risks may be a cop-out, but the following posting just might be valuable to someone. >From: bill@tuatara.uofs.edu (Bill Gunshannon) [RISKS-12.32]: > I believe that the apparent hot-headedness seen in Email, BBSes and > USENET are only signs of an immature communications media and do not > accurately reflect what we can expect in the future. > My own experience tends to bear this out. When I was first > introduced to USENET and NEWS, in 1982, I was very quick to flame > people for the slightest remark with which I didn't agree. Today, if > I come across something that I feel requires a response, I save the > offending message and give the whole thing some thought. Somewhat > akin to stopping to count to 10. In 95% of the cases, I then decide > it isn't worth raising my blood pressure about and throw the article > away. My experience is similar. What I do (now) is download the article from the VAX to my PC, edit a reply, upload my reply, and send it off. This allows me to cool off (if necessary), and edit out the "heat." Also, the increased trouble of the process (over simply typing REPLY) makes me decide if the reply is really worth the trouble. Sure, I've disagreed with stuff posted here, and people have disagreed with my stuff, too. So what? People are gonna disagree. As long as we remain calm and polite, we can intelligently exchange information, ideas, and opinions. Finally, as Ken writes in the introduction to VIRUS-L: > One thing to bear in mind when sending a message to this (or any) > public forum is that you have a potentially *very* large audience - > this group is read by an estimated 10000-20000 people around the > globe. As such, it is advisable to be particularly careful about how > you word things. - - - - - - - - - - - And now for something completely different... >From: turtle@darkside.com (Fred Waller): > ... Considering that the author of the article [me - WWW] > seems to have military affiliation, one is surprised that, in his > search for theoretical justification, he was attracted by medical, > rather than martial, theory. When I was in college, I was studying medicine before I switched to studying computers. Perhaps that's why I like studying anti-virus measures. As for my military affiliation, the Air Force pays the contractor, the contractor pays the subcontractor, and the subcontractor pays me. That's about the extent of it. If my opinions are those of the Air Force, then that's an unfortunate coincidence. :-) Bill Walker ( WALKER@AEDC-VAX.AF.MIL ) | "If 'pro-' is the opposite of OAO Corporation | 'con-,' then is 'progress' the Arnold Engineering Development Center | opposite of 'Congress?'" M.S. 120 | - Gallagher Arnold Air Force Base, TN 37389-9998 | ------------------------------ End of VIRUS-L Digest [Volume 4 Issue 173] ****************************************** Downloaded From P-80 International Information Systems 304-744-2253