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

Text File | 1995-01-03 | 11KB | 245 lines

VIRUS-L Digest             Tuesday, 16 May 1989        Volume 2 : Issue 117

Today's Topics:
re: PC Virus List
Re: Macintosh virus query
blown floppy disk (PC)
Re: Virus-proof PC
re: The only good virus is a dead one
Virus in data files (MAC)

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

Date:    16 May 1989, 13:05:24 EDT
From:    David M. Chess  <[e-mail]>
Subject: re: PC Virus List

Nice list!   A couple of notes:

- - I suspect that the "Vienna" (number 5, characteristic size 648)
  is exectly the same virus as the "DOS-62" (number 10).  It sounds
  that way from Jim Goodwin's list, anyway; the sample that I have
  grows COM files by 648 bytes (like the "Vienna") and overlays
  victims with reboot code one time in eight (like the "DOS-62").
  So I'd suggest that they're the same code, unless there's
  evidence otherwise.

- - There are in fact two variants of the "DataCrime"; one makes
  files bigger by 1280 bytes, and one makes them bigger by 1168.
  They seem to be functionally identical; the differences are
  just slightly tighter coding, and not saving some uninitialized
  scratch areas.

I'd be interested in more info on the "Nichols"; I've seen the
name here and there, but never a real description.

I'd also be interested in a complete set of descriptions of
all these, of course!   *8)

DC

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

Date: Tue, 16 May 89 10:42:04 PDT
From: [e-mail] (Dave Platt)
Subject: Re: Macintosh virus query

> Has there ever been a macintosh virus than is part of a document? The
> macintosh has both data and resource forks. It would be interesting to
> create a macwrite or MS-word document with the document in the data
> fork and the virus as a code resource that is preloaded to override an
> application code resource (the printing code comes to mind). This
> would allow documents as well as applications to transfer the virus.

I've never heard of a virus that could successfully insert itself into
a Mac document, and have the resulting document be infectious.

There's a reason for this.  Many Mac applications don't use the
resource fork of their document files at all... all of the significant
information is stored in the data fork.  Apple recommends against
attempting to treat the Resource Manager as a database package (it
bogs down, badly, if you try to load too many resources into a single
file).

Some applications do store a limited amount of information in the
resource fork of their documents.  Many text editors, for example,
store font/point-size/tab-width information in the resource fork;
there are some resource-types that have acquired "conventional uses"
of this sort.

Opening the data fork of an file does _not_ automatically open the
resource fork and make the resources available... this must be done
separately.  In my experience, applications that store information in
the resource forks of their documents usually don't keep this fork
open for a long period of time... the resource forks are usually
opened only for the amount of time that's needed to load the desired
resources into memory, and are then closed.  When the resource fork is
closed, any and all resources that had been loaded from the resource
file will be purged, unless someone has issued a DetachResource() call
to unlink them from the file.

Therefore, there's only a very narrow window in which a virus-resource
in a document-file's resource fork could be loaded "by mistake".  The
virus would have to masquerade as a portion of code that the
application would execute _before_ the document file's resource fork
was closed...  otherwise, the viral resource would be purged before it
could ever be executed.

This is certainly possible... but I believe that the "window of
vulnerability" is so small, and so application-specific, that a
general-attack virus could not propagate itself effectively in this
manner.

Also, most of the free and commercial virus-blocking INITs
(GateKeeper, Vaccine, et al) would detect the attempt of a virus to
write a CODE resource into a document, and would raise the alarm.

I do know of one Mac virus (ANTI) which can infest nonexecutable
resource files (such as the Desktop file, the Scrapbook, and so
forth), and into documents whose resource-forks are used by the
applications that create them.  ANTI patches itself into the Resource
Manager and injects a copy of its INIT into any resource-file that's
opened by any application.  However, nonexecutable files containing
this INIT are not themselves infectious... the INIT is never executed.

Dave Platt    FIDONET:  Dave Platt on 1:204/444    VOICE: [phone]
UUCP: ...!{ames,sun,uunet}!coherent!dplatt  DOMAIN: [e-mail]
INTERNET:   coherent![e-mail],  [e-mail]
USNAIL: Coherent Thought Inc. 3350 West Bayshore #205 Palo Alto CA 94303

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

Date:    Tue, 16 May 89 13:40:55 EDT
From:    "W. K. (Bill) Gorman" <[e-mail]>
Subject: blown floppy disk (PC)

     I have a 5-1/4" floppy disk under examination for possible virus
damage, and have run into an interesting problem. The disk acts like
it is totally unformatted; neither CHKDSK, RECOVER, the Norton stuff,
or anything else seems to be able to access it. The result of this is
that I cannot see anything about what has happened to the disk. What I
need is a good pd or shareware sector editor that can get at the
absolute sectors w/o trying to read the directory (or else a
reasonably cheap commercial one), although I am not sure that will do
any good, since I cannot write to the disk (no, it is not write
protected) either.
     Perhaps a little history is in order. The disk was obtained from
a student employee in one of our administrative offices. My initial
response was to suspect that the disk had been mistreated in some way,
resulting in a total erasure of all data and format information. Both
the student and his boss, however, insist that the failure occurred
spontaneously while using the disk, and that it has happened more than
once. Suspicious, IMHO. I could format the disk and probably make it
useful again, but that would defeat the purpose of my investigations.
I repeat, I am *not* certain that this is a virus case, but I
definitely would like to find out what happened to this disk (and
recover the student's files, just to be a nice guy (!) in the
process). Since we are currently awash in nVIR, SCORES, and
gawd-knows-what-else, I think an investigation of this problem is a
reasonable approach.
     Suggestions? Comments? Flames? Nasty notes?  :-)

.........................................................................
|W. K. "Bill" Gorman                              Foust Hall # 5        |
|PROFS System Administrator   E-Mail & Message    Computer Services     |
|Central Michigan University Encryption/Security  Mt. Pleasant, MI 48859|
|[e-mail]       Virus Countermeasures [phone]        |
|_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_|
These comments reflect personal opinions held at the time this was written.
Copyright (C) 1989 W. K. Gorman. All rights reserved.

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

Date:    16 May 89 14:20:00 EST
From:    "BARRY NEWTON" <[e-mail]>
Subject: Re: Virus-proof PC

The only ways I can imagine to implement a "virus-proof" PC involve
marking executables with some sort of authorization signature or
placing them on a list of authorized programs.  Either activity is
probably too much overhead for most organizations.

If the authorization process is centrally controlled, users will
revolt and defeat it.  If it is not centrally controlled, it would be
totally useless.

Barry Newton
National Institute of Standards and
Technology (Which is neither aware of nor interested
in my opinions expressed here)

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

Date:    Tue, 16 May 89 20:05:02 BST
From:    Neil Youngman <[e-mail]>
Subject: re: The only good virus is a dead one

>From:    well![e-mail] (Michael Odawa)
>In VIRUS-L 2-112, Allan Pratt mentioned the possibility of back door
>neutralizers and other methods of disarming a potentially "beneficial"
>virus which might unintentionally run amuck, contending,
>
>> you can deliberately code in an easy way to kill the thing, such as the
>> presence of a file with a certain name, or a certain magic number in a
>> cookie someplace in RAM.

To add my few pence worth:

1: How many of these things are there going to be? I could need
hundreds of "antibody" files or magic numbers in RAM locations that
might have other uses.

2. What if there's a bug in the self-destruct test?

3. What about people who don't know how to kill it?

4. What about mistakes like the INTERNET worm? If you are going to
test it there might be problems with it spreading in an unexpected
fashion. (God forbid the release of an untested version).

>The only good virus is a dead one.

Very true.

>Michael Odawa

Neil Youngman, Computer Science Dept, Exeter University,
Prince of Wales Road, Exeter, Devon, EX4 4PT, UK.
        UUCP:   [e-mail]          JANET:  [e-mail]
"The lights are on but Mr Brain is not at home!"

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

Date:    Tue, 16 May 89 14:37:43 EDT
From:    [e-mail]
Subject: Virus in data files (MAC)

In a recent Virus-L (May 15), Emil Rainero
(rocksanne![e-mail]) raises the possibility of a virus
hiding in the resource fork of a data file.

Generally, such a virus would not be very successful at propogating,
if this were the lone method of propogation (using the resource fork
of data files).  Information in resource forks are generally not
executed.  There is (however) a notable exception to this.

INITs, cdevs, and the like are "data" files; they contain no CODE
resources that make an application an application.  Conceivably, they
could be used to spread a virus as the information in the
INIT/cdev/... is executed at system startup if the file is in the
system folder.  The INIT 29 virus makes use of this.  It will infect
the resource fork of data files, and should such a data file reside in
the system folder, the virus will be executed from the data file when
the system is next started.

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

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

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