VIRUS-L Digest Thursday, 26 Sep 1991 Volume 4 : Issue 174
Today's Topics:
Virus Scanner Test Info Required (PC)
Procedures Involving Potential Virus Files (IBM VM/CMS)
desouza or souza virus (PC)
re: Precise identification (PC) Reaction and Philosophy
Re: Novell
Various
SITELOCK (PC)
re: Precise identifications
Re: Possible Autocad virus (PC)
Wanted : a utility to warn me when I'm accessing a removable disk (PC)
Re: Procedures Involving Potential Virus Files (IBM VM/CMS)
Re: Need Info on Integrity Shells
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: Wed, 25 Sep 91 11:35:00
>From:
[email protected]
Subject: Virus Scanner Test Info Required (PC)
I don't want to start any flames about the efficiency or otherwise of
different virus scanners, but has anyone tested a range of products to
determine just how good they are? In particular, I am interested in a
comparison between McAfee's products and VirusBuster. We are
prohibited from using McAfee's products as the site licence was too
expensive and must now use VirusBuster.
If anyone has tested these two products, I would welcome your
comments. If you post directly to me, I will summarize for the
newsgroup.
[Ed. Have you taken a look at the reviews that have been posted to the
group? They're archived on the anonymous FTP on cert.sei.cmu.edu in
pub/virus-l/docs/reviews]
Thanks,
David White.
Department of Chemical Engineering
Curtin University
Bentley,
Western Australia.
------------------------------
Date: Wed, 25 Sep 91 09:05:03 -0500
>From: Ron Wigmore <
[email protected]>
Subject: Procedures Involving Potential Virus Files (IBM VM/CMS)
Relax! This is just a request for 'policy' information! :-)
We have RSCSV3 checking for files that may be potential viruses (such
as CHRISTMA exec, etc.). We just had someone try to send such an exec
out. As it turns out, the exec is harmless and the user just picked
a bad name for his exec.
What do other sites do at this point? Do you just discard the file,
with or without telling the user? Do you rename the file and send it
on off to its original destination.
Do you tell the people on your system that files of a certain filename
and filetype cannot be sent out over the network? This is the main
stumbling point. If you tell the users which filenames/types cannot be
sent out over the network, then anyone wanting to cause some trouble will
just rename the file and then send it out - defeating the reason for
checking for specific files in the first place.
How do other sites handle these matters?
Reply via email if this is a 'sensitive' topic.
Ron,,,
------------------------------
Date: Wed, 25 Sep 91 08:44:00 -0500
>From:
[email protected]
Subject: desouza or souza virus (PC)
Two faculty here at UWSP have reported that their home PC's have been
infected with the "desouza" or "souza" virus. I looked through FPROT
2.0's list of virus information, but could not locate a reference to
either name.
I have not yet gone to their homes to try to use FPROT 2.0 to clean
their disks. I might find out at that time that these are known
viruses and will be easly cleaned. But, wanted to ask ahead of time
if anyone knows of viruses with these names.
Thanks,
Tom Neuhauser
[email protected]
Information Technology, University of Wisconsin, Stevens Point, WI
------------------------------
Date: Wed, 25 Sep 91 11:18:42 -0400
>From: padgett%
[email protected] (A. Padgett Peterson)
Subject: re: Precise identification (PC) Reaction and Philosophy
>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.
I do not know how the preceeding garble (from issue 173) occurred but it
destroyed the meaning of the posting.
The concept presented was to consider a PC divided into two partitions:
one locked from writing and containing only executables. the other
writable but not executable. There could be provision for an executable/
writable partition as well for development. Updates of the executable/
unwritable area would be accomplished via user disrection with a special
command format.
This is not a pipe dream, I have been using something similar for some time.
It is done with software. Being software, it is breakable, but being PC
specific, generic software to break it would have to be very complex -
far beyond the level of sophistication seen in malicious software thusfar.
It would take an intruder some time to capture enough data to bypass
manually and resonable procedure on the part of the user is enough
to reduce this risk.
Add in a secure BIOS, prevention of the three-finger-salute, and a good
integrity manager and you have reduced risk to the point where any
increase in protection would be lost in the noise.
Padgett
ps I am getting tired of hearing why things will not work in some
obscure instance, e.g. a Ferrari makes a poor dump truck. The
simple fact is that use of ANY commercial anti-viral utility
(and many non-commercial) puts a user way out beyond the third sigma
in liklyhood of a damaging infection.
------------------------------
Date: Wed, 25 Sep 91 11:49:38 -0600
>From:
[email protected] (Kevin Hemsley)
Subject: Re: Novell
In VIRUS-L Volume 4 : Issue 17, I wrote:
> 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.
In a personal reply, Steven Klepzig <
[email protected]> wrote:
> Hello there. I read your post to the VIRUS-L list with interest. I can't
> believe that anyone would actually trust just the file attributes to protect
> a network. Even I saw the folly of that one! We definitely use the Netware
I think that I may have been a bit misleading in my comment. The
network administrators that I spoke with did use rights, but they felt
that within the directories they had given access to, use of the Read
Only attribute would prevent viral infection. I have found that many
"computer professionals" have ingored viruses until they experienced a
problem. Those which have not really considered what viruses truly
are, often make obvious mistakes such as this. I have had degreed
professionals ask me if viruses are some kind of "freak of nature,"
like a program gone mad or something. So I continue on my trek of
educating users and support employees about the realities of viruses,
hopefully eliminating false conceptions and undue paranoia.
-
-------------------------------------------------------------------------------
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: 25 Sep 91 13:37:01 -0400
>From: "David.M.Chess" <
[email protected]>
Subject: Various
Back from vacation, and just finished reading all the back VIRUS-L's.
Good discussion going on! A few random comments on some of the
threads (I apologize for not including citations for what I'm
replying to):
On IBM's scanner having strings in clear: I have seen at least
one sample in which two tiny changes were made, one of which
was in the middle of one of our signatures. The sample came
to us very indirectly, though, and it wasn't clear whether it had
been found in the wild, or prepared specially by someone out to
prove a point. We've never seen that particular variant again,
so it was probably a "lab specimen". IBM's scanner now has
a certain amount of "mutant detection" on by default, so it's
a bit harder to produce a tiny variant that will go undetected.
The need for verifiers: If the typical incident involved detecting
an infected object (program, diskette) before it was used (run,
booted from), I would tend to agree that verifying the exact
identity of the virus would be of secondary interest (possibly
interesting to trace spread, but not of vital interest to the
user). Of course, if that were the case, viruses would cease
to be a problem shortly thereafter! As it is, the typical
incident involves finding that a system is infected, and has
been for at least a little while. Given that, it's vital to
know exactly what virus you're dealing with, because you have
to know what things may have been damaged (subtly or otherwise),
and require repair. I wish exact identification weren't needed,
but I fear that it is! At least at the moment. (I've just
written a paper on the verification tools we currently use;
I'll be posting or publishing it somewhere before too long.)
Hardware and Software: Even the ideal combination of hardware
and software doesn't make viruses completely impossible. As
Cohen and others have shown, a virus can be written for even
a protected system that is correctly set up and, as long as (roughly)
some users can write to programs that others can execute, it
can spread. Now this may be of only theoretical interest, in
that such a virus might never actually become a problem (spreading
too slowly to become pervasive in any real environment), but
it's worth remembering that *any* search for _perfect_ protection
is almost certainly doomed, and we have to look for "good enough".
Integrity shells: The only one I know of is Cohen's own. I
think it's called "ASP", but I fear I don't have any contact
info. Fred is not on the net (and proud of it, hehe!).
DC
------------------------------
Date: Wed, 25 Sep 91 12:51:06 -0500
>From: BJ Watts <
[email protected]>
Subject: SITELOCK (PC)
Hello,
I don't know if anyone has really mentioned anything about SITELOCK
lately, but I am disappointed with it so far. We have a 100 PC Novell
Network with EtherNet and Token Ring configurations. The problems
that we have been having is that after LockSetting a program, when
another user tries to access that particular program after the limit
is used, the pc's tend to hang up. After call Bright Works, they sent
us another release 3.10 and it still does the same things, just not as
often. I was wondering if anyone has used SITELOCK and if anyone has
had any problems with it. Any comments or answers would very much be
appreciated. Thanks.
________________________________ ____________________________________
: : :
: BJ Watts : :
: BITNET:
[email protected] : How do girls get minks? :
: INTERNET:
[email protected] : The same way minks get minks. :
: The University of Alabama : :
:________________________________:____________________________________:
------------------------------
Date: Wed, 25 Sep 91 12:38:48 -0400
>From: padgett%
[email protected] (A. Padgett Peterson)
Subject: re: Precise identifications
>From:
[email protected] (Fred Waller)
> 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.
That comes under the heading of "bottom duck". If every PC in our
organization looked exacly like mine, I'd have to go back to honest
work (not entirely without merit) and I could start getting more than
four hours sleep a night.
Given a 10,000 user community and a bad economy you don't always get your
way even if it is right (see "Atlas Shrugged" by Ayn Rand).
Excrement happens, and I have to be ready to deal with ongoing
situationns not just tell people "if you had only...". When a virus
appears (and they do knock at the door with disturbing regularity) I
want to know:
1) What is it
2) How did it get here
3) How do we close that door without offending the users
Part of this is the ability to get a fast, reasonably accurate fix on
the "what" so that we know how to deal with it. Scanners pay a big
part in th "what" to determine the scope of the danger.
Try sitting in a control room at 2 a.m. with a couple of VPs waiting
to find out if you are going to shut their production line down to
isolate a problem before you denounce SCANers as a valuable tool. In
the real world today, taking down a 2000 node network because the
Jerusalem or one of its clones has gotten loose is not something done
lightly.
The fact is that we are all still learning how to cope. I have been
fortunate (?) enough to experience some real "interesting" cases that
are simple to say "well, what we should have done was..." now but it
was the "first time" then. LANs are the real threat today. It is
nearly impossible to manage thousands of clients, often in remote
areas and owned by outsiders "by the book" - and we are still writing
the book.
In short, there probably is not "one true solution". We are imperfect
and we make mistakes, but when someone shouts "FIRE" there is not time
to say "this can't be happening", it's time to find every available
water line & hope for overkill - the alternative is worse.
Padgett
------------------------------
Date: Wed, 25 Sep 91 19:22:00 -0500
>From: Big fish man on hippocampus <
[email protected]>
Subject: Re: Possible Autocad virus (PC)
BBROWN%
[email protected] (Bob Brown) writes:
> Has anyone heard of a virus that infects Autocad and pops up an alien
> who moves his mouth for appr. 1 second and then dissappears? We tried
> using scanv80 and IBM's virscan, but neither could find an infection.
> Has anyone else seen this or have ideas?
AutoCad compiles and runs an AutoLisp program when it calls up a
drawing. It would be possible to program some kind of animation
sequence in it. If you want to check it out, copy the acad.lsp file
from the installation disk into your autocad directory and run
autocad. Of course this will overwrite any "macros" or other programs
or subroutines you might have had in the acad.lsp so you might want to
rename/copy the file first.
- --
|\ \\\\__ Tony Maimer __
| \_/ o \ / |
> _ (( <_ / |
| / \__+___/
[email protected] /o /_/|
|/ |/ < )) _ <
\ \ \|
\ |
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
------------------------------
Date: Thu, 26 Sep 91 10:26:41 +0000
>From:
[email protected] (Nick Stephen)
Subject: Wanted : a utility to warn me when I'm accessing a removable disk (PC)
Hi
Whilst I've been reading these groups for some time, I've never seen
mention of a utility which prevents me from accessing a removable disk
unless I type some command or response allowing me access to a floppy
drive. Does such a thing exist?
I would like it so that I do not need to have something like vshield
resident, but instead the computer reminds me to run a scan program
over any floppy that I put into my drive *before* I access it in any
other way.
Ideally, the program could recognise when a first access to a
removable media is made and prompt for an 'are you sure' or even
simply return a 'general failure' or similar error. Once the disk was
accepted (reply 'y' to the prompt) the drive would be accessed
normally until the media was removed, whereupon the process could be
repeated when a new disk is accessed.
Installing something using multiple disks could be done by either
replying 'y' to the 'are you sure' message for each new disk, or
running an 'acceptA' program which disables the checking. I believe
that on a humble XT such as mine, the 'media changed' flag doesn't
work properly, so this TSR could only easily fire the once, upon the
first floppy access. After that, it could assume that I was alert
enough to run scan on any suspect floppies I was about to introduce
until the next reboot!
I don't know enough about the internals of a PC to write such a TSR,
but I do know enough about programming to know it shouldn't be that
hard to someone who DOES know!
Is there anything out there that already does this? If so, is it on a
mail server somewhere, or could someone email me a copy as I don't
have FTP access across to the USA :(
Many thanks in advance,
Nick
------------------------------
Date: Wed, 25 Sep 91 15:22:30 -0400
>From: "Steven P. Roder" <
[email protected]>
Subject: Re: Procedures Involving Potential Virus Files (IBM VM/CMS)
On Wed, 25 Sep 1991 09:05:03 EST Ron Wigmore said:
>Relax! This is just a request for 'policy' information! :-)
>
>We have RSCSV3 checking for files that may be potential viruses (such
>as CHRISTMA exec, etc.). We just had someone try to send such an exec
>out. As it turns out, the exec is harmless and the user just picked
>a bad name for his exec.
>
>What do other sites do at this point? Do you just discard the file,
>with or without telling the user? Do you rename the file and send it
>on off to its original destination.
>
>Do you tell the people on your system that files of a certain filename
>and filetype cannot be sent out over the network? This is the main
>stumbling point. If you tell the users which filenames/types cannot be
>sent out over the network, then anyone wanting to cause some trouble will
>just rename the file and then send it out - defeating the reason for
>checking for specific files in the first place.
>
>How do other sites handle these matters?
Ron,
We are running the Selective File Filter package on RSCS 3.1
here. I have the first 10 copies of the file (e.g. CHRISTMA EXEC)
sent to my userid, and any subsequent copies are purged. We do not
advertise the names of the files we are filtering. Sending them to my
ID allows me to see what the file is or does. If we were to make a
policy of not allowing any files of filetype EXEC or MDOULE to be sent
out, then we would publish it. We are not doing this, since it seems
like overkill.
Hope this helps.
Steve
------------------------------
Date: Tue, 24 Sep 91 18:05:00 +0300
>From: Y. Radai <
[email protected]>
Subject: Re: Need Info on Integrity Shells
Steve Albrecht writes:
>In his article "A Cost Analysis of Typical Computer Viruses and
>Defenses", Dr. Fred Cohen speaks of "integrity shells...command
>interpreters that look for changes in interpreted information before
>interpreting it".
>
>What commercial products, shareware, or public domain software
>falls into this category? I know of plenty of products which fall
>into Dr. Cohen's other three categories (scanners, monitors, and
>cryptographic checksums), but cannot locate an "integrity shell".
An example of an integrity shell is Cohen's own commercial product,
ASP (Advanced Systems Protection). I first heard of it two years
ago. I presume it's still available, though I'm not sure. (I've
never used it, so I can't comment on how good it is.)
What I know of integrity shells (a la Cohen) comes mainly from
glancing through his book _A Short Course on Computer Viruses_ while I
was at the VB Virus Conference a couple of weeks ago. I found a lot
of interesting information in it that I've never seen in any other
book on viruses, and it's the only one I feel tempted to buy. However,
it seems to me that an integrity shell would be entirely at the mercy
of stealth viruses. Yet unless I overlooked something in the short
time I had to look at the book (my apologies to Cohen if I did), his
book contains absolutely no discussion of this important threat. And
in general, it seems to me that the book omits several more very
relevant topics, and (imho) contains a few outright errors. Still,
on the whole I recommend the book, if not the software.
Y. Radai
Hebrew Univ. of Jerusalem, Israel
[email protected]
[email protected]
------------------------------
End of VIRUS-L Digest [Volume 4 Issue 174]
******************************************
Downloaded From P-80 International Information Systems 304-744-2253
