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
[email protected] (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:
[email protected].
Ken van Wyk
----------------------------------------------------------------------
Date: Mon, 23 Sep 91 21:04:33 +0000
>From:
[email protected] (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.
- --
[email protected] |Wes Morgan, not speaking for| ....!ukma!ukecc!morgan
[email protected] |the University of Kentucky's| morgan%engr.uky.edu@UKCC
[email protected] |Engineering Computing Center|
[email protected]
------------------------------
Date: Tue, 24 Sep 91 14:45:31 +0000
>From: dana%
[email protected] (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
[email protected] University of California, Berkeley
------------------------------
Date: Tue, 24 Sep 91 11:07:04 -0400
>From: padgett%
[email protected] (A. Padgett Peterson)
Subject: re: Boot variations (PC)
>From:
[email protected] (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%
[email protected] (A. Padgett Peterson)
Subject: Precise identification (PC) Reaction and Philosophy
>From:
[email protected] (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 <grin>).
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) <
[email protected]>
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%
[email protected] (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:
[email protected] (Fred Waller)
Subject: Precise identifications
Writes padgett%
[email protected] (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:
[email protected] (Fred Waller)
Subject: Software protection?
Writes
[email protected] (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:
[email protected] (Fred Waller)
Subject: Infectable Areas (PC)
Writes
[email protected] (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:
[email protected] (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 :
[email protected]
- ----------------------------------------------------------------------------
------------------------------
Date: Tue, 24 Sep 91 10:06:15 -0600
>From:
[email protected] (Kevin Hemsley)
Subject: Re: Various (PC) (Novell)
In VIRUS-L V4 #171 Steven R. Klepzig (
[email protected]) 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!
[email protected] |
-
-------------------------------------------------------------------------------
------------------------------
Date: Tue, 24 Sep 91 18:17:00 +0100
>From: "Olivier M.J. Crepin-Leblond" <
[email protected]>
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:
[email protected] (Gary Heston)
Subject: Re: BIOS Viruses (PC)
[email protected] (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.
[email protected]
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" <
[email protected]>
Subject: Re: Comment
Please excuse the non-virus-related topic. I just feel that this
needs to be presented.
>From:
[email protected] (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:
[email protected] (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:
[email protected] (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 (
[email protected] ) | "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
