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

Text File | 1995-01-03 | 18KB | 416 lines

VIRUS-L Digest   Friday, 27 Oct 1989    Volume 2 : Issue 224

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:

Using OBJ files to prevent viruses (PC)
Macintoch MacWrite, STR 801 (Mac)
Obj - anti-virus (PC)
Re: Operating System virus protection (DOS & UNIX)
Re: VIRUSCAN/VIRSCAN Issues (PC)
VIRUSCAN False Alarms (PC)
CERT_RCP_Advisory
Can we get a summary?
Virus scanners
Clarifying SAM Comments... (Mac)
Jerusalem virus infects boot sector ? (PC)
PC Problem?

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

Date:    26 Oct 89 09:15:00 -0500
From:    [e-mail]
Subject: Using OBJ files to prevent viruses (PC)

May I suggest that distributing .OBJ files and having the user link
them would only disable current viruses; an obj infector is perfectly
feasible, and could be easier than an .EXE infector.
   More to the point, though, linking applications is not always
feasible at all PC sites. To link AnalytiCalc on a 256K machine with
dual 5.25" floppies is barely possible, with many disk changes, and
requires some skill AND the correct linker (since the linker
distributed with most MSDOS versions cannot handle the particular .OBJ
constructions). This even though the resulting executable will fit
(tightly) in 256K. With an only slightly larger file, linking would be
completely infeasible on such a small engine. In addition to a fairly
onerous "installation" procedure thus invoked, the distribution would
be several times larger than it is; the object library requires an
entire disk, and separate objects needed for overlays take much of a
second. Documents, utilities, and so on are still required.
   Finally, commercial software vendors may be nervous about distributing
.OBJ code. Consider that global symbols, and sometimes internal symbols,
are present in these files. A disassembly of such a beast can be VERY
close to the original code, labels included...especially if the original
is IN assembler. This is wonderful for learning algorithms, etc., but
tends to make it easier to clone applications. In the current climate
I suspect it would lead to a great many more lawsuits based upon suspicions
that competitors' code was derived in part from such sources. Unfortunate,
but likely...
   Then, some object libraries that come with compilers can be linked and
the results distributed; without these, the .OBJ files cannot be linked.
This would also prevent widespread use of .OBJ files.

  In a different vein, may I suggest that a great deal of the hysteria
over viruses stems from the fact that well backed-up PC disks are the
exception rather than the rule. As an industry we should become VERY
upset over machines with inadequate backup hardware and software. More
energy in this direction could render the damage viruses can cause
moot.  By easy backup/restore, I mean hardware such that one can slap
a tape into a slot, type some simple command, and after a few minutes
(over lunch break, perhaps?) come back with the entire volume copied.
Not having this designed into ALL the PCs we use, or at least made a
requirement for those containing business-critical data, seems a
mistake. As Grace Hopper put it, we are terrible custodians of the
data we have/use.

Glenn Everhart
[e-mail]

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

Date:    Thu, 26 Oct 89 10:39:09 -0500
From:    Joe Simpson <[e-mail]>
Subject: Macintoch MacWrite, STR 801 (Mac)

I'm unclear about the STR 801 discussion.  Let me tell a little story
to see if I can further confuse things.

About 4 months ago a client reported that MacWrite was growing in file
size on a public Mac.  I checked to see that VACCINE was turned on.
I ran Disinfectant 1.2.  A clean machine.

I then ran ResEdit to look at the MacWrite file.  There were a large
number of STR 801 resources.  The program was adding STR 801 resources
at some unknown interval.

I replacedthe file with a fresh copy of MacWrite and the problem disappeared.

I put it down to normal computer miseries and not a computer virus.

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

Date:    Thu, 26 Oct 89 10:39:00 -0400
From:    "Paul Bienvenue" <[e-mail]>
Subject: Obj - anti-virus (PC)

    Damon Kelly writes:

>    Earlier this week I was reading a book by Peter Norton.  There was
>a passage about the importance of .OBJ files created by compilers
>(esp.  assembly).  While I was pondering the importance of .OBJ files,
>an idea hit me: since this type of file is non-executable and can only
>run when linked, wouldn't self-attaching viruses be scrambled when the
>"host" file is changed to an .EXE?

    It's a nice idea, but it wouldn't really stop virus writers, just
make life a little more difficult for them. (and possibly for virus
detectors as well) What would keep a virus writer from creating an obj
which would become a virus when compiled?  Also, it would be a real
pain for users to have to compile every piece of software they were
going to use.  Anyone with much assembling experience would also know
how difficult it is to write code which will successfully compile with
all major assemblers.  Good try, though...

                                                    Paul Bienvenue
                                                [e-mail]

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

Date:    Thu, 26 Oct 00 19:89:08 +0000
From:    [e-mail]
Subject: Re: Operating System virus protection (DOS & UNIX)

|  How do you know?  The only machines DOS runs on are PCs and compatibles.
|  UNIX implemented on these machines would be just as vulnerable as DOS.
|  The most obvious weaknesses of DOS are unimportant compared to the fact
|  that the hardware itself has no protection mechanisms.

  True, but only of the 8088 (original XT) machines. The AT and 386
machines run UNIX in protected mode, and have as much hardware
protection as a VAX.
- ---
bill davidsen    ([e-mail] -or- uunet!crdgw1!crdos1!davidsen)
"The world is filled with fools. They blindly follow their so-called
'reason' in the face of the church and common sense. Any fool can see
that the world is flat!" - anon


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

Date:    Thu, 26 Oct 00 19:89:34 +0000
From:    [e-mail]
Subject: Re: VIRUSCAN/VIRSCAN Issues (PC)

  You have a good point about encrypting strings, and I am as guilty
as anyone else of not saying thanks often or publically enough. Due to
the recent flap about viruses, I gave a talk about protection at a
local user group meeting, and distributed about 40 copies of viruscan,
including putting a copy on my BBS.

  I am happy to say that I am not a user of the program, since I run
UNIX, but I have tried it, am impressed, and do provide it to any PC
user who wishes it. Well done, for what it's worth!
- ---
bill davidsen    ([e-mail] -or- uunet!crdgw1!crdos1!davidsen)
"The world is filled with fools. They blindly follow their so-called
'reason' in the face of the church and common sense. Any fool can see
that the world is flat!" - anon


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

Date:    Thu, 26 Oct 89 10:52:42 -0700
From:    portal!cup.portal.com![e-mail]
Subject: VIRUSCAN False Alarms (PC)

This message is forwarded from John McAfee:
=============================================================================

    SCANV45 causes false alarms when used with a number of Jerusalem
Virus detectors/eradicators.  What has happened is this:  I returned to an
earlier version of string identification for this virus in order to avoid
conflicts with a number of newer Jerusalem detectors.  Apparently, however,
the string identifiers used in earlier versions (being unencrypted) were
picked up on by other authors (perfectly legitimate) and used in their
own detectors.  There are over 30 such detector/eradicator programs in use
now.  I stgrongly urge all such authors to do one of two things:  Choose
your own strings, or encrypt them if you use strings from older versions of
SCAN.  Otherwise, your programs will be flagged as viruses not just by my
scanner, but by everyone who chooses those same strings.  The problem is
worsened now cause I use multiple strings for some viruses (to avoid
cracking) and either one of the multiple strings will cause an alarm if
that string is chosen by others and not encrypted.  If authors do not like
the idea of encryption, then ASCII representations can be used (like IBM
uses).  THis will allow your users to see the strings that you have chosen
but will not cause false alarms.  We must all remember that multiple
authors are trying to fight the virus problem, and we should do everything
possible to avoid conflicts with each other's programs.

John McAfee

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

Date:    Thu, 26 Oct 89 21:24:58 -0400
From:    CERT Advisory <[e-mail]>
Subject: CERT_RCP_Advisory


                CERT Advisory

               October 26, 1989

            Sun RCP vulnerability


A problem has been discovered in the SunOS 4.0.x rcp.  If exploited,
this problem can allow users of other trusted machines to execute
root-privilege commands on a Sun via rcp.

This affects only SunOS 4.0.x systems; 3.5 systems are not affected.

A Sun running 4.0.x rcp can be exploited by any other trusted host
listed in /etc/hosts.equiv or /.rhosts.  Note that the other machine
exploiting this hole does not have to be running Unix; this
vulnerability can be exploited by a PC running PC/NFS, for example.

This bug will be fixed by Sun in version 4.1 (Sun Bug number 1017314),
but for now the following workaround is suggested by Sun:

Change the 'nobody' /etc/passwd file entry from

nobody:*:-2:-2::/:

to

nobody:*:32767:32767:Mismatched NFS ID's:/nonexistant:/nosuchshell


If you need further information about this problem, please contact
CERT by electronic mail or phone.


J. Paul Holbrook
Computer Emergency Response Team (CERT)
Carnegie Mellon University
Software Engineering Institute

Internet: <[e-mail]>
[phone] (24 hour hotline)


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

Date:    Thu, 26 Oct 89 21:16:31 +0100
From:    [e-mail] (Clifford A Stevens, Jr)
Subject: Can we get a summary?

I'm new to all this stuff, been on superminis for 10 or so years, so
could somebody post a summary of what a virus is, how it works (in *REAL*
general terms), and how it propogates?

Thanks!

[Ed. This is a frequently asked question; let me "answer" it by
referring you, and others who've asked, to some of the introductory
documents found on the VIRUS-L/comp.virus documentation archive sites
- - or to any of the introductory books on the subject, many of which
can be commonly found in bookstores.]

Who, me worry?!?
    Cliff Stevens    MT1E228  att!cbnewsj!ncas  [phone]

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

Date:    Thu, 26 Oct 89 18:58:33 -0700
From:    portal!cup.portal.com![e-mail]
Subject: Virus scanners

In VIRUS-L #222 David Gursky wrote concerning an earlier posting that
"a strategy that relied solely on a scanner application would not be
a strong defense defense against electronic vandalism."  This is because
"you must remember to periodically scan the disk."

I believe Mr. Gursky is quite correct about not relying solely on a
scanning program.

While I was mainly relying on the technical sophistication of VIRUS-L
readers to know that, I did mention qualifiers such as "very useful
part of an anti-virus program."

Actually, there are programs for the Macintosh (SAM, Virex) that can
be set to check each floppy disk each time it is inserted.  Or a
"log-on" or "log-off" batch file could be used for other machines to
run the scanning program against all the hard disk files.  Even if
that were done, it would still not be adaquate protection against
viruses, even on microcomputers, since it can be effective only
against known viruses.

My point about "How good are scanning programs" is mainly that if the
program uses well-chosen search strings it can be more effective than
I, at least, initially expected.  Several scanning programs for the
Macintosh relied only on resource names (resources include program
code on the Mac).  These resource names, such as nVIR, are very easily
and quickly changed to hPat or anything else, completely defeating the
scanning program.

I always urge clients to use additional detection and prevention, and
am somewhat frustrated that some of them feel that scanning programs will
protect them.

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

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

Date:    26 Oct 89 17:05:00 -0700
From:    harvard!applelink.apple.com![e-mail]
Subject: Clarifying SAM Comments... (Mac)

In response to Henry Schmitt's comments about SAM, I would like to
clear up a few things. SAM does indeed provide a mechanism to view,
edit, and even print its exceptions list (i.e., the alerts that have
been learned). It's quite easy to remove any exception that may have
been accidentally entered. So his comments about SAM letting a virus
through, etc. are not true.

Also, I programmed the alert display in SAM without the help of MacDTS
(I too am simply an independent developer)! BUT, I believe how I do it
is even safer than how Apple does certain similar things! This was the
hardest part of SAM, and required quite a bit of research, testing,
and so forth to guarantee a stable alert under all environments. There
are man-months of work in those alert boxes!!

Paul Cozza
SAM Author

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

Date:    Fri, 27 Oct 89 11:23:16 +0700
From:    "S. Yeo" <[e-mail]>
Subject: Jerusalem virus infects boot sector ? (PC)

Hi everybody,

My colleague passed me a diskette which contains a viruscan program from
Rotterdam this morning. While looking through a file which contains some
virus signatures, I was surprise to learn that all Jerusalem strains
of viruses except Jerusalem (PLO/sUMsDos) virus infect COM/EXE files
as well as*boot sector*.The documentation for this program was written
by J.P. van der Landen and the signatures collected by Jan Terpstra.
Could anyone out there please verify this?
Thanks !

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

Date:    Thu, 26 Oct 89 23:54:48 -0500
From:    James Ford <[e-mail]>
Subject: PC Problem?

A friend who works a company began to experience some interesting problems
on his hard drive.  He works with JL Modula2.  Code that had run in the
past would not work now.  Someone else could put a comment in a file
(however you do that in Modula2), re-compile it, and it would hang.

I gave him a copy of Scan 1.1V45 and Scanres 1.1V45, but they found
nothing strange.  He has purchased a copy of Flushot, and the following
message is from him, describing what Flushot sees.  Can anyone explain
this?  If you need more information from him, send direct to me and I'll ask
him.  For better or worse, the powers-that-be are leaning towards taking all
source code off the hard drives, and doing a lowlevel/highlevel format of
all harddisks involved.  (I have no ideal if he has installed Flushot+
correctly, but he is by no means ignorant when dealing with computers.)

Thxs
James Ford - [e-mail]

===========================================================================
Sent : Oct 25, 1989  at 5:44 PM
Subj : Re: <1446> Bit

(...after running SCAN 1.1V45, it found...)

Not a thing.. it found nothing either on my systems or the ones at work.
I'm still totally convinced something is sorely amiss, however.  We
installed Flu+ and watched JPI's Mod 2 compiler/linker do all kinds of
strange calls (Flu+ labeled them as 'handle write access attempted'
operations, but they appeared to be reads... why would anyone write to a
'DEF' file during a link?  I checked them with a disk editor afterwards
and found nothing but pure ASCII text...)

I did discover one interesting thing.  When you copy a non-executable file
with COMMAND.COM, Flu is perfectly happy.  When you copy an EXE, COM, etc.
file you get the old 'handle write access attempted' msgs. Curious. Why
would COMMAND.COM care what type of file is being copied?  It seems to use
DOS to open the file and the BIOS to transfer the data or something.

The only thing I can figure with the compiler is that the program opens
the file for READ/WRITE and Flu+ flags it just to be safe.  We all got
tired of the beeping, and Dean absolutely refused to believe anything was
wrong, so everyone just kinda went back to doing their stuff and just
checked it occasionally.

Anyway, I really appreciate your uploading SCAN45 - I'm gonna keep pluggin
and see if I can find out the problem. I'm also gonna call McAffee Assoc's
board tonite and see what I can start finding out.  Thanks!

- -=Marcel=-
====================== end of note ========================================

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

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