VIRUS-L Digest Monday, 30 Sep 1991 Volume 4 : Issue 176
Today's Topics:
Re: precise identifications
Re: Perfect detectors
Re: Perfect detectors
Re: Encryptors and experience
Re: Scanning LZEXE and PKLITE files (PC)
Policy for Filters
NetWare (v. other servers)
New Virus Warning (PC)
Re: Infectable Areas (PC)
Re: Infectable Areas (PC)
Re: Precise identification (PC) Reaction and Philosophy
Stoned Virus - Thank You All (PC)
Re: Perfect detectors
F-Prot 2.0 (PC)
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: 26 Sep 91 19:39:04 +0000
>From:
[email protected] (Vesselin Bontchev)
Subject: Re: precise identifications
[email protected] (Fred Waller) writes:
> But the above conclusion is not strictly mine. It has been expressed
> many times before. Many writers have publicly questioned the wisdom
> of giving such intense publicity to computer viruses as the scanners
> provide by reason of their design, and to the use of colorful
> epithets that love to dwell on mythical, satanic and pathological
> meanings. As an example of such objections, none other than Dr.
This is true and I often use almost the same arguments, when I'm
trying to explain the people the the producers of anti-virus software
do not need to write and release viruses in order to promote their
programs. It is fully sufficient that they use the media hype. What
they often do, unfortunately... :-(
> Solomon, author of the well-known Dr. Solomon's Antivirus Toolkit,
> objected so much to this habit that at one time he refused to
> recognize any virus programs except by its byte length. The IBM
More exactly, he used the infective length of the viruses (as one of
their signifficant properties) to name them. He released this naming
scheme long time ago, when it turned out to be inappropriate. His
current version of the Toolkit uses a completely different naming
convention.
> corporation, surely not one to carry "unfounded flames against
> the anti-virus researchers", proposed to do the same thing. Many
Because it seems so "natural". :-) At that time almost all known
viruses had different infective lengths, and it was easy to see that a
file has increased in size.
> people have expressed the concern that all this "identification"
> the colorful naming, and the attendant publicity, were bound to
> challenge virus authors to produce ever-cleverer, ever-subtler
> viruses in quest of pathological glory. Well, it seems to have
> caused exactly that!
The question what exactly caused the increasing number of new viruses
can be argued ad infinitum without much use, so let's drop this
discussion.
> It is very hard to swallow this "computer virology". There is, of
> course, no such "science", nor is there any need of such. Computer
> viruses are one minor class of computer programs, and their study
> falls well within the field of computer science. Programming
Expert systems are just computer programs, but nevertheless, they are
considered as part of the Artificial Intelligence science and not of
the computer science. And not so longtimes ago, compiler writing was
considered a science too... I suggest that you read Aho & Uhlman's
book "Principles of Compiler Design".
> mathematics and in considerations of physics. There is no research
> involved - every single CPU instruction found in a virus program
> has been long known to the designers of the microcircuits and
> of the OS. No "discoveries" are needed. No "research". One can
The human genome consists of finite number of relatively well-known
atoms. Does this mean that trying to decrypt it leads to "no
discoveries" and involves "no research"?
> they agree to tell you. But let's not fool ourselves (or others)
> into thinking we are conducting "research" into some unknown natural
> phenomenon.
No, we're conducting research into a (relatively) well-known
artificial phenomenon.
> Viruses share most characteristics with conventional, non-replicating
> programs, and can be fully and completely studied in that context.
Yes, that's why it is
> In fact, at the most elementary level, it's impossible to separate
> virus programs from non-virus programs. Carrying the idea further,
> I quote F. Cohen (1990): "Please note that the 'DISKCOPY' program
> is a virus in the mathematical sense"(*). Some commercial programs
This indeed conforms with Cohen's definition of computer virus in the
broad sense, since he includes the user in the computer system. I
slightly disagree with him at this point, however, and I also have the
feeling that I am not alone... :-)
> have now started to implement viral techniques for "good" purposes,
> and are doing it quite well. All this, in turn, demonstrates the
> fallacy of wanting to create a separate "science" for the study of
> viruses.
If this is true, it proves that such science is really useful, since
it already beared some useful fruits. Can you tell however which
commercial programs use viral techniques? (By viral techniques I mean
self-replication, not the different hacker's tricks like interrupt
tracing that help the viruses to fool the anti-virus programs but have
nothing to do with the replication process.)
> Let us not confuse the commercial aims of antivirus software
> producers with the goals of scientific research. There is no
> "research" involved, only software publishing, of an admittedly
> useful and practical kind.
The purpose of the scientific research is to define the goals and the
effective ways to achieve them. Only when they are defined, come the
"practical" commercial implementations...
> I think we need a "computer virology" as much as we need a "computer
> wordprocessology" or a "computer filecompressology".
I may sound surprising, but even such practical things as writing a
good word processor or a fast and efficient file system involve a lot
of science. Think about the Boyer-Moore algorithm for fast string
search; the "dining philosophers" problem; and see my remark about the
compiler design above.
Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev Universitaet Hamburg, FB Informatik - AGN
[email protected] Schlueterstrasse 70, D-2000 Hamburg 13
New address after October 1, 1991: Vogt-Koelln-Strasse 30, D-2000, Hamburg 54
------------------------------
Date: Fri, 27 Sep 91 11:52:00 +1200
>From: "Mark Aitchison, U of Canty; Physics" <
[email protected]>
Subject: Re: Perfect detectors
[email protected] (Ray Mann) writes:
> However, there seems to be evidence that virus scanners are
> not really diminishing the virus threat. Several people pointed
> out that there's been a great =increase= in the total number of
> infected machines, and in the number of infections per machine
> since the scanners came out. Also, the total number of new viruses
> has increased dramatically...
>... It appears that viruses and antivirus utilities have
> more or less encouraged one another in time. What's especially
> notable is that most known viruses started to appear =after=
> the initial appearance of scanners.
>
> Anyone care to elaborate or make some comments on this?
There is probably something in that, but remember that the main virus
problems are coming from a quite small number of old viruses (written
when virus scanners weren't quite so much in the news), that have
simply had enough time to spread. There is a difference between
talking about "most known viruses" and "the viruses that are found
most often". In the future, perhaps, these many varied viruses may be
the big problem, but not at the moment.
I suspect that:
(a) The people with virus scanners are tending to stop viruses
spreading past them (the extent to which a scanner-only approach stops
further infection could be debated, of course). You might like to
think of a little boy with his finger in a hole of the dyke, but I
prefer to think of two or three people with closed doors on the
Titanic, hoping to stop the water come into their room.
(b) The viruses' real breeding ground is the many *MANY* more
computers without anti-virus measures. It spreads when it is quiet,
when the computer user not only doesn't know it is there, but when
there seems to reason to worry about anti-viral precautions. The most
successful viruses work mainly by ignorance on the part of the user,
rather than smart tricks to beat the greatest virus detectors. Think
of stoned - sure it is easy to spot, yet there are enough people with
no protection at all for it to spread in a big way.
(c) Reports of vast increases in viruses are only coming through after
the virus is noticed (when it delivers its payload, or spreads to a
scanned computer). That is the real problem: that viruses are allowed
to grow unrestrained, because a small percentage of users bother to
watch for them; the real size of the problem could be (and probably
is) much bigger than reported. To this extent, I would say that
reliance on scanners is failing: the present use of scanners is too
rare. Something (scanner or other protection) should be either built
into DOS or distributed for free. [Thinks: there are already free
virus detectors, yet only a small percentage of users have them or use
them properly, I wonder why?]
(d) All of this boils down to a great time for virus writers. There
might be some powerful psychology at work here, trying to beat
successive versions of virus scanner; that might account for a large
number of slightly different viruses, but probably not explain the
success of the old ones. I don't care if continual advances in
anti-virus techniques are seen as a challange by some people, I want
it to be *harder* for a virus to survive. It is simply that, at the
present, what we need most of all is NOT a fancier anti-virus tool
(unless it is so nice to use people use it more often), rather a
concerted attack on the relatively old viruses, even with old
software, but on almost all computers rather than only a handful of
them.
Now, all you need to do is to work out how to make that happen.
Mark Aitchison, University of Canterbury.
------------------------------
Date: Fri, 27 Sep 91 00:19:44 +0000
>From:
[email protected] (Morgan Schweers)
Subject: Re: Perfect detectors
Some time ago
[email protected] (Ray Mann) happily mumbled:
>A posting by
[email protected] (Albert Lunde) said:
>
> "As prior threads have illustrated, a "perfect virus detector"
> is in general impossible."
>
> That's a reasonable corollary of the premise that 'software
> cannot overcome software'..
Hmmm... Understand that that 'premise' can be reversed, and
you supposedly have a contradiction. (I.E. If 'good' software
cannot overcome 'bad', then the 'premise' above suggests that
'bad' software cannot overcome 'good'. Therein lies paradox.)
> more or less encouraged one another in time. What's especially
> notable is that most known viruses started to appear =after=
> the initial appearance of scanners.
>
> Anyone care to elaborate or make some comments on this?
Yeah, I'd like to. You're wrong. The most common viruses
(Stoned and Jerusalem) have been around well before all of the
currently existing scanners. Even the Disk Killer, Ping Pong,
and even the Dark Avenger were out well before the majority of
the present scanners came out. I think you might consider looking
into the history of the psuedo-industry before making general
comments like that.
Moreover, anti-virus programs are most certainly diminishing
the virus numbers. You can't state that they are *NOT* without
having an adequate comparison
-- Morgan Schweers
- --
[email protected] | Morgan Schweers | Happiness is the planet Earth in your
[email protected]| These messages | rear view mirror. -- Jeff Glass
Kilroy Balore | are not the +--------------------------------------
Freela | opinion of anyone.| I *AM* an AI. I'm not real...
------------------------------
Date: Fri, 27 Sep 91 01:13:29 +0000
>From:
[email protected] (Morgan Schweers)
Subject: Re: Encryptors and experience
Some time ago
[email protected] (Fred Waller) happily mumbled:
> Well, perhaps I have a little. Still, I'm not sure that one's assumed
> personal experience is relevant to someone else's judgement of that
> posting, but so be it. (But again I wonder: is it desirable, or
> necessary, to dwell on _ad hominem_ approaches here so much. What
> do they prove?)
Greetings,
Actually, it was more of an observation of your level of experience
with viruses. He's correct too, as I'll discuss later.
>
> My comment on Bill Arnold's post was that, in many cases, it's
> possible to use the virus itself to obtain decrypted code, since the
> virus is, obviously, the best degarbler for its own encryption. If
> one simply lets the virus decrypt itself to memory, the memory image
> is very frequently an excellent, easy source of decrypted code. Not
> always, and not in every case, but many times. Something similar
> to what some (including my commentator) do to obtain decrypted
> scanning strings...
This is such a bad idea, that I don't think you really mean it.
Frankly, exactly how would you go about doing this with a variable
encryption virus? How do you know if it *IS* the virus, so you can
call the decryption routine? What if its a virus which pretends
to be the said virus, and actually has code that does something
dangerous if executed out of its 'normal' location?
Sir, this statement shows that you *DO* have very very little
experience with encrypted viruses. I suggest that you do a bit of
research first, (and I have made that comment to you in the past)
before jumping in with both feet stuck firmly in your mouth.
> > Viruses with a highly mutating degarbler (like V2Px) cannot
> > be matched by a simple (or even wild-card) string and require
> > algorithmic approach.
>
> When Washburn's viruses first appeared, everybody simply accepted
> Washburn's statement that "only an algorithmic approach" could
> detect such viruses. This view was adopted by the experienced
> virus analysts, including Vesselin Vladimirov. At the time, all
> McAfee did was to look for 1260 bytes of added code and, if found,
> conclude that it was the 1260 virus. Some algorithm. So the 1260
False. 100% false. 1260 bytes of code added TO WHAT? Exactly
how would we *KNOW* that a file was infected to check the size
increase. Please, PLEASE think these things through. Your comment
showed that you are unfamiliar with the viruses described.
> virus did not seem so tough, but the variable-size V2P6s were
> another matter. Well-regarded antiviral packages, such as F-PROT,
> have trouble dealing with the V2P6 even today. Well, to make
> liars of us all (including Vesselin Vladimirov), Wasburn recently
> posted on McAfee's BBS a full set of search strings, with global
> characters, to detect the V2P6 virus! True, the strings were many,
> but there they were... if anyone wants them here, I'd be happy to
> repost Washburn's message (messages, actually: there was a series
> of them, each with 12 or so strings). From the horse's mouth, as
> it were.
The original concept, from 'The Horse's Mouth' was that it could
not be detected by *A* string. There is no such thing as a virus
which cannot be detected given any number of strings. Think about
it.
There is no difficulty with 'variable-size' viruses, it is the
variable ENCRYPTION which is difficult. This is where you clearly
show that you have not worked with these viruses, and is why I
support Vesselin's comments regarding your experience. You are
among professional anti-virus workers here. We have worked with
these viruses. I'm sure you have a realm of knowledge, in which
you are excellent. Please confine yourself to statements about
which you have knowledge.
>
> It's notable that the widely-experienced virus investigators, who
> claim to be more familiar with the V2Px viruses, the founders of
> "computer virology", were not themselves able to derive such
> essential information.
Nonsense. It simply takes more memory than the effecient
algorithmic approach we took.
>
> So, I apologize for my modest personal experience, and I'm sorry
> that it makes such a target for those with richer experience, but
> perhaps these widely-experienced persons might be somewhat more
> factual -and less personal- in their expressions? Second request.
Perhaps you might consider studying the facts, before making
untoward comments about the skills and personalities of the other
professionals on this forum.
-- Morgan Schweers
- --
[email protected] | Morgan Schweers | Happiness is the planet Earth in your
[email protected]| These messages | rear view mirror. -- Jeff Glass
Kilroy Balore | are not the +--------------------------------------
Freela | opinion of anyone.| I *AM* an AI. I'm not real...
------------------------------
Date: 26 Sep 91 19:23:45 +0000
>From:
[email protected] (Eric Backus)
Subject: Re: Scanning LZEXE and PKLITE files (PC)
>I'll try to remember to grab VirX to look at its documentation, but does
>anyone know of shareware/public-domain programs which have been
>compressed with a customized PKLite which I can play with?
You mean, besides pklite.exe itself?
- --
Eric Backus
ericb%
[email protected]
(206) 335-2495
------------------------------
Date: Fri, 27 Sep 91 01:09:00 -0400
>From:
[email protected]
Subject: Policy for Filters
>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.
My understanding is that IBM does exactly that. It arbitrarily changes
the file type on all executables, thus protecting the user from
inadvertantly executing a Trojan Horse program. Of course CHRISTMA was
able to spread wildly simply by inviting users to execute it, so
changing the file type will not protect the net from users, but it may
protect some users from the net.
I understand that IBM also arbitrarily throws away, without notice, any
file in the net that has a name that looks remotely like Christmas.
It is interesting that while propagation via the net is faster and more
disruptive than via diskette, it is less persistent. This is in part
because you have a place to stand to both filter and purge.
Spread in PC LANs involves the server, the workstation, and diskettes.
In addition, while it does offer a place to stand to filter, it does not
offer any place to stand to purge. Therefore, it tends to offer the
worst of both worlds. The virus spreads rapidly from diskette to
workstation to server to workstations to diskettes where it is difficult
to find and is otherwise persistent.
William Hugh Murray, Executive Consultant, Information System Security
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840
203 966 4769, WHMurray at DOCKMASTER.NCSC.MIL
------------------------------
Date: Fri, 27 Sep 91 01:23:00 -0400
>From:
[email protected]
Subject: NetWare (v. other servers)
The discussion here re: NetWare is not NetWare specific. Everything
said here is equally applicable to the other popular servers and
workstation shells.
I had a report from a system administrator that both his NetWare
server software and his Vines software were broken. He had configured
both to resist any user writing and yet files on both had become
infected. I suggested that while I might believe that one or the
other was broken, believing (before breakfast) that both were broken
was a little much. I suggested that it was far more likely that both
were misconfigured or that a supervisor had logged on to both from an
infected workstation. He assured me that one of the two swore that he
had not done so. The other admitted to having logged on but "he had
not executed any programs."
We deployed a thousand LANs today and created a thousand new
administrators. How many do you suppose understand how to configure a
server to resist the spread of viurses? How many even understand that
they cannot logon to a server without executing programs in the
workstation? How many understand that they should never logon to a
server from a workstation that they did not initialize from their own
known source?
Regards to all, Bill
William Hugh Murray, Executive Consultant, Information System Security
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840
203 966 4769, WHMurray at DOCKMASTER.NCSC.MIL
------------------------------
Date: Fri, 27 Sep 91 05:55:41 +0000
>From:
[email protected] (McAfee Associates)
Subject: New Virus Warning (PC)
This is a forwarded message from John McAfee...
- -------------------------
V I R U S W A R N I N G
A new, fast moving, and very destructive virus has been
reported from multiple countries in Eastern Europe. The virus uses
a completely new technique for infecting and replicating and it
cannot be easily identified or removed with existing anti-virus
removers.
The virus infects by first placing itself in the last cluster of
host disks. It then modifies the directory entries for all
executable files in the system so that the directory chains point
to the virus. Then it encrypts the original pointers for the
executable files and places the encrypted pointers in unused space
within the directory area. The result of this is that
whenever a program is executed, the virus is loaded into memory.
The virus, in turn, loads the program for execution. Programs
themselves are not modified.
A disruptive characteristic of this virus is that if an infected
system is booted from a clean floppy, none of the executable files
can be copied from the system. Neither can they be backed up. If
the system is not booted from a clean floppy, then the files can
be copied and backed up, but the virus will copied along with the
programs. It's a catch 22 situation. Additionally, if an infected
system is booted from a clean floppy, and then a CHKDSK /F
is run, then all executable files in the system will be destroyed.
The virus is also a stealth virus. While it is active in memory
it is difficult to detect.
The Virus has been named DIR-2. It has been reported at numerous
sites in Bulgaria, Poland, Yugoslavia and Hungary. We received our
copy for analysis from Tamas Szalay in Budapest.
The virus spreads more rapidly than any virus yet discovered.
Vesselin Bontchev in Bulgaria reports that it has become the most
reported virus in his country within the past few weeks.
We are currently re-writing our SCAN and CLEAN programs to deal
with this virus, as are most other anti-virus suppliers. A beta
version of both programs will be available September 26th. Anyone
reporting symptoms similar to the above described, please
contact us.
Thank you,
John McAfee
- --
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: 27 Sep 91 05:55:08 +0000
>From:
[email protected] (Vesselin Bontchev)
Subject: Re: Infectable Areas (PC)
[email protected] (Fred Waller) writes:
> 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.
Yes, indeed, I forgot to mention these... And some viruses (e.g., the
Flip-like ones) use to shorten a bit and existing partition, in order
to create space for their body.
> definition of what the Joshi, etc. does. And what should be the
> definition of the method used by DIR-2..?
My definition is: Dir II modifies the directory entries in such a way
that the executable files described in them -appear- to contain the
virus body.
> > 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.
I did. I know this very well and still think that it is a bad
approach. There are too many execfile compressors - should everybody's
scanner be able to cope with all of them? IMNSHO, we need a shell
program (a la Shez), that is able to unpack the compressed files and
to run a user supplied scanner on them.
Anyway, my original (and incorrect) claim was that as far as I know,
only VirX is able to scan inside both LZEXE'd and PKLite'd files. It
is the first program that was able to scan inside PKLite'd programs.
As Morgan Schweres pointed out, now SCAN is able to do it too. I'm not
quite sure about F-Prot, but know that Frisk intends to implement it.
Yet another useless thing that the anti-virus researchers are forced
to implement by their users... like the disinfection, for instance...
:-)
Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev Universitaet Hamburg, FB Informatik - AGN
[email protected] Schlueterstrasse 70, D-2000 Hamburg 13
New address after October 1, 1991: Vogt-Koelln-Strasse 30, D-2000, Hamburg 54
------------------------------
Date: 27 Sep 91 05:55:08 +0000
>From:
[email protected] (Vesselin Bontchev)
Subject: Re: Infectable Areas (PC)
[email protected] (Fred Waller) writes:
> 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.
Yes, indeed, I forgot to mention these... And some viruses (e.g., the
Flip-like ones) use to shorten a bit and existing partition, in order
to create space for their body.
> definition of what the Joshi, etc. does. And what should be the
> definition of the method used by DIR-2..?
My definition is: Dir II modifies the directory entries in such a way
that the executable files described in them -appear- to contain the
virus body.
> > 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.
I did. I know this very well and still think that it is a bad
approach. There are too many execfile compressors - should everybody's
scanner be able to cope with all of them? IMNSHO, we need a shell
program (a la Shez), that is able to unpack the compressed files and
to run a user supplied scanner on them.
Anyway, my original (and incorrect) claim was that as far as I know,
only VirX is able to scan inside both LZEXE'd and PKLite'd files. It
is the first program that was able to scan inside PKLite'd programs.
As Morgan Schweres pointed out, now SCAN is able to do it too. I'm not
quite sure about F-Prot, but know that Frisk intends to implement it.
Yet another useless thing that the anti-virus researchers are forced
to implement by their users... like the disinfection, for instance...
:-)
Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev Universitaet Hamburg, FB Informatik - AGN
[email protected] Schlueterstrasse 70, D-2000 Hamburg 13
New address after October 1, 1991: Vogt-Koelln-Strasse 30, D-2000, Hamburg 54
------------------------------
Date: 27 Sep 91 06:17:44 +0000
>From:
[email protected] (Vesselin Bontchev)
Subject: Re: Precise identification (PC) Reaction and Philosophy
padgett%
[email protected] (A. Padgett Peterson) writes:
> 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>).
cutable files. In fact executables are not
> permitted to load from DataDisk (see PATH). Need to update a file or
How do you achieve this by using only the PATH variable? That is, how
do you prevent the files in the current directory on the data disk
from being executed (if the data disk is also the current drive)?
> 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.
Unless the protection is achieved by a strong cryptographic scheme,
there is no way to prevent the information from being read, using
software only... And no way of protecting the disk from being
destroyed, regardless of the software protection used... Or do I miss
something? How do you achieve your protection exactly?
Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev Universitaet Hamburg, FB Informatik - AGN
[email protected] Schlueterstrasse 70, D-2000 Hamburg 13
New address after October 1, 1991: Vogt-Koelln-Strasse 30, D-2000, Hamburg 54
------------------------------
Date: 27 Sep 91 07:49:50 -0400
>From: LARRY MATEO <
[email protected]>
Subject: Stoned Virus - Thank You All (PC)
I would like to thank everyone who responded to my questions about the stoned
virus. I received responses from all over the world. Wonderful! I appreciate
the time you all took to help me. It is good to know that there is a large
group of knowledgable people I can turn to when I have a problem or questions.
Thanks again.
------------------------------
Date: Fri, 27 Sep 91 16:09:32 +0000
>From:
[email protected] (Albert Lunde)
Subject: Re: Perfect detectors
[email protected] (Ray Mann) writes:
> A posting by
[email protected] (Albert Lunde) said:
>> "As prior threads have illustrated, a "perfect virus detector"
>> is in general impossible."
> That's a reasonable corollary of the premise that 'software
> cannot overcome software'..
It derives from abstract computation theory - somewhat related to the
"Halting Problem" for Turning Machines - It is in general hard to
determine the purpose and untimate effect of a computer program and
thus decide if it is, say, a virus.
[email protected] (Ray Mann) writes:
> However, there seems to be evidence that virus scanners are
> not really diminishing the virus threat. Several people pointed
> out that there's been a great =increase= in the total number of
> infected machines, and in the number of infections per machine
> since the scanners came out. Also, the total number of new viruses
> has increased dramatically.
This picture is confounded by the fact that reporting is not uniform.
Sites that use scanners will report more occurances of virues. Much
of the increased count of new viruses come from having an
international reporting system developing, and from counting
variations
I do not think there is a causal relationship "Use of virus scanners
- -> new viruses." I get pissed off by stuff that suggests anti-virus
developers are somehow the cause of the problem. Without these tools
most people would be up a creek.
The one mechanism I can think of would be that scanners may make it a bit
easier for yahoos to "capture" a copy of an existing virus.
I would like to see more use of OS/hardware protection, but I'm not
holding my breath.
------------------------------
Date: Fri, 27 Sep 91 14:52:00 -0800
>From:
[email protected]
Subject: F-Prot 2.0 (PC)
I just downloaded a copy of F-Prot 2.0 and have a few questions:
1. I remember reading that it is incompatible with Zenith DOS 3.3+,
which is true, at least to the degree that F2 stops at the end of the
list of viruses (Attacker) and gives the following message: error
reading drive C:. Is VIRSTOP.EXE also incompatible, or can it be still
used as a first line of defense?
2. The documentation speaks of a single copy of VIRSTOP.EXE installed
on a server, so that every single machine would be protected.
Obviously not machines with hard drives, or am I wrong? But also, I
fail to see how a machine using start chips would be protected. To
explain our circumstances: not in all instances do people who boot off
the start chip log into the network, so that the config.sys on the
Start volume is used, but no autoexec.bat file. This allows
non-network users without boot disks to use the stations without
asking for a boot disk, and leaves them more room in memory. With
F-Prot 1.6, I simply installed F- DRIVER.SYS on each start volume of
the network (I use about 5 different start volumes, depending on
classes, accounts, etc.). So far it worked, although I understand
that the lack of infections may have been pure luck. Anyway, do I
understand the new directions correctly: Load VIRSTOP.EXE in the
AUTOEXEC.BAT file of the server(s) to protect the entire system? Or
should I again load VIRSTOP.EXE on each start volume (3Com 3+Share
system)?
Thanks,
[email protected]
------------------------------
End of VIRUS-L Digest [Volume 4 Issue 176]
******************************************
Downloaded From P-80 International Information Systems 304-744-2253
