VIRUS-L Digest Thursday, 31 Oct 1991 Volume 4 : Issue 205
Today's Topics:
Only Scan Floppies? (PC)
Jerusalem Virus info wanted (PC)
suspicious boot sectors (PC)
Re: McAfee84 fails to remove Cascade (PC)
Hardware forever!
Re: UNIX anti-virus program (UNIX)
found 10/31/91 in fido virus echomail (PC)
McAfee84 failed to remove Joshi (was Re: McAfee84 fails to remove Cascade (PC))
Running circles around (PC)
Re: Request for Standards
Re: Questions about VIRLIST.TXT (PC)
Re: VSHIELD.... (PC)
UNIX virus checker (UNIX)
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: 30 Oct 91 19:43:59 +0000
>From:
[email protected] (Jesse Chisholm AAC-RjesseD)
Subject: Only Scan Floppies? (PC)
Question: of the various TSRs that check programs before I execute
or copy them, do any allow me to only check those coming from a floppy?
Reason being a performance degradation issue. Floppies are slow
anyway and adding the time to scan the file is a very small percentage.
But adding the time to a hard disk access is a larger percentage
(though I admit still small) and not really necessary as I checked
my hard disk thoroughly at boot up time.
Thanks ahead of time.
Jesse Chisholm | Disclaimer: My opinions are rarely understood, let
[email protected] | tel: 1-408-432-6200 | alone held, by this company.
[email protected] | fax: 1-408-435-8517 |-----------------------------
======== This company has officially disavowed all knowledge of my opinions.
- --
"I woke up one morning, October 23rd.
Riding the range with the 2-U herd.
Come a ti-yi-yippy-yippy-ay yippy-ay.
Come a ti-yi-yippy-yippy-ay." -- from an old song, "The Chisholm Trail"
------------------------------
Date: Wed, 30 Oct 91 22:04:40 +0000
>From:
[email protected] (Scott Truesdell)
Subject: Jerusalem Virus info wanted (PC)
I take care of mostly Macintoshes but I also have a lab of 35
stand-alone (non-networked) MS-DOS Toshiba T-300's. They use a strange
disk format (I think it's single-sided, high-density).
Someone put one of these disks into another `real' MS-DOS machine with
normal drives and a virus alert program flagged the floppy as infected
with Jerusalem virus.
a) What is the Jerusalem virus and what are its effects?
b) How is the Jerusalem virus erradicated?
c) Is it possible that the strange disk format could be responsible
for confusing the virus detection utility?
Thanks,
Scott Truesdell
Lab Manager
ICS
U.C. Irvine
------------------------------
Date: Thu, 31 Oct 91 00:39:48 +0700
>From:
[email protected] (Fridrik Skulason)
Subject: suspicious boot sectors (PC)
I received a question by E-mail from Kyle Benger at WLU about my program
reporting a suspicious, "stoned"-like boot sector, but my replies seem
to bounce.
As I hope this information may be of interest to somebody else, I am just
posting the reply here.
- -frisk
- -------------
There are two (or three) possible explanations:
1) the disk was once infected, but the infected area was not fully
erased when the disk was disinfected, so some "suspicious"
bits of the virus are left (this happens when some disinfection
programs are used), so the scanner only finds a part of the virus
search string...this is not a real problem, as the disk is not really
infected - it can be ignored, but is annoying.
2) you have a new variant of the virus, or a totally new virus.
3) totally false alarm - highly unlikely in this case...
The easiest way to determine if there is a virus or not is simply (in this
particular case) to look at the memory size (reported by CHKDSK) If it is
full 640K (or 512 or whatever) you don't have a stoned-related boot sector
virus, but if there are some Kb suddenly missing.....well....
Of course, it is also possible to determine from a dump of the partition sector
if it is infected or not.
- -frisk
------------------------------
Date: Thu, 31 Oct 91 05:31:08 +0000
>From:
[email protected] (McAfee Associates)
Subject: Re: McAfee84 fails to remove Cascade (PC)
>McAfee fails to remove the Cascade 1701...
Hmm....
>I have just downloaded a series of anti-virus prog's from Garbo, and I
>also have access to some other programmes. When I found the Cascade
>1701 one some of the students' machines, I decided to test these
>utilities out. As the Cascade is an old and common virus, to say the
>least, it should be no match to the recognized virus programmes - or
>so I thought...
I would think so too. The 1701 is one of those older viruses that
pops up all the time.
>All programmes tested was able to detect the virus, but disinfecting
>proved to be far more difficult:
<some of message deleted>
>McAfee Clean 84 could not remove the virus, but offered to delete and
> wipe my infected files.
<more of message deleted>
Well, that's the message that CLEAN-UP gives when it can not safely
remove a virus without damaging the infected file. Reasons for this
could include that the virus has overwritten part of the file and
truncated it, or it is some kind of variant that CLEAN-UP does not
recognize.
>Finally, I would like a comment from McAfee, how is it possible that
>your programme is not able to disinfect such an old and well-known
>virus???
CLEAN-UP removes all samples of the 1701/1704 (alias Cascade) virus in
our library. I would suspect that you either have files that have
been damaged in some way or a variant of the virus that has been
modified in some way. If you can UUENCODE an infected file and send
it to me, or mail a disk with an infected file to the address in my
sig file below, I will pass it on to our programming staff for
analysis.
Regards,
Aryeh Goretsky
McAfee Associates Technical Support
- --
- - - -
McAfee Associates | Voice (408) 988-3832 |
[email protected] (business)
4423 Cheeney Street | FAX (408) 970-9727 |
[email protected](personal)
Santa Clara, California | BBS (408) 988-4004 |
95054-0253 USA | v.32 (408) 988-5190 | CompuServe ID: 76702,1714
ViruScan/CleanUp/VShield | HST (408) 988-5138 | or GO VIRUSFORUM
------------------------------
Date: Wed, 30 Oct 91 22:27:30 -0800
>From:
[email protected] (Fred Waller)
Subject: Hardware forever!
Writes
[email protected] (Arthur Gutowski):
> Hardware isn't absolutely necessary to solve the problem,
Hardware is not _absolutely_ necessary, but I hold that it is the
most practical, least expensive and most effective solution. It
is also one that will not require updating.
We must remember that runtime software can only exist as a
FUNCTION OF hardware, but the reverse is never true! Is the
inference clear? If not, then let me repeat: viruses and
antiviruses are but two expressions of the same symbolic
processes; there is no true precedence nor true ascendence
among them. Any precedence is based on (fickle) symbolic
convention, and not (strong) physical reality. Therefore, it
may be changed at will also by symbolic means as long as enough
ingenuity is applied towards doing so. Or, most importantly,
it can be changed *against* one's will by someone else - the
virus author. Always.
This leads to everlasting battle, endless waste of effort, ever
repeated threats, ever renewed defenses. No end in sight. None.
> if the OS has enough smarts (though it is a stronger
> determinant than software, in most cases).
If the OS has enough smarts? Such as what? The OS is software.
It can be subverted by software. Viruses are software. They can
subvert the OS, (if given hardware access to it). If not, they
cannot. Therefore, use hardware defenses to stop the attack.
It's simple.
In private mail, one correspondent was recently describing the
security of Unix, and how a safe OS resides in a higher "ring"
than the applications. He was telling me that since the CPU was
now operating in Protected Mode, it was impossible to bypass what
he termed this "hardware protection" (amazing how programmers
think). He didn't realize that anything one causes the CPU to do
with a software command, could be undone with a software command.
Protected mode, secure? Says who?
There is NO software defense that's fully reliable. There IS
hardware defense that is fully reliable. There is NO software
defense that is permanent. There IS hardware defense that is
permanent. Simply implemented, hardware defenses may lead to
uncomfortable computing. Intelligently implemented, they may
be both effective and tolerable to users.
> VM, MVS, and even Apple Systems, have more smarts built into them
than MESS-DOS. This is a factor that causes infection numbers to
look like they do.
I totally disagree with the reference to Apple Systems. I attribute
its ostensible virus resistance to: 1. low number of machines
installed and 2. secretiveness of the manufacturer re OS details.
> Also has to do with population and the types of people that work
> on these other systems. That's not to say that we'll never see
> an MVS virus, because it is quite possible, but it's a lot less
> likely to happen.
Well, I don't know. We have seen Unix worms issued in playful mood,
and I know of at least _some_ people who have played strange games
on VM and VMS systems... But I think the most important factor is
the number of machines, and the number of users. The 50-70 million
PCs out there are a unique _market_ for antiviruses - a tempting
one. The viruses seem to have just sprung up in the same market,
somehow.
> Yes, they should. Hardware and software can be used together to
> produce a more effective solution than hardware alone. As has
> been pointed out before, we do have ignorant operators.
Not more effective, if we define effectiveness as the ability to do
a job with a minimum investment and a maximum yield. But a hardware/
software combination _will_ allow loosening some restraints that
might make hardware-alone methods too severe.
> Mainframe OSes tend to keep their operations secret, much like
> Apple does. But, that's not to say that a good techie (like
> several we have around here), couldn't infiltrate the OS with
> a virus.
Quite agree with this, for reasons mentioned above.
> But global access to the OS or to all user files isn't necessary
> either. All that is required is *some* access.
Yes. And it need not be during normal, continued use of the system.
Updating of the OS, for example, is done at very infrequent
intervals. Surely we can institute very severe security procedures
during those infrequent times. I believe this use of the TIME
element has not been sufficiently contemplated among antiviral
measures and procedures. All we hear is people complaining about
how restricting the flow of data would cripple computing. But it
doesn't have to. We can maintain a pretty secure computing
environment, AND retain the ability to update programs, etc.,
only not at the same time!
> I am merely attempting to confront what you have admitted to
> as being sometimes- confrontational postings.
I reiterate my admission in this sense.
> The bursting flames, have, I think, subsided for the most
> part some time ago.
Things are rather more decorous now. Seems more of us may be
learning from Dave Chess' posts, who is giving lessons on how to
write like a gentleman while disagreeing with rabble-rousers
proposing strange hardware modifications... :-)
> When addressing an issue of import confrontationally, one should
> expect to see people who hold (even slightly) different views to
> react with a degree of confrontation as well.
Indeed one should. I should have been more aware of it.
With cordial wishes,
Fred (W.)
[email protected]
------------------------------
Date: 31 Oct 91 08:12:21 +0000
>From:
[email protected] (Tommy Pedersen)
Subject: Re: UNIX anti-virus program (UNIX)
[email protected] (Brian Schieber) writes:
>I'm looking for sources for virus checking for UNIX boxes. Whats available ?
TCell is a commercial UNIX virus checking program that the company I
work for has developed. It uses cryptographic checksums to check for
unexpected changes in the file system. Contact me and I'll tell you
more about it.
Regards,
- --
/Tommy Pedersen
______________________________________________________________________
|E-mail:
[email protected] /\ |
|S-mail: Tommy Pedersen / / Telephone: +46 13 235200 |
| SECTRA-Secure Transmission AB | | FAX: +46 13 212185 |
| Teknikringen 2 |.> |
| S-583 30 Linkoping |/ |
|_______ SWEDEN ______________________________________________________|
------------------------------
Date: Thu, 31 Oct 91 06:35:00 -0500
>From:
[email protected]
Subject: found 10/31/91 in fido virus echomail (PC)
I found the following two messages in the FIDO echomail dedicated to viruses I
received this morning (10/31/91).
- ----- begin forwarded messages --
To: All Message #: 3320
>From: Paul Ferguson Submitted: 29 Oct 91 22:47:00
Subject: 7th Son virus Status: Public
Received: No Group: VIRUS (30)
- ----------
Virus Name: Seventh Son (7th Son)
Type: Appending .COM infector
Eff. Length: 350 bytes
Comments: The Seventh Son virus was received from Europe and thought to
be authored in Italy. It is a direct-action, appending
infector of .COM files. When a file infected with the Seventh
Son is executed, it will infect all .COM files in the current
directory. Infected files will have a growth of 350 bytes
which is noticeable by performing a DIRectory listing. File
date/time stamps remain unchanged and infected files will not
become reinfected.
The following text strings can be found within infected files:
"Seventh son of a seventh son"
and
"*.COM"
No current scanner detects the virus, but Fridrick Skulasson's
"Analyze" option of F-Prot version 2.00 detects viral-like
coding.
The following scan string will detect the virus:
"B8 00 33 CD 21 52 32 D2 B8 01 33 CD 21 B8 24 35"
The virus does nothing beyond replicate.
-Paul
- ---
* Origin: Sentry Net BBS, Centreville, VA 703-815-3244 (1:109/229)
====================
To: All Message #: 3961
>From: Paul Ferguson Submitted: 30 Oct 91 14:18:00
Subject: Exterminator 2.0 Status: Public
Received: No Group: VIRUS (30)
Virus Name: Exterminator 2.0
Type: Direct Action, Overwriting .COM Infector
Eff. Length: 429 bytes
Comments: This virus is very much like the previous viruses in this
family (Exterminator 1.0, Badguy, Demon) except for the length
and the text contained within the virus:
"Exterminator 2.0 - (c) by Cracker Jack 1991 (IVRL)"
"Italian Virus Research Laboratory"
"(C) 1990,1991"
"Meassage to Virus Researchers: Vedo che non avete sequito il
mio consiglio!!"
"Adesso mi sono arrabbiato.........."
"Virix-Researchers Exterminator 2.0 (c) by Cracker Jack"
[Translation welcome.]
{Here comes: "I see that you did not follow my advice"
"Now I'm mad..." C. B.-H.}
As the virus code is 429 bytes, any file smaller than 429
bytes will have a resultant file size of 429 bytes. Files >
429 bytes will be overwritten at the end of the file. As with
the other viruses in this family, it's activation date is on
Mondays, at which time if it is activated, it will overwrite
the first 160 sectors of the C: drive.
Utilities that detect the other viruses in the family should
detect this one as well (ie SCANv84 detects it as [I-B] and
HTScan v1.16 detects it as Badguy-related)...
--------------------
Paul
- ---
* Origin: Sentry Net BBS, Centreville, VA 703-815-3244 (1:109/229)
- ----- end forwarded messages --
Regards, Claude.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Claude Bersano-Hayes HAYES @ URVAX (Vanilla BITNET)
University of Richmond
[email protected] (Bitnet or Internet)
Richmond, VA 23173
------------------------------
Date: 31 Oct 91 14:56:58 +0000
>From:
[email protected] (Steve Rikli)
Subject: McAfee84 failed to remove Joshi (was Re: McAfee84 fails to remove Casc
ade (PC))
[email protected] (Audun Bringsvor) writes:
>McAfee fails to remove the Cascade 1701...
>
>McAfee Clean 84 could not remove the virus, but offered to delete and
> wipe my infected files.
As the subject says, Clean v84 couldn't handle Joshi. It discovered
and claimed to clean it on an IBM PS2/30, but Scan discovered it
again. Repeated attempts failed.
Interestingly enough, Clean v76 DID handle Joshi on a CompuAdd '286.
I thought this was *really* strange.
- --
|| Steve Rikli ||| Visualization Lab ||
||
[email protected] ||| Texas A&M University ||
|| (409) 845-5691 ||| College Station, TX 77843-3137 ||
------------------------------
Date: Thu, 31 Oct 91 08:50:40 -0500
>From: padgett%
[email protected] (A. Padgett Peterson)
Subject: Running circles around (PC)
[email protected] (Robert Yung) writes:
> In the latest PC-MAG, it says that a device driver is better
>against certain viruses that can run circles around TSRs. Why not make
>Vshield a device driver? It certainly would have more memory to load
>into when it is the first loaded (that is after the memory driver).
(also responding to Aryeh's comment)
I believe the "running circles around" refers to execution speed
rather than effectiveness. Certainly, a lower level function *could*
be more efficient from this standpoint if repetitive disk operations
are performed. This is part of the reason I wrote DiskSecure to
operate "under" DOS - provides direct access to the BIOS and is not
subject to "undocumented" features. Peter Tippet told me that Certus'
NOVI now uses the same technique, certainly it appears to run very
fast.
Given that programs MUST begin on sector boundaries, it is possible
that a future SCANning technique (particularly when a scan of all
files is requested) might involve a direct examination of each cluster
with a file name track/ display only if something is found. Such a
program might first load the FAT and then "walk the FAT" for extra
speed. Given direct disk controller access and exact sector counts, on
a modern machine it could be quick enough to avoid the long coffee
breaks and limited validation we often use today.
On that subject, I wonder if the current crop of disk compression
routines (Stacker, SuperStor, etc.) might be using the same technique
- - certainly the speed has improved considerably recently - I am told
(need to try some RSN) that the algorithms are now good enough that
the time to compress/decompress is balanced by the reduced number of
sectors to be retrieved. Makes sense.
Of course use of compression like that might blow away scanners that
use BIOS to scan the disks since the retrieved data would still be
compressed. So the next. next generation scanner would have to be able
to determine if compression is in use.... Oh well, nice thought.
Padgett
------------------------------
Date: 31 Oct 91 15:25:20 +0000
>From:
[email protected] (Vesselin Bontchev)
Subject: Re: Request for Standards
[email protected] writes:
> studies, and (4) to focus on the user's point of view. The NCSA has
> also started a program to certify virus scanners against the NCSA
> collection (and quite a substantial collection it is). All of these
What? NCSA will test other people's scanners against their
collection?! God forbid, unless they have gained signifficant amount
of expertise recently. I'd like very much to see someone form the NCSA
to comment this.
We received a copy of their so-called collection here at the VTC. I
consisted of 1775 files, which were even not named, but numbered! They
contained several files, infected by one and the same virus;
self-comressed files with and without viruses; legitimate programs
(even one copy of a perfectly clean CHKDSK); etc. All this was
distributed in several directories, the contents of each directory was
ZIPed, and all the ZIP files were ZIPed together. At last, the whole
thing was PCBACKUPed on a (huge) set of 3.5" diskettes. We needed
about 30 Mb of disk space only to unpack the stuff - and this only to
discover that a large part of it is just a mess.
I seriously doubt that those, who call this mess "virus collection"
have the necessary expertise to do reliable and careful testing of
ant-virus products. Unless, of course, if they have gained more
insight recently, what I would be happy to learn.
Regards,
Vesselin
P.S. The oppinions expressed above are my own (since I was the person,
who had to unpack and look at the so-called "virus collection") and
not necessarily those of the VTC Hamburg (although I won't be surpised
very much to find that they agree with me...).
------------------------------
Date: 31 Oct 91 15:06:05 +0000
>From:
[email protected] (Vesselin Bontchev)
Subject: Re: Questions about VIRLIST.TXT (PC)
[email protected] (Raul Fernando Weber) writes:
> I am trying to plot some curves about viruses grown and, among other
> sources, I use the file VIRLIST.TXT that cames with McAffe's package.
Well, you're wrong, IMHO. VIRLIST.TXT is certainly the less reliable
part of McAfee's product... :-( It contains a lot of error, typos,
wrong number fo variants, names that are never reported by SCAN (and
even do not exist in its internal signature database), wrong
descriptions of viruses, etc. However, I guess that for most users it
does not matter how many viruses the scanner detects exactly, if it is
able to detect all viruses that attack -their- computers. Also, SCAN
is updated very regularly, in an attempt to at least try to keep
up-to-date with the virus wave. Don't rely on it for exact
information, however.
> However, adding each virus individually (and their variants) doesn't
> match the total supplied in the file. Here are the numbers I got:
Guess that the person who compiled VIRLIST.TXT never had the idea to
make this comparison... :-)
> Particularly interesting is the difference that occurs
> with version 80 of VIRLIST.TXT. In the file the total is
> 714, but I got 675. The difference (39) is too big when
> compared with those from the other versions (about 5).
> Examining the list carefully I discover a great growing of
> Whale variants (from 3 to 34). I wonder if this grown really
> exists or was a typo when replacing the 3 with a 4 :-).
> The number 34 for Whale remains the same in the next versions
> of VIRLIST.TXT (82 and 84). There are really so many variants
> for the Whale virus?
In fact, the Whale virus can mutate in 33 (not 34) different ways and
therefore can be detected by 33 different signature strings.
Obviously, this is the reason that McAfee counts it as 33 different
viruses... :-)
> Another related question is about viruses that appear in two forms:
> a "boot" and a "file" version. They are different viruses (with
> no other relations than the name) or are the to be interpreted
> as the same virus that is able to propagate using boot sectors
> and files? If this last hypothesis is true, why the Horse Boot,
> Invader and Virus-101 (all listed as able to infect boot sectors and
> files) aren't listed in the same way?
Well, I haven't meticulously check all the contents of VIRLIST.TXT,
but it's obviously so full of errors, that they creep in even when you
quote parts of it... :-) In this particular case, the Horse Boot virus
is a boot virus only, not a multi-partite one. I have supplied it to
the anti-virus researchers in original source form (I got it from its
author), and somebody of McAfee's people have compiled it to a COM
file (this is possible, although it will not work).
There are many other errors. For instance, the V800 virus is still
reported as causing no increase of file size (in fact, it increases
them by 800 bytes and even does not try to hide it), regardless of the
fact that I have reported this particular error several times.
The other parts of the documentation is not brilliant as well. For
instance in the latest version states about the Dir II virus that
"there is no current technique, short of reformat, to deal with this
virus", regardless of the fact that the virus has been discussed very
detailly on this net and an extremely simple technique, using only the
REN command (and optionally CHKDSK) has been proposed by a Polish
anti-virus researcher... :-(((
Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg
[email protected] Fachbereich Informatik - AGN
Tel.:+49-40-54715-224, Fax: -246 Vogt-Koeln-Strasse 30, D-2000, Hamburg 54
------------------------------
Date: 31 Oct 91 15:45:36 +0000
>From:
[email protected] (Vesselin Bontchev)
Subject: Re: VSHIELD.... (PC)
[email protected] (McAfee Associates) writes:
> disk caching programs buffer writes to the disk as well as reads. From
> our POV, buffering disk writes is a Bad Idea(tm). Here's why: If a
> computer was reset or turned off while there was something in the write
> buffer, it's contents would be irrevocably lost. This could havee all sorts
> of dangerous side effects, such as a file being left open, damage to the
> root directory or FAT, or other unpredictable nasty results. If you do
Well, it might be not that bad as idea, if it is implemented well...
For instance, if the cashe program detects that the sector being
written is the same as the one that has been recently read and is
still in the buffers, it might just not write it... Of course, all
this is pure speculation; I don't know how exactly this particular
cashe program (PC Kwik) works.
> VSHIELD V84 with the /LH switch requires a (approximately) 31Kb UMB. So
> about a third of the original size. The actual ~110Kb requirement was
> for VSHIELD to initialize its code prior to going resident, it would
> then "shrink back" to it's 30-whatever Kb size.
This reminds me of another thing. Why all current versions (84) of the
programs are self-compressed with PKLite, while VShield is
self-compressed with LZEXE?
Another question. Is there version 84 of VCopy?
> [SHRUG] I would think that a device driver would provide very little
> additional security, if any, compared to a TSR. I have not come across
> any virus that "ran circles" around our TSR-based program, I do think
> that VSHIELD did intercept all the viruses in their test suite, though.
Well, not exactly. If an on-the-fly scanner (like VShield) is
implemented as a device driver, instead of a TSR program, there is
much less probablility that a virus will infect it. Currently there
exists only 1 (one!) virus that is able to infect device drivers,
while there are several hundred others that are able to infect
executable files (COM and EXE, that is), regardless whether they are
TSR or not.
Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg
[email protected] Fachbereich Informatik - AGN
Tel.:+49-40-54715-224, Fax: -246 Vogt-Koeln-Strasse 30, D-2000, Hamburg 54
------------------------------
Date: Thu, 31 Oct 91 12:04:00 -0500
>From: <
[email protected]>
Subject: UNIX virus checker (UNIX)
At the UNIX Expo in New York, a company called CyberSoft was promoting
their UNIX virus checker called VFIND. This is the first I have heard
of such a product.
CyberSoft
210 West 12th Avenue
Conshohocken, PA 19428-1464
(215) 825-4748 FAX (215) 825-6785
Gordon
- ----------------------------------------------------------------------------
UNIX Lab Supervisor Academic Computing Services Fairfield University
- ----------------------------------------------------------------------------
------------------------------
End of VIRUS-L Digest [Volume 4 Issue 205]
******************************************
Downloaded From P-80 International Information Systems 304-744-2253
