VIRUS-L Digest Monday, 23 Sep 1991 Volume 4 : Issue 170
Today's Topics:
precise identifications
software approaches
Re: Disinfectant and students (Mac)
Encryptors and experience
Theory and practice
Boot selection (PC)
Brain Virus (PC)
False positives
Precise identification
Looking for information
Re: FAT Infection (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: Fri, 20 Sep 91 22:16:44 -0700
>From:
[email protected] (Fred Waller)
Subject: precise identifications
In an earlier article, I wrote about the Rosenthal Virus Simulator
and while on the subject, commented on the methods used by the
antivirus publishers, as follows:
"I often wonder if we shouldn't credit the virus-naming penchant of
antivirus publishers (and the attendant publicity), as well as the
quest for "precise identification", with being at least partially
responsible for the extraordinary proliferation of new viruses, and
the concomitant increase in virus incidents worldwide. I'm not
referring to any possible collusion, or virus-production, by anti-
virus entities, but to the obvious invitation that "orthodox" virus
authors must feel to rise to the challenge and produce new
creations that could trick a given scanner, if only ephemerally."
Apparently slighted by this conclusion, Vesselin Vladimirov
Bonthchev wrote in reply:
> The above is just an unfounded flame against the anti-virus
> researchers, so I won't bother to comment it.
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.
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
corporation, surely not one to carry "unfounded flames against
the anti-virus researchers", proposed to do the same thing. Many
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!
> I'll contend myself only to mention that each science begins with
> defining the proper terms, naming, and classification. The fact
> that even this is not yet accomplished in the field of computer
> viruses, only means that the computer virology is a very young
> science.
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
computers is an engineering task, and an art, not a scientific
investigation. Its fundamentals will be found in the science of
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
get the same information by writing a letter to Microsoft, assuming
they agree to tell you. But let's not fool ourselves (or others)
into thinking we are conducting "research" into some unknown natural
phenomenon.
Viruses share most characteristics with conventional, non-replicating
programs, and can be fully and completely studied in that context.
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
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.
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.
I think we need a "computer virology" as much as we need a "computer
wordprocessology" or a "computer filecompressology".
---------------------------
(*) Cohen, F., Letters, Virus Bulletin, May, 1990. (p.7)
------------------------------
Date: Fri, 20 Sep 91 22:14:24 -0700
>From:
[email protected] (Fred Waller)
Subject: software approaches
Regarding the Virus Simulator by Rosenthal Engineering, and
in answer to the following earlier comments in my article :
"Perhaps the best way to solve it is to move away from string
scanning as a viral "detection" technique. The assumption
that, in order to *stop* a virus one needs to *identify* it
is, in my view, an incorrect assumption."
writes
[email protected] (Vesselin Bontchev):
> Why? There are other ways to stop a virus, agreed, but none of
> them is universal (except of turning your computer off, of
> course). Neither is the scanning approach, but nobody claimed
> that.
Vesselin Vladimirov writes this, yet he knows that all virus
scanners make it a prominent point of announcing many (useless)
hundreds of viruses they can "detect", with the obvious intention of
impressing the public into (debatable) confidence. He also neglects
to take into account the fact that well-known hardware approaches,
such as recently described by Padgett Peterson here (posting of 16
Sept 91 on `Interesting Laptop config') provide a much more
effective means of protection than software.
By definition, software cannot defeat software. All it takes is
the next generation of viruses, and the antivirus programs must
be updated. And all it takes is the next generation of antiviruses,
and the *viruses* must be updated!
Certainly, both virus and antivirus combatants have demonstrated
tenacity and skill in updating and improving their respective
creations. In practice, what has resulted so far is an endless
proliferation of viruses, and a seemingly endless proliferation of
antiviruses. The end is nowhere in sight, ever remote... a mirage.
But both viruses and antiviruses are thriving.
It would be nice if we could say that, after all this time, the
antivirus publishers have given us some tangible evidence of
usefulness, some material proof that they have contributed to
diminish the virus threat. Such evidence is missing.
Unfortunately, the reverse is true: since the virus/antivirus
utilities have appeared, the number of infections, and the number
of viruses have both increased dramatically. The number of affected
machines is higher, not lower. The overall number of virus types
is increasing at a mad pace. The incidence of cases around the
world is higher, not lower. These facts cannot be ignored.
Clearly, the facts show that software approaches are not the way
to deal with the problem. They haven't lessened it. There is no
indication that they ever will. On the contrary, in spite of all
attempts at control by software approaches, the problem gets
increasingly worse, worldwide.
> Recognizing known viruses is just one of the ways to stop them.
Not according to any statistics that anyone can quote. Exactly the
opposite is true. Virus "recognition" as practiced by the "scanners"
is shown to be a most counterproductive method to deal with a problem.
It wins small battles, but loses the big war. It is not a wise
application of resources to solve a problem.
Further writes Vesselin Vladimirov:
> If the scan strings are carefully chosen, they give few false
> alarms and detect many future virus modifications. Oh, yes, and
> they also get sometimes fooled by Rosenthal's program... :-)
Does this mean, then, that IBM's and McAfee's, and Microcom's,
and Skulason's and Central Point's and Symantec's and Jim Bate's
and Sophos' and TBScan and.... so many other scanners have all had
their strings not "carefully chosen", since they are ALL fooled
by the Virus Simulator? Should all of them choose their strings
more carefully? Would choosing them "more carefully" prevent
false alarms (100% in many cases)? No, I don't think so. Show me.
Vesselin Vladimirov further quotes me on the Virus Simulator:
>> ..(the Simulator)... will make a lot of people aware of the
>> inadequacy of string scanning as a virus-detection technique.
and responds:
> But it doesn't do that!
It most certainly does. That's exactly what it does, and it does it
rather well. What better demonstration of the inadequacy of string
scanning than Rosenthal's Virus Simulator? It proves that virus
scanners can be fooled into giving false alarms at the rate of nearly
100%, an incredible figure.
------------------------------
Date: 21 Sep 91 22:39:01 +0000
>From:
[email protected] (Peter Chen)
Subject: Re: Disinfectant and students (Mac)
I was taking care of the Mac's at a microlab at Rutgers for two years
until early this summer. In general, my policy had always been
educating the users as much as possible and making them aware of the
problems with virus, since I was getting rather annoyed when my
machines kept getting infected by the floppies that ignorant users
brought in. We ran both SAM and Disinfectant(I wasn't using
Disinfectant's Init). I found SAM's automatic floppy scanning useful
for most users, even though some people found it intrusive. Whenever,
there is a new virus appear, I usually post a message about it on the
local newsgroup and put up signs around the lab. This made most of
the users more aware of the situation and more willing to cooperate
with the consultants. I am not sure whether this is still done after
I left the facility; however it did save us a lot of trouble.
PeteChen
[email protected]
------------------------------
Date: Fri, 20 Sep 91 22:18:58 -0700
>From:
[email protected] (Fred Waller)
Subject: Encryptors and experience
Writing some comments to an article by Bill Arnold of IBM, (who
wrote that he spent considerable time designing degarblers for
antivirus scanners), I suggested:
> If I were writing such software, I would seldom bother composing
> dergablers. Each encrypted virus has its own degarbler built in.
> Why not just use that? It usually works rather well... <g>.
> Sliding-window encryptors do not respond well, but the rest do.
Commenting on several related issues, Vesselin Vladimirov Bontchev
apparently misunderstood my meaning and, addressing his posting to
me directly, wrote:
> You obviously have very little (or no) experience with really
> mutating viruses.
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?)
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...
But why dwell on personalities, let's look at some facts instead:
Vesselin Vladimirov mentions "V2Px", which I take to mean Washburn's
viruses, such as V2P2, V2P6, etc.
> 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
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.
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.
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.
------------------------------
Date: Sat, 21 Sep 91 22:43:17 -0700
>From:
[email protected] (Fred Waller)
Subject: Theory and practice
Writes
[email protected] (Vesselin Bontchev):
> Controlled? Why? Frisk's heuristic analyser only warns the user
> that a program does something strange.
If it did just that I wouldn't have objected. The "heuristic virus
analyzer" boldly proclaims: "A BADLY WRITTEN PROGRAM" when it finds
something that, in its opinion, is not the way it should be. But
-who cares- what any publisher of antiviral utilities thinks, or
doesn't think, about what's a "badly-written" and "not-badly-
written" program? Should the fact that someone decided one day
to publish a virus scanner give him/her the right to pass judgement
on what is "good programming" and what is "bad programming"? Why
is he entitled to make such comment on someone else's work,
written by people who have been writing successful software well
before he ever started to compose his own?
Instead of a defense, I would have rather expected some sort of
an excuse, or apology, for such manners.
> Well, when I tried Mark Washburn's program, it just hung my
> system, so I stopped using it at all. Well, to be honest, it
> was a rather old version - 2.11 or something like that. I have
> to try version 2.30 and see if it works.
Perhaps reading the .DOC files might have helped. SECURE will
-stop the CPU- at the first notice of infection because even a
single instruction that's allowed to be executed after an illegal
attempt is detected could be enough to give control to the virus.
The freezing is intentional, and is the best defense: to -stop-
a virus from infecting, -before- it invades a system, rather than
allow infection first, then attempt to "scan" it, then attempt to
"clean" it, then see if any remnants of the virus were missed, then
restore damaged files, then hope to avoid another infection...
SECURE eliminates all that.
> It is very easy to write a dedicated virus, which will aim
> particularly SECURE and disable or circumvent it.
> It is even easier than to construct a fake file which causes
> SCAN to report false positives. :-)
In the final analysis, it's always possible to defeat software with
software. However, it's also possible to make reasonable choices
as to what is the -best method- for designing protective software.
While it's not easy to disable SECURE, it's indeed possible and has
been done in the laboratory. In order to do so, one must have the
particular issue of the program which one wishes to subvert. You
can't write a program to defeat SECURE ahead of time - you can only
do so for versions that have been already published. And it doesn't
have to be a virus. A demo program was written that allowed the
removal of -one- specific version of SECURE from memory. Since
SECURE is updated frequently, this provides more than enough
security and SECURE is indeed able to stop every known virus from
infecting a system.
Whether it is or is not possible to design a bypass to SECURE, the
important consideration is that, of the currently known viruses,
none can bypass it. In practice, it's almost irrelevant whether
some "researcher" can design some way to bypass SECURE's protection.
Such theoretical bypass is not infecting computers anywhere.
It is not a practical threat.
If we further consider that there are only 40 or so -actual- viruses
spread in the field [and not the 600/900 that some "scanners"
purport (what for?) to "detect"], it becomes even more obvious that
a program such as SECURE is by far the wiser choice. In an ideal
scenario, if every computer in the world were "scanned", infections
would still continue because scanners do not prevent spread of
infection, they only detect it after it occurs. But if every
computer in the world were protected by programs such as SECURE,
infections by viruses as we know them today would cease to occur.
These are best-case scenarios, of course, and never likely to occur
in reality. They do, however, illustrate interesting directions
and possibilities.
> I have also to test it against some of the most clever
> Bulgarian viruses...
Well, I don't know. Would these be still unpublished ones?
If you have any viruses that can bypass SECURE, you should make
a copy of them available to the author, so that he can improve
his program and eliminate any loopholes you might have found.
If you have found any loopholes.
> Just try to use PC Tools or Norton Utilities, without
> registering them properly in the database file... :-)
The immense majority of computer users do not employ programs
designed to edit executables. Those who do, usually have enough
knowledge of computers to deal with virus threats in a much
more effective manner anyway.
> And if you -do- register them and give them the appropriate
> rights to modify executable files, a virus which infects them
> will gain the same rights.
Only to infect -one file-! As soon as *that file* tries to infect
another, it will be stopped for good. No more virus spread. No
damage to program or data files. No crosslinking of clusters.
No scrambling of FATs. No encrypting of hard disk contents. No
deletion of valuable files. No loss of data. No further spread
to friends or associates. No virus.
> I strongly suggest you to read the paper "Computer Viruses -
> Theory and Experiments" by Fred Cohen. It explains the very
> basic things in computer virology - a knowledge that you
> really need to avoid some theoretical traps when dealing with
> the computer virus problem.
I strongly suggest you read the .DOC files that come with the
programs you try to use. :-) Doing so may help you understand
the difference between theory and practice. By the way, consider
this my third request to ease up on _ad hominem_ comments.
------------------------------
Date: 22 Sep 91 15:32:52 -0400
>From: Jon Freivald <
[email protected]>
Subject: Boot selection (PC)
> On arrival, it was certainly a laptop and not a notebook &
>requires a diaper bag for transport but had some interesting and
>unnannounced features built into the BIOS:
>
>1) Password boot protection
>2) Password keyboard locking while operating
>3) Floppy/FD boot selection
>4) Partition table validation
Zenith computers have had a similar feature (to #3) for years and have
recently (last year or so) implemented #1 as well. In general, I
dislike Zenith systems, but those features have proven nice in some
instances (we have ~70 Zenith machines in our organization...).
------------------------------
Date: 23 Sep 91 00:37:06 +0000
>From:
[email protected] (Brian Cooper)
Subject: Brain Virus (PC)
Thanks to all those who responded to my questions regarding
the Stoned Virus. I now scan all disks before copying files
to my hard drive.
I do have another problem; one which I believe is a false alarm.
I have been using Central Points Vdefend (comes with PC Tools V7).
It is a TSR which is loaded via my autoexec.bat. I have been using
McAfee's SCAN for about two weeks with no problems. However, while
running SCAN today, I received the message that the Pakastani/Ashar
[Brain] virus was found in memory. The message suggested that I power
down and boot from a clean floppy and run SCAN to determine the extent
of infiltration. I powered down, rebooted from a floppy, and ran SCAN;
however, SCAN did not detect any infected files.
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)?
Thanks in advance,
Brian Cooper
- --
Brian Cooper
Georgia Institute of Technology, Atlanta Georgia, 30332
uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!psgrbbc
Internet:
[email protected]
------------------------------
Date: Sun, 22 Sep 91 21:04:35 -0700
>From:
[email protected] (Fred Waller)
Subject: False positives
Writes
[email protected] (Vesselin Bontchev)
responding to a post by
[email protected] (Ray Mann):
>> grossly inadequate. By the way, Rosenthal's virus simulator
>> seems to have disclosed a real weakness in the area of false
>> alarms...
>
> Of FALSE POSITIVE alarms. These are in no way dangerous and I
> really don't see what the discussion is all about.
------------
At least from my end, this discussion is about false positives,
about the unreliability of virus scanners and about the Virus
Simulator of Rosenthal.
False positives are -very- annoying, cause much waste of time and
resources and are highly undesirable. Within an organizational
environment, false positives are nearly intolerable! The Virus
Simulator proves that it's possible to cause the virus scanners
to have a 100% false alarm rate. If the Virus Simulator can
achieve this, so can malicious software, self-replicating *or not*.
The Virus Simulator proves that anyone who wants to do so, can
make the virus scanners issue false alarms, as often as he wants to.
Therefore, as technical curiosities the virus scanners are very
interesting, but as security products they are not useful.
------------------------------
Date: Sun, 22 Sep 91 21:03:29 -0700
>From:
[email protected] (Fred Waller)
Subject: Precise identification
Writes
[email protected] (Vesselin Bontchev):
>> But why do we need "precise identification"?
>
> Precise identification is undispensable if your program has to
> disinfect the infected media. If it tries to disinfect the wrong
> virus variant (even if it differes by only one or two bytes), it
> may damage that file beyond repair.
-------
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?
Of course, preventing infection would tend to stop the spread of
viruses while curing it does not. The question then is: what is the
ultimate goal of the virus scanners: to prevent viruses from
spreading or simply to be widely-used but not very efficacious
utilities?
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_. There is no end to this
sort of thing. Software defenses and software attacks will alternate
forever, to the great joy of the antivirus publishers, but to the
detriment of users worldwide, large and small.
Only hardware/firmware defenses can definitively stop such software
attacks. Hardware defenses can be much *less expensive* in the long
run, and even in the short run, do not encourage the production of
ever-improved viruses and do not need to be frequently upgraded.
Hardware defenses stop viruses. Software defenses do not.
------------------------------
Date: Sun, 22 Sep 91 07:50:46 +0700
>From: Hank Nussbacher <
[email protected]>
Subject: Looking for information
I am looking for introductory online information about viruses. I
remember seeing a list of all viruses, how many there are, how many
strains, etc. I am also interested in the history of viruses - when
was the first one spotted on a PC, on a Mac, what was its name, which
virus is the most deadly, etc. I seem to remember seeing lists of
this nature, but that was a year or two ago.
Any help would be greatly appreciated.
Thanks,
Hank Nussbacher
------------------------------
Date: Fri, 20 Sep 91 18:43:09 -0500
>From: Otto Stolz <
[email protected]>
Subject: Re: FAT Infection (PC)
On Wed, 18 Sep 91 15:18:00 +1200 Nick FitzGerald said:
>At this point there is much potential for confusion. Some BSI/PTI
>viruses _affect_ (NOT infect) the FAT. This happens with Stoned and
>most of its derivatives, due to the "assumption" by its creator, that
>sector 0,0,7 is never used. This is true on HD's FDISK'ed with ...
In this case, the virus may be affected in turn. This spring, I saw an
example.
A secretary at our university had a Stoned virus on her hard disk in a
DOS 2.11 (or 2.7? -- I know there was a prime number after the dot)
system. I told her to use only diskette drive B (to confine the virus)
and to do a backup of all her files, before I came to dis-infect her
environment. This lady was very scrupulous about her files, so she
went through all the directories, deciding what files to backup and
DELETING the other files. Now, DOS faithfully changed what it thought
was the FAT, but what partly was the original master boot record
saved by the Stoned virus to sector 0,0,7! This continued, until the
computer did not boot any more from the hard disk.
Another observation from the same incident bears on the epidemology
of the Stoned Virus. That group has two secretaries equipped whith
identical computers. Both had Stoned on their hard disks. When I checked
all diskettes in that environment, I found that one secretary had
infected more than half of her stock, while the other one had
infected but 1 diskette. It turned out, that one usually worked whith
drive A, and the other one usually whith drive B of her computer.
Regards
Otto
------------------------------
End of VIRUS-L Digest [Volume 4 Issue 170]
******************************************
Downloaded From P-80 International Information Systems 304-744-2253
