Hacker 2/HACKER2.mdf/virus/virusl2/virusl2.221

Text File | 1995-01-03 | 23KB | 488 lines

VIRUS-L Digest   Tuesday, 24 Oct 1989    Volume 2 : Issue 221

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., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

Today's Topics:

Re: Gatekeeper false alarm? (Mac)
Re: SAM vs. Gatekeeper (Mac)
RE: Superclock non-virus... (Mac)
Re: INIT 29 question from Jim Bradley...
IBM Virus Scan program (PC)
Virus source available in Toronto
IBM's Virscan Program (PC)
VIRUSCAN test (IBM PC)

---------------------------------------------------------------------------

Date:    23 Oct 89 21:27:20 +0000
From:    ut-emx![e-mail] (Chris Johnson)
Subject: Re: Gatekeeper false alarm? (Mac)

In VIRUS-L Digest V2 #217, Richard Kennaway ([e-mail]) writes:

>Paranoid speculation follows.

Paranoia, being a disease, is an inherently bad thing.  What follows is, I
believe, an unfortunate illustration.

>Maybe someone is using the Joker's trick.  There could be several
>infected applications out there, all quietly spreading harmless-looking
>things like STR 801 that dont ring GateKeeper's alarms, but when they
>all come together in one application, the real virus is triggered...

More likely, there's no virus *at*all*.  I do believe this is pure paranoia.
Further, there's a good reason that things like STR resources look harmless:
they are.  Period.  They aren't executable, so they don't get executed.  In
and of themsleves they are *utterly* harmless.  The end.

For a virus to spread executable code has to move.  Although *no* anti-virus
scheme is perfect, that is exactly the kind of thing that Gatekeeper watches
for.  There's no such dichotomy as "real virus" versus un-real virus - either
it is a virus, or it isn't.

That means that this "Jocker's trick" is essentially nonsense - in order for
the "harmless-looking things like STR 801" to spread there has to be a real-
live virus *doing* the spreading - a virus which, in all probability, systems
like Gatekeeper will stop.

>Plug for Virus Detective: with this it was easy to search for all files
>containing STR 700 (legitimate MacWrite resource) or STR 801.  All the
>other virus detectors I've seen have the symptoms to look for
>hard-wired.  I have no relationship with the author other than being a
>satisfied customer.

Philosophical Point:  The problem with tools is that the users have to under-
stand how they work, what they do, and how to use them.  A failure of the
user on any of these points results in the tool being unable to accomplish its
intended purpose.

Virus Detective is a fine tool, but it's not being correctly employed here.
Sure enough, most MacWrite files have STR 700 and 801 resources, but just
because Virus Detective will allow a person to discover this, *doesn't*
in any way indicate the presence or involvement of a virus.

Like any tool Virus Detective can be used correctly or incorrectly -- in this
case it is being used in an incorrect manner, since the key issue,
whether or not there is any reason to believe a virus is involved, has
been sidestepped.  Virus Detective is now merely serving as a tool to "confirm"
baseless fears and assertions.

Gatekeeper being more a "system" than a "tool", is less prone to feeding
wild speculation, since it has its own means of identifying the presense of
a virus and, as a result, does not require that the user be a skilled Mac
programmer capable of searching out and analyzing would-be new viruses.  Of
course, Gatekeeper is fallible... but that usually means that users are merely
required to tell it what *isn't* a virus, rather than having to search out
new viruses from scratch like searching for needles that may-or-may-not be
hidden in hay stacks.

STRs 801 and 700 are good examples of strands of hay mistaken for needles.

Returning to Gatekeeper, the symptoms are not quite "hard-wired".  Gatekeeper's
philosophy is, basically, that if a virus can't move, add, modify or delete
executable resources (there are about 24 types), then it can't spread.
And a virus that can't spread isn't really a virus anymore.  Of course, you'll
still want something like Disinfectant to remove the effectively sterilized
virus.

The list of executable resources is certainly not hard-wired - it's easily
edited by following the instructions in the on-line help.  The type of
monitoring that Gatekeeper does *is* hard-wired, but in order to establish
that this is a problem, a way must first be found to spread a virus without
moving, adding, modifying or deleting executable resources.

In short, the hard-wired aspects of Gatekeeper are not a problem - they are
*fundamental* protections.  This is why Gatekeeper has been able to stop
every Mac virus discovered to date, including totally new viruses like
ANTI and INIT 29 which were developed *after* Gatekeeper was written.
I should add that Gatekeeper's security system has not had to change since
it was first released on 2-Jan-89, precisely because it is such a fundamental
approach to stopping viruses.

Gatekeeper isn't perfect - no anti-virus system is - but it's very good.

I, personally, tend to be a bit defensive with regard to Gatekeeper because
I've observed a number of misconceptions that do it sad injustices, while
johnny-come-lately packages like SAM and the Virex INIT, etc. are heralded
as the first and only fundamental solutions to the Macintosh virus problem.

Since Gatekeeper was discussed here in a misleading manner I thought it was
important to try to put an end to, at least, the misconceptions illustrated
here.

As to the alleged MacWrite virus - paranoia tends to spread... and I've
seen a number of postings to other newsgroups from people scared because
they've discovered perfectly normal STR resources in their MacWrite documents.

This never should have happened.

The fact is, the burden of proof is on he who asserts the positive.  Yet, for
all the talk about this new virus, there's still been no offer of proof of
the virus's existence.  Nonetheless, the paranoia spreads due to these
baseless assertions.  If there's some proof, we *need* it and blessings upon
whoever provides it, but, for lack of that proof, this discussion should
have been terminated long ago.

Given that there's been a delay in the VIRUS-L news recently, maybe this
discussion has already died, and I've ranted on needlessly.  I certainly
hope that's the case.

- ----Chris (Johnson)
- ----Author of Gatekeeper
- [e-mail]

------------------------------

Date:    23 Oct 89 22:09:00 +0000
From:    ut-emx![e-mail] (Chris Johnson)
Subject: Re: SAM vs. Gatekeeper (Mac)

In VIRUS-L Digest V2 #216, Henry C. Schmitt writes:

>I have used both GateKeeper and SAM Intercept and I prefer the
>latter.  The main reason?  When "something suspicious" happens,
>GateKeeper says "you can't do that!" then if you want to override,
>you must open the Control Panel select GateKeeper and set up the
>permission; with SAM Intercept, at the time of the happening you can
>allow the action once or LEARN the action then and there!

The reason Gatekeeper does not bring up a custom dialog that would
let the user allow an operation, is neither sloth, nor indifference to
the plight of the user.  The reason is *compatibility*.  Apple will
guarantee that the Notification Manager, which Gatekeeper uses to display
its alerts, will be compatible with virtually all software and will certainly
be compatible with all future versions of the System.  SAM's custom dialog
may break in future releases of the System - or it may not.  For myself,
I can't think of any method that's worth the risk.

Since the author of SAM probably had support from Apple DTS, he may have
been provided with techniques that would make a safe implementation possible.
I, regrettably, have no real access to DTS (becoming a registered developer
requires money I just don't have).  If anyone at DTS would be willing to
offer some advice on safe ways of approaching the custom-alert problem, I'd
*love* to hear it.  (Hint, hint.)  :-)

One other point though (and please correct me if I'm wrong), I've been told
that SAM doesn't provide a way to view all of the privileges that have been
granted to various applications, let alone a method of editing them.  If this
is the case, I have to view it as a far greater problem with SAM, than on-the-
fly configuration is with Gatekeeper.  If someone using your machine inadvert-
antly or unwittingly clicks on the LEARN button when a virus attack is
detected, your copy of SAM will have been programmed to let a virus attack
succed in that case, and you'll probably never find out.

Like I said, though, please correct me if I'm mistaken.

On the subject of the Gatekeeper Log file:

>I only see this as being useful if you're trying to track the
>propagation of a virus, but then you have to allow the "suspicious
>action" which GateKeeper doesn't do (unless you gave permission, in
>which case it isn't logged!)

Depends what you mean by "propagation."  If you mean the successful spread
of a virus, then yes, Gatekeeper won't tell you much simply because it won't
permit the spreading to occur in the first place. :-)

But consider what the log file *does* do for you... it will tell you where
all of the infection attempts originated from, when they started, what
characterized the infection attempt, and it'll even tell you whether or not
your machine was booted on a floppy disk and infected that way.  Furthermore,
if you're a person attempting to quickly gain an understanding of a virus'
infection mechanism, running Gatekeeper on a test machine in its "notify only"
mode will give you an immediate run-down on how the virus works.

Also, each virus has its own "signature" - even when Gatekeeper stops the
virus' spread - in the log file.  It is easy, for instance, to tell INIT 29
from Scores merely by looking at the records of their failed attempts at
infection as recorded in the Gatekeeper Log.  This makes it equally easy
to indentify both new strains of existing viruses, and totally new
viruses.

The log file provides an incredible amount of documentation that can be,
I believe, extremely useful in protecting an individual or an entire
corporation from the influx of viruses.

>I'm not trying to put down GateKeeper, if you want to fight viruses
>cheaply, it's a must!  Keep up the good work Chris!
>
>                        Henry C. Schmitt

Thanks!  Gatekeeper 1.2 is in the works.

In the same spirit, I'm not trying to put down SAM - I'm just trying to make
sure that Gatekeeper gets full credit where it's due.

- ----Chris (Johnson)
- ----Author of Gatekeeper
- [e-mail]

------------------------------

Date:    Tue, 24 Oct 89 08:32:07 -0400
From:    [e-mail] (David Gursky)
Subject: RE: Superclock non-virus... (Mac)

Superclock (in the general case) is not a virus.  It is a legitimate
cdev that displays the current time-of-day in the upper right hand
corner of your Mac's screen.  The current version is 3.5 (although I
thought I saw a 3.6 yesterday).

It is more likely that the "Superclock" virus is simply an occurance
of (if I have to pick one) the INIT 29 virus, or a strain therof.

Superclock is not a stand-alone application; it is a "control panel
device" that is loaded into RAM at start-up.  In the MS-DOS world,
Superclock would belong to the class of applications called "TSR"s
(Terminate and Stay Resident).  In the Macintosh world however, cdev's
(and their sister's RDEVs (Chooser devices) and INITs (classic TSRs))
contain their code in resources called (appropriately) INIT.  Classic
Macintosh viruses (such as nVIR and strains, Scores, Peace, and ANTI)
infect code in CODE resources.  Only INIT 29 infects code stored in
INIT resources.

Another possibility is that the "Superclock" virus is a wholly new
strain.  While this is not impossible, I find this less likely.  The
Mac is a not as easy a machine to program and acquire expertise on as
MS-DOS platforms.  Consequently, there is simply a smaller number of
potential virus-writers (proportionally) than in the MS-DOS world.

David M. Gursky
Member of the Technical Staff
Special Projects Department, W-143
The MITRE Corporation

------------------------------

Date:    Tue, 24 Oct 89 08:50:37 -0400
From:    [e-mail] (David Gursky)
Subject: Re: INIT 29 question from Jim Bradley...

In Virus-L V2 #220, Jim Bradley asked if an application on a clean
disk opened a data file infected with INIT 29, would the application
then become infected.

No.  While INIT 29 is capable of infecting data files, the virus is
"dormant" essentially.  Code in INIT resources is only executed at
startup, and no other point.  Data files infected with INIT 29 only
represent a threat to your system if they are kept in the same folder
as your System and Finder files.

------------------------------

Date:    Tue, 24 Oct 89 11:09:00 -0400
From:    "Gerry Santoro - CAC/PSU 814-863-4356" <[e-mail]>
Subject: IBM Virus Scan program (PC)

I like the fact that the IBM virus scanning program reads its strings
from an ASCII file provides the capability for updating this program
for new viruses.  (I still like McAfee's SCAN program too, and would
recommend that a user have BOTH, just to be safe.)

My question, are there any plans to add updated virus scan strings to
the IBM virus scan data file and have this string file available on
one of the anti-virus servers?  This could help a lot of people avoid
duplication of effort.
- -----------------------------------------------------------------------------
gerry santoro, ph.d.                         *** STANDARD DISCLAIMER ***
center for academic computing              This  posting   is  intended  to
penn state university              |       represent  my personal opinions.
gms @ psuvm.psu.edu              -(*)-     It is not representative  of the
gms @ psuvm.bitnet                 |       thoughts or policies  of  anyone
...!psuvax1!psuvm.bitnet!gms               else here or of the organization.
[phone]                               ---- "I yam what I yam!" ----
- -----------------------------------------------------------------------------

------------------------------

Date:    Tue, 24 Oct 89 12:01:49 -0400
From:    Russell Herman <[e-mail]>
Subject: Virus source available in Toronto

Disassembled source code for the PC virus producing a bouncing ball
onscreen just appeared on a major Toronto BBS.  It does not appear to
be quite correct, nor will it assemble nonfatally with either MASM 5.1
or TASM 1.0.1 (small comforts).  Furthermore, the comments are in
Portugese, although the file was dubbed "italiano.asm".

Now the world has been given the template for an infector (sigh).

[Ed. The book "Computer Viruses: A High Tech Disease", published by
Abacus, contains several (functional) source code examples, in various
languages on various hardware/software platforms, of viruses.  This
book is readily available in bookstores and from the publisher.]

- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Russ Herman     | Internet: [e-mail]    | University of Toronto
Comp. Sys. Mgr. | UUCP:     uunet!utai!me!rwh     | Dept. of Mech. Eng.
[phone]   |                | 5 King's College Rd.
[phone]fax|                | Toronto, ON M5S 1A4 Canada

------------------------------

Date:    Tue, 24 Oct 89 12:38:00 -0400
From:    <[e-mail]>
Subject: IBM's Virscan Program (PC)

I just subscribed to this list, so this posting may be redundant.
Bear with me...

  I worked for IBM over the summer and had a chance to take a look at
their VIRSCAN program, which others have discussed on this list.
Unfortunately the version I used is listed as "IBM Internal Use Only",
meaning that It is only to be used for IBM related purposes.
According to the Forums I read on the IBM network while working there,
VIRSCAN is supposed to be one of the better programs for detecting
known viruses.  What I would like to know is if there is a similar
version of this program available to the general public, and if so how
to get a copy of it.  Also, if a public version of this program is
available, how are updates to the virus signature files (SIGFILE.LST
and SIGBOOT.LST for VIRSCAN) kept up to date, if they are at all?

  Bruce Pennypacker
  [e-mail]
  [e-mail]

------------------------------

Date:    Tue, 24 Oct 89 07:41:08 -0700
From:    portal!cup.portal.com![e-mail]
Subject: VIRUSCAN test (IBM PC)

These results apply to versions through V38.  The current version at
this time is V45.  Changes are made at least once per week, it seems,
to keep up with new viruses, and I finished the work about the time
this digest went off for a couple weeks.

VIRUSCAN, for the IBM PC, from McAfee Associates, was tested using 23
actual viruses or strains of virus.  These included boot or partition
viruses such as Stoned, Ping Pong, and Brain, and .COM or .EXE viruses
such as Datacrime (1168, 1280, Datacrime II) Jerusalem, Icelandic
(several varieties) and Fu Manchu.

In each case, with two exceptions (noted below) VIRUSCAN correctly
identified the viruses after they had infected programs or disks, and
located all instances of infection in all subdirectories of the hard
disks.

One version of the program, before V35, failed to detect the 405
virus, but this was corrected in later versions.  Suriv 300, a
Jerusalem variant, was not detected in an .EXE file, but was caught in
a .COM file.

Based on the testing I did, VIRUSCAN appears to be a well-written and
effective program for locating specific known viruses, and is a very
useful part of an anti-virus program.

Next question:  How good are scanning programs?

There seems to be a perception, at least as written in several sources, that
scanning for known viruses is the weakest method of detecting viruses.  This
is probably based partly on the assumption that the slightest change in a
virus will defeat the effort to detect it using byte strings.  Experience
shows that minor changes are frequently made to microcomputer viruses.
Perhaps the most freqent change is to imbedded, non-encrypted, text strings.
Changes are also made to the infection trigger or activation conditions or
dates.

Obviously, changes can be made to any virus to defeat any particular scan
string.  This has already occurred in the Macintosh world, but most changes
made so far have been on the same level of difficulty as changing ASCII
strings.

Inspection of a search string in VIRUSCAN and/or its location in the virus
code can show that a particular search string is not based on imbedded text,
and that changing the text will not interfere with detection.  A number of
viruses were checked for this.

Also, it is easy to determine that text added to a boot sector in the
Yale/Alameda virus, for example, to make it look more like a normal boot
sector would not interfere with its detection.  If the search string used in
the scanning program is at a different location than the added text, it
won't interfere.

On other changes, I found that with a partial disassembly, or one that was
perhaps incorrectly interpreted by me, changes to what appeared to be an
infection trigger did not replicate with the virus, or did not cause the
anticipated change in virus behavior.

For this reason, it seemed more efficient, and probably more accurate, just to
make a common type of change to a virus, and test VIRUSCAN again.

Each virus was modified by patching it, making minor changes in the
executable code on the disk.  Each modified  virus was allowed to infect at
least one other program to produce a second generation virus.  The final
infected program was inspected and run to ascertain that the modification
was correctly transmitted  with the virus.  This established that there was
a viable new strain of virus.  VIRUSCAN was run to see if it still found the
modified virus.

- --------
Viruses modified and detected by VIRUSCAN version 0.5V34 or later versions
through V38.


 -Virus name-                        -Type of modification-



 Ping Pong boot Virus (Italian)         Activation window time was
                                        increased

 Jerusalem Virus - Version D            Activation date changed

 1280 Virus (Datacrime)                 Activation (destruction)
                                        date changed

 1168 Virus (Datacrime)                Activation (destruction)
                                        date changed

 Vienna (DOS 62) Virus - Version A    Manipulation task to move
                                        5 bytes to corrupt
                                        infected program was
                                        changed.

 405 virus                              Changed to seek and infect
                                        hidden files

- -------------

Conclusion:

A well-chosen search string for a virus can survive at least some of the
common changes to viruses that are made as they pass through different
hands.  A good scanning program can provide better protection than it might
appear at first glance.

VIRUSCAN is available from BIX, CompuServe, and other sources, including the
Homebase BBS, at 408-988-4004.  On Homebase, the latest version is
SCANV45.ZIP.

Disclaimer:  I am a computer security consultant and have been
working with PC and Macintosh microcomputer viruses and anti-
virus products for about 18 months. I have no obligation to John
McAfee except to report the outcome of the tests.  Information Integrity is
a member of the Computer Virus Industry Association, which is operated by
John McAfee.

Charles M. Preston                             907-344-5164
Information Integrity                          MCI Mail  214-1369
Box 240027                                     BIX  cpreston
Anchorage, AK  99524                           [e-mail]

------------------------------

End of VIRUS-L Digest
*********************
Downloaded From P-80 International Information Systems 304-744-2253