VIRUS-L Digest Thursday, 11 Apr 1991 Volume 4 : Issue 60
Today's Topics:
Administrivia - DIGEST FORMAT CHANGE
Infection by insertion (Mac)
Interpol reacts to computer viruses
re: Non-obvious viruses (was: Unix and viruses (UNIX))
Re: AF/91 - John Gantz joke in Infoworld
Infoworld article
Classification of the Malicious Software
An Analysis of McAfee's Authentication Methods (longish) (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: Thu, 11 Apr 91 09:16:30 -0400
>From: Kenneth R. van Wyk <
[email protected]>
Subject: Administrivia - DIGEST FORMAT CHANGE
Hi Folks,
(NOTE: this does not affect comp.virus, only VIRUS-L.)
Recently, an Internet RFC (Request For Comments - these are the
generally accepted standards within the Internet community) on digest
formats has been brought to my attention. RFC 1153, dated April 1990,
states (among other things):
The Preamble must be separated from the remainder of the message by a
line of 70 hyphens followed by a blank line.
...
Each enclosed message must be separated from the the remainder of the
digest message by a blank line before and after a line of 30 hyphens.
VIRUS-L digests currently use 75 hyphens to separate the preamble from
the remainder of the digest. However, each message is separated by
the correct (30) number of hyphens.
So, in an effort to conform to RFC 1153, I will be changing the format
slightly. Effective Volume 4 Issue 61, the digests will contain 70
hyphens between the preamble and the remainder of the digest. Anyone
out there who is using a digest exploder should make the necessary
changes to be able to read the new format.
I hope that this does not cause difficulties for anyone. If anyone
would like to see RFC 1153, it is available by anonymous FTP on
NIC.DDN.MIL. Or, email me and I'll send you a copy.
Cheers,
Ken
Kenneth R. van Wyk
Moderator VIRUS-L/comp.virus
Technical Coordinator, Computer Emergency Response Team
Software Engineering Institute
Carnegie Mellon University
[email protected] (work)
[email protected] (home)
(412) 268-7090 (CERT 24 hour hotline)
"Be it ever so humble, there's no place like $HOME"
------------------------------
Date: Thu, 11 Apr 91 08:58:00 -0500
>From: "Mark Nutter, Apple Support" <
[email protected]>
Subject: Infection by insertion (Mac)
Thomas DiBlasi asks:
>Is it possible for a virus, trojan, worm, etc. to infect a hard disk
>or RAM simply by inserting an infected floppy into a drive without
>execution??
There are a couple of Mac viruses that take advantage of a loophole in
the Mac OS to produce precisely that effect. Basically, the Mac OS
allows you to define code resources for such common items as windows
and menus, so that you can implement custom windows and unusual menus.
The WDEF and MDEF viruses exploit this by putting modified (viral)
code resources where the operating system will find them when it goes
to draw a window or pull down a menu. Thus, if you put an infected
disk in your disk drive, and then open a window (or pull down a menu),
the infected code resource gets executed, even though you never ran a
program.
Naturally, the freeware program GateKeeper (actually GateKeeper Aid),
and a number of other anti-viral products, now check this loophole, so
a protected Mac should be safe from this particular avenue of
infection. I run GateKeeper all the time, and it has caught a number
of WDEF-infected disks before they could do anything. (It
automatically removes the virus upon detection).
- -----------------------------------------------------------------------------
Mark Nutter MANUTTER@IUP
Apple Support Manager
Indiana University of Pennsylvania
G-4 Stright Hall, IUP
Indiana, PA 15705
"You can lead a horse to water, but you can't look in his mouth." - Archie B.
=============================================================================
------------------------------
Date: 11 Apr 91 13:21:55 +0000
>From: Pete Jinks <
[email protected]>
Subject: Interpol reacts to computer viruses
An article in The Daily Telegraph, Saturday April 6th p.2 col.1 about computer
crime:
" ... [at] the 20th Interpol European conference in London [yesterday]
.. Det. Insp. John Austen, who runs the computer crime unit of the
Metropolitan Police Fraud Squad ... [and is] chairman of Interpols's
European computer crime working party ... [said that] `... By the end
of the year, Interpol will have set up a computer virus library in
Holland, to provide a central information point for European police
forces, and a database from which to send out warnings of any major
virus attack. ... An index of 400 computer viruses had been compiled,
with cures for most of them.'"
------------------------------
Date: 11 Apr 91 10:31:11 -0400
>From: "David.M.Chess" <
[email protected]>
Subject: re: Non-obvious viruses (was: Unix and viruses (UNIX))
In an otherwise quite solid article, William Hugh Murray
<
[email protected]> writes:
>>d. That the individual is sufficiently sophisticated to avoid leaving
>>obvious clues (file sizes, dates, etc.).
>
>Well, that excludes all viruses. It is possible to conceive of a
>virus that was so subtle that it left no evidence; on the other hand,
>if you never notice that you have been damaged, then you have not been
>damaged.
>
>No such virus has ever been detected, for obvious reasons. All the
>reported viruses have done something noticeable. Since the intent of
>a virus is to spread, and since if it has no symptoms, the author
>cannot know if it is successful, few people would write such a virus.
This is much too strong. There are certainly viruses that go to great
lengths to avoid leaving *obvious* clues, and there are quite a number
of viruses that have no intentional payload (don't ever erase files,
damage data, print a message, or anything else). Presumably the
authors of these viruses had a somewhat different set of intents; any
statements of the form "the intent of a virus is X" are backed up by
little or no evidence, and should be avoided by the fastidious! *8)
Of course, all viruses have *some* symptoms (they change existing
objects, or create new objects, or whatever). But that doesn't mean
that there aren't viruses that do their best to have as few symptoms
as technically feasible. Even a virus that did have a destructive
"payload" could be written to have no obvious symptoms until the
payload was delivered.
DC
------------------------------
Date: Thu, 11 Apr 91 09:52:08
>From:
[email protected] (John Boyd;CRENP)
Subject: Re: AF/91 - John Gantz joke in Infoworld
I guess that, from now on, anyone who writes 'joke' articles, even if
they *do* appear in a 1 Apr cover date pub should begin and end their
articles with the banner:
_________________________________________________________________
*JOKE* *JOKE* *JOKE* *JOKE* *JOKE* *JOKE* *JOKE*
_________________________________________________________________
so that those of you who neither have a sense of humor, *or* read to
the *end* of the article will know that it's a joke. I passed the
aforementioned article to all the members of my end-user support team;
and while the article 'had them going' in the beginning, when one got
to the bottom, it became *obvious* that it was tongue-in-cheek humor.
You have seen that style of humor, haven't you?
I have been reading computer related pubs written to various user
levels for about 10 years, and it has been my experience that you
almost *always* see some article which, at first glance appears to be
real, only to 'remove its tongue from its cheek in the end'. Geez!,
lighten up! Laugh once in a while; and get some sun!
------------------------------
Date: Thu, 11 Apr 91 12:16:46 -0400
>From: padgett%
[email protected] (A. Padgett Peterson)
Subject: Infoworld article
>From:
[email protected] (Malcolm Sharp)
>In the April 1, 1991 issue of Infoworld, John Gantz in his column
>"Tech Street" warned of a virus called "AF/91"...
>In the same issue, columnist Robert Cringely discussed Windows 3.0
>vulnerability to viruses saying it "has lots of holes for custom
>viruses to slip through."
Of the two, I consider the Cringely article far more dangerous. Mr.
Gantz clearly stated at the end that "AF" meant "April Fool" and the
concepts were plainly ludicrous.
Mr. Cringely, however, is echoing out of context some mythconceptions
concerning Windows. Windows is a colletion of programs. It makes use
of certain "undocumented" constructs and capabilities in MS-DOS just
as NetWare DOS. The error cones in the implication that there is no
way to protect against malicious software that exploits these "holes".
This is completely erroneous !
The "holes" are simply alternate paths used for disk and OS access
that will bypass a conventional Int 13 or Int 21 "trap" that is
layered on after DOS has loaded. These are easily plugged by a system
that places its "traps" <italics on> before DOS has loaded <italics
off> for hardware access, and understands the special hardware where
networks are involved. (ROM pointers are still present, the protection
software just must know how to find them.
To me, this comes under the same heading as last year's reports of the
"invisible stealth" viruses that could not be detected. BALDERDASH.
For example, many people are surprised to find that their machine has
become infected in the partition table from an "accidental" floppy
boot. If the partition table (MBR) code just checked three things such
infections (like BRAIN & STONED) would have never spread:
1) Can I trust myself
2) Can I trust the disk access
3) Can I trust the MBR on the disk
Such checking can be done in about 20 additional bytes.
What is needed is a comprehensive integrity management scheme that is
invisible to the user but encapsulates the OS. The sooner a vendor
comes up with a good mechanism (and it would be easiest for
MicroSoft), the sooner the public will quit worrying about hundreds of
"unkillable" viruses in PCs.
Oh well, the incredible diversity of virus checking programs out there
makes it difficult for malicious software to be able to defeat
everything. Maybe that is a good.
Warmly,
Padgett
ps I left a similar message on Mr. Cringely's voice mail system. It
has not been returned. app
------------------------------
Date: Thu, 11 Apr 91 17:57:05 +0300
>From:
[email protected] (Eldar A. Musaev)
Subject: Classification of the Malicious Software
Writing a book about malicious software I need in
classification. I ask to discuss the next classification.
That is not my classification, I've only formulated common
implications and made some attempt to make it complete. Another basis
of this classification are the recommendations of (American) National
Institute of Standards and Technology (John Wack Suggested Reading
List for Computer Viruses and Related Problems, September 22, 1989 -
Basic Terms).
Till now there is some unstability in some terms so it would
be very good to find the best fits.
Please, send replies to me, I'll summarize results.
Common name: Malicious Software
Short informal synonym: Badware
Interlanguage synonym: Trojans
Reasons: Any malicious software can be considered as
a programs with Trojan side effects.
The first level classification criterion:
a)Duplicating/non-duplicating - i.e. does the program
duplicate itself or not ?
b)Parasitic/non-parasitic - i.e. does the program attaches
itself to another program to duplicate itself ?
So there are three classes of malicious software:
I.Trojans - non-duplicating, non-parasitic
II.Worms or Bacteriums (this term I've read in French-language papers)
- duplicating, non-parasitic
III.Viruses - duplicating, parasitic
I.Trojans - the suggested classification criterion is the origin
of the Trojan effect:
I.1.Accidental Trojans or Infirm Programs - the programs which have not
been sufficiently tested and so contain many errors.
Example: PCShell word-processor which sometimes looses the file
if the disk is full
I.2.Side Trojan or Programs with bugs (or implanted bugs) - the programs
with unspecified back entries or other opportunities to
deactivize software or make any harm.
Example: Software for the French weapon systems sold to Iraq.
I.3.Direct Trojans or Trojan Horses - the programs which are specially
designed to harm something and which are designed to hide these
side effects.
II.Worms or Bacteriums - the suggested classification criterion is the
area and media of duplication.
II.1.Network worms - the programs which duplicates themselves from node
to node in networks.
Example: Christmas Tree
II.2.Local worms - the programs which copy themselves *INSTEAD OF*
another program. The original program is destroyed in part
or as a whole.
Another names:
Overwriting viruses - Patricia Hoffman;
Worms - some French-language papers;
Bacteriums - the same place.
Suggested short terms: absorbers, destroyers, spoilers ...
What is better ?
III.Viruses - the suggested classification criterion for viruses
is the kind of the link between the virus and a victim and
the fact of modification of the victim content.
III.1.Static viruses - most numerous class of viruses and malicious
software. These viruses join to the victims and modify them
to get a control first.
Exaples: Vienna, Dark Avenger etc.
III.2.Dynamic viruses - the viruses which do not change the contents
of the victim and place themselves in separate files, which
are logically and dynamically connected with the victim.
Example: Spawning viruses (in terms of Patricia Hoffman)
which make a COM-twins for EXE-victims, so when calling
a victim, the virus gets a control first (as a COM-file with
the same name) and later dynamically loads and executes the
victim.
"Spawn" is the C/Unix term for the dynamic call with return
of a program, so it is a comparatively new term. The older
generation of programmers use "attach", "link" or "[dynamically]
call" terms.
===== Please, reply to me, I'll summarize the results ==================
| Eldar A. Musaev, Ph.D., Researcher |
[email protected] or |
| Mathematical Institute, Acad.of Sci. |
[email protected] |
| USSR 191 011 Leningrad Fontanka 27 LOMI AN USSR |
========================================================================
------------------------------
Date: Tue, 02 Apr 91 14:06:00 +0300
>From: "Y. Radai" <
[email protected]>
Subject: An Analysis of McAfee's Authentication Methods (longish) (PC)
[The following is a draft of an article I'm submitting elsewhere
(except that for this version I've added a few references to this
forum). Your comments and constructive criticisms are welcome.]
The anti-viral programs released by McAfee Associates are well known
in this forum. It is presumably because of their popularity that they
have been the victims of a number of "Trojanizations" or bogus ver-
sions. I would therefore like to discuss them not from the usual
point of view of their ability to recognize and remove known viruses,
but rather with respect to the measures which McAfee has taken to
ensure that his programs have not been tampered with. These are as
follows:
1. The first measure he introduced was insertion of a self-test into
each of his programs when it begins execution. If one of them has
been modified, a warning "The file xxxxxx has been damaged!" is
displayed, but the program is allowed to continue execution. If there
has been no modification, no message is displayed.
2. Starting from Ver. 46 (in the case of SCAN and SCANRES), his pro-
grams have been packaged with an external file authentication utility
VALIDATE. According to the most recent version of the documentation
file for VALIDATE, it uses "two discrete methods" to generate CRCs.
(In my opinion, it would be more accurate to say that it uses a
*single* method (the CRC algorithm) to compute a pair of 16-bit check-
sums based on each of two generator polynomials.) The utility displays
these, as well as the file size and date of creation, for the user to
compare against the "known" data for the program, i.e. that "published
by the author of the program or obtained from a trusted information
database". (This includes the CVIA, but it's not clear what other
databases are trustworthy.) But the correct data for each of McAfee's
programs is also included in the doc file for the current version of
that program. The documentation for SCAN says that if your copy of
SCAN.EXE differs (i.e. if you get different validation results), the
program "may" have been modified. On the other hand, until recently
the VALIDATE.DOC file claimed that "If they match, you can be assured
that the program has not been tampered with." In recent versions, the
wording is slightly more modest: "If they match, than it is highly
improbable (less than one in sixty-four quadrilion) that the program
has been modified."
3. Starting with Ver. 72, all of McAfee's programs which are made
available for downloading are archived using the Authenticity Verifi-
cation option of the PKZIP utility. At the time they are extracted or
tested the user should see the message
> Authentic Files Verified! # NWN405 Zip Source: McAFEE ASSOCIATES
If one or more files in the archive have been replaced by someone else,
all files will be extracted as usual, but PKUNZIP will display the
following message instead:
> Authenticity Verification Failed!
> One or more of these files has most likely been tampered with.
The idea of introducing authenticity checks is a good one in prin-
ciple, and one might suppose that with so many methods, McAfee's pro-
grams must be secure against forgery. Unfortunately, the particular
techniques chosen all seem to me inadequate for the following reasons:
Self-Test:
This is the simplest check to circumvent. A self-test makes sense
as protection against most viruses, since a virus is ordinarily de-
signed to preserve the functionality of the program which it infects,
which would include the self-test in this case. However, a self-test
is useless if the program is replaced by a Trojan, since in this case
the hacker is not constrained to preserve functionality; in particular,
there's no reason why his Trojan should retain the self-test. (Actual-
ly, a self-test is ineffective against some types of viruses too, since
overwriting viruses do not preserve functionality, and a virus could be
designed to neutralize the self-test routine itself. Most important,
the test would fail when certain types of stealth viruses are active.)
VALIDATE:
The great majority of users are not going to bother contacting the
author or the CVIA in order to validate their programs. If they do it
at all, they're going to use the values given in the documentation
files. Hence when the hacker modifies one of McAfee's programs, he can
simply compute the CRCs (i.e. the checksums produced by the CRC algo-
rithm) of the modified program and substitute these values for the au-
thentic ones in the doc file, and similarly for the file size and date.
But suppose one contacts a "trusted information database" and that
the CRCs, dates and file sizes all check out. Can we be so confident
that the file has not been modified, as the documentation claims?
Unfortunately no. It is true (as I have emphasized several times in
VIRUS-L) that the CRC algorithm is perfectly secure against forgery
when it is used to detect modification of a file *on a given computer*
(the typical anti-viral application of checksum programs), provided
that (1) each user's generator is unknown to others and (2) the CRC
corresponding to a given file is inaccessible to a virus or other
program planted by a hacker.
However, in the present situation (detection of modifications which
take place during transmission of a file from one computer to *other*
computers) these conditions cannot be satisfied. In particular, the
generators which VALIDATE uses must be the same for all users, and so
it suffices to determine them once in order to be able to modify any
file in such a way as to preserve its CRCs.
Now it so happens that the two generators which VALIDATE uses can be
very easily determined by downloading the PVALIDAT package and examin-
ing the source code. But even if the source were not available, one
could find them by disassembling VALIDATE.COM or by computing them
from a few file-CRC pairs.
Once this has been done, the next step is to "forge the CRCs", i.e.
to modify the bits in some small area of the file so that the CRCs of
the resulting file are the same as those of the original one. Now
trying to forge with respect to two generators simultaneously may seem
impossible to some people, but actually, it's equivalent to forging
with respect to the single generator which is the least common multiple
of both of them (which is of degree at most 32 in the present case).
And once the generator has been determined, the extra modification
required to forge the CRC of a given file can be computed directly,
without need for trial and error. Thus the CRC algorithm, even with
two or more generators, is not sufficiently secure in the present
situation.
Concerning the above-quoted claim that the probability of an
undetected modification is 1 in 64 quadrillion, I confess that it's a
mystery to me where that number came from. From the above it follows
that the probability is 1 in (at most) 2^32, which is about 4.3
billion. But actually, such probabilities are meaningful only when
the file modification is a *random* one, not when it is deliberately
directed against the algorithm. When that is done by someone who
knows the method, the probability is not 1 in quadrillions or even 1
in billions, but simply 1!
The hacker also has to preserve the date and size of the file.
Preserving the date is trivial. In the case of viruses, preserving
file size (actually, and not just apparently) is impossible in the
majority of cases since a (generic, non-overwriting) virus must
preserve functionality of the program while adding propagation code
and damage code. But it's simple in the case of a Trojan, since there
are no functionality constraints and no propagation code.
PKZIP authentication:
This has the advantage over the other two features of authenticating
the sender as well as the files. Still, it is essentially a self-test
and it can be easily circumvented.
One way would be for the hacker, after unzipping McAfee's archive
and modifying one or more of the files, to simply rezip them without
using the authenticity verification option; the user will not get any
message that a file has been modified. And if the hacker also
removes the warning not to use the programs if one does not get the
authentication message, the user will not even *know* he's supposed
to look for such a message.
Another way would be to distribute a hacked version of PKUNZIP
which always displays the decrypted name and code, even in the case
of an authentication mismatch.
These are my reasons for concluding that all three of McAfee's
authentication methods are inadequate. I hope it will not be thought
that my purpose has been to single out McAfee for criticism. Obvious-
ly, if his software is insecure in this sense, then so is all the
other software which uses only a subset of these methods or none at
all, and that's nearly all software. His simply constituted an ideal
"case study" since it has more authentication features than any other
that I know of and since it's so well known in this forum.
Fortunately, there's a better solution (one which gets suggested
every now and then in VIRUS-L): Replace the CRC algorithm in VALIDATE
by a cryptographic hash function (such as MD4) to get a "message
digest" about 128 bits long, and then apply the private-key procedure
of a two-key cryptosystem to this. This solution has a number of
advantages over the above methods:
Unlike VALIDATE, which authenticates only the file, this method also
authenticates the sender; the signatures can be safely supplied along
with the files; and it requires only a one-time public announcement of
the author's public key instead of having to re-announce all the
checksums each time new versions of the programs are released.
As for PKZIP's authentication system, it's true that this also
authenticates the sender. However, unlike PKZIP, with the above
solution the user's authentication utility (based on the public key)
can be supplied independently of any program which it is designed to
protect, and there is no circumvention process analogous to rezipping
of the archive without the authentication option.
Finally, it seems to be computationally infeasible to forge the
signatures of most two-key systems. In the case of RSA, 13 years of
unsuccessful attempts to break it suggest that it is as infeasible to
forge as it is to factor its modulus. In the case of some other sys-
tems, such as those of Rabin and Williams, it has even been *proved*
that this is so, though these systems are more difficult to implement.
On the other hand, there is no evidence, as far as I know, that it's
infeasible to forge PKZIP authentication. And it's certainly possi-
ble, as mentioned above, to forge CRCs in the current environment.
While this solution seems better than any of the above methods, I
don't claim that it's perfect. In particular, the commonly suggested
protocol at the recipient's end seems to me problematic. I have a
suggestion for improving it, but that will have to wait for a future
posting.
Y. Radai
Hebrew Univ. of Jerusalem, Israel
[email protected]
[email protected]
------------------------------
End of VIRUS-L Digest [Volume 4 Issue 60]
*****************************************
Downloaded From P-80 International Information Systems 304-744-2253
