Hacker 2/HACKER2.mdf/virus/virusl3/virusl3.76

Text File | 1995-01-03 | 15KB | 333 lines

VIRUS-L Digest   Monday, 16 Apr 1990    Volume 3 : Issue 76

Today's Topics:

Disinfectant 1.7 (Mac)
MACs for Programs
Re: Death of a Virus
Friday the 13th of April Computer Virus??? (PC)
Re: Virus in Text Files
First computer virus extinct?
WDEF A on Chessmaster 2100 and Cribgin (Mac)
Re: Loophole in VIREX 2.6? (Mac)
Jerusalem-B Virus (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 [e-mail] (that's equivalent to
LEHIIBM1.BITNET for 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: [e-mail].

   Ken van Wyk

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

Date:    Fri, 13 Apr 90 15:02:44 -0500
From:    Norbert Bornfeld <[e-mail]>
Subject: Disinfectant 1.7 (Mac)

I have major problems downloading the binhexed 1.7 version from the info-mac
archives as well as from the anti-virus sites as described in this list.
The file seems to be corrupted and decoding the file I get an
EOF-error message. Any solutions?
N. Bornfeld, University of Essen


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

Date:    Fri, 13 Apr 90 11:44:00 -0400
From:    [e-mail]
Subject: MACs for Programs

>The first system usable for this is
>the RSA public key encryption system. For a MAC, you encrypt the
>checksum with the privat key of the author and append it to the
>message. It can be decrypted by anyone using the public key which has
>to be obtained once, and then the checksum can be checked.
>Unfortunately, it is patent copyrithed (sic)in USA .....

It is true that RSA is protected by patent and copy right in the U.S.
However, I am not prepared to grant that that is "unfortunate," or somehow
removes it from consideration.

>and requires lengthy
>computations of prime numbers for the keys, ....

Again, true but irrelevant.  If you were going to perform a function often,
its speed would be important.  However, the key is only computed once, by
the originator; even if it takes minutes, who cares.

>and depends both on the
>problem of factorisation and the discrete logarithm.

And, once more, irrelevant, unless, of course your interest is only in
promoting an alternative.

>But there is an alternative scheme: the ElGamal-Scheme.

But of course.  Indeed, there are several.   Let us not forget the
Xerox Secure Hash Function (Snefru).

Incidentally, the sponsor of this algorithm admits that it might be a
little slower than RSA at checking time.   Right!  RSA is slow at key
generation, fast at calculating the signature, which is done more often,
and very fast at checking the data against the signature, which is done
most often.

Any number of existing and theroretical functions will enable us to
determine that the probability of change is vanishingly small, at
least as long as we have a trusted source for the MAC.  However, RSA
has the advantage of providing for attribution of both origin and, if
each person in the chain adds his signature, any change.

All that having been said, the important thing is to start using something.
Part of the reason that we have not done so is that we insist upon seeing
the value as the receiver not running something that he does not intend.
On the other hand, if such a function were available, most people would
not calculate it before running the code.

The real value is in an author not being held accountable for something
that he did not write.  Given the potential for someone adding a virus
to my code, I would not write code for publication where I did not
compute such a value and publish it at least as widely as the code.
Then, if as has happened to readers of this list, someone was damaged
by code that he thought to be mine, but which had been subsequently
maliciously modified, I would be able to demonstrate that the code
used was not the same as what I shipped.  I would be protected even if
the end user, who failed to compute my function, was not protected.

Authors, the use of a MAC serves you even if no one ever reconciles it.
It is cheap.  You have a choice of functions, security, and costs.  The
choice is yours.  Pick one, but do something.  Use several; they are
cheap.

William Hugh Murray, Executive Consultant, Information System Security
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840
203 966 4769, WHMurray at DOCKMASTER.NCSC.MIL

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

Date:    12 Apr 90 00:00:00 -0500
From:    "David.M..Chess" <[e-mail]>
Subject: Re: Death of a Virus

Dave Ihnat <[e-mail]> writes various things, including:

> Systems which provide the underlying hardware CAN be made much more
> secure.

>               Attacks on such multi-user/multi-tasking systems that
> are successful invariably result from either errors in the protection
> mechanisms (usually, not the hardware itself, but rather the operating
> system which utilizes it) or errors in application of the provided
> protections, either by programmers (privileged programs that don't
> properly control access, etc.), or by administrators and users who
> don't use such capabilities as ACL's and file permission settings.

I agree completely with the first; systems with no concept of security
are in general much harder to write reliable anti-virus software for
than systems that provide a trusted kernel, or rings, or other ways
to protect some software from other software.

I disagree with the second, though; unless you label any setting of
access levels that allows some programs to write to others as
an "error", viruses can spread even in systems that have reliable
access controls which are being used properly and without error.
How many installations can you think of where no program *ever*
legitimately writes to another?

I think the reasons that we have seen microcomputer viruses, but no
large-system viruses are primarily "cultural" (writing viruses hasn't
become "the thing to do" in the mainframe underground, there simply
aren't as many mainframe programmers, large installations don't tend
to exchange software yet, and so on).

DC

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

Date:    13 Apr 90 18:19:15 +0000
From:    [e-mail] (Marilyn Bushway)
Subject: Friday the 13th of April Computer Virus??? (PC)

Hello we are experiencing what we believe to be a virus.  It just hit
today.  Symptoms: All executable files are destroyed and must be
reloaded.  It is only on P.C.'s (Dos machines) It just hit the campus
today which is Friday the 13th.  Is there a virus out there that we
didn't know about???  Does anyone know of a utility for ridding the
machine of it.

[e-mail]

- --
Marilyn Bushway  3181 S.W. Sam Jackson Park Rd. Portland, OR  97201
[phone]   {ogicse,qiclab,uunet,tektronix,nosun,psueea} ohsuhcx!mkb

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

Date:    Fri, 13 Apr 90 23:35:06 +0000
From:    rutgers!tiger.ecn.purdue.edu![e-mail] (Ashar Nisar)
Subject: Re: Virus in Text Files

cdss![e-mail] (Tom Culliton) writes:
>[e-mail] (Dr. Ruth Mazo Karras) writes:
>
>How many times has this question been answered?  If you can't execute
>the file or run it via an interpreter it can't carry a virus.  If its

That is a very general statement.... and flase too!

Technically yes you may be right... but you never know if somebody
can't exploit any bug in the systems software to get the control of
the machine... even when APPARENLY the system is just READING a text
file etc.

An example is the Internet worm that used a bug in mail system Now
mail system apparently only reads/sends text mail.... and there is no
reason why such a bug can not exist in current PC software, especially
with so many third party Network/LAN/mail/tcp etc implementations

Not likely, BUT there is NO guarantee

- -ashar

[e-mail]

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

Date:    Sat, 14 Apr 90 00:53:22 -0700
From:    [e-mail] (Joe Dellinger)
Subject: First computer virus extinct?

In article <[e-mail]> [e-mail] (Per Lindberg) writes:
>He he... Single-host viruses dies out when their host dies out.
>Will this be the first COMPUTER virus destined for extinction?
>Why isn't the WWF doing anything!!??

Well, there is an interesting point here: Macintoshes and IBM PC's seem to
be CRAWLING with many strains of viruses. One person on comp.virus reported
a single file infected with three viruses simultaneously! On the other hand,
it seems viruses on Apple ]['s were pretty rare. A few existed, including
mine, but none of them ever seems to have reached anywhere near epidemic
proportions. Most Apple ][ users I've heard back from report NEVER
encountering _any_ viruses.

What's the difference? An Apple ][ was an ideal machine to write a virus
for. There was massive copying of software. There's been plenty of
time for viruses to have become entrenched. Why didn't they? My guess is that
the proliferation of non-standard DOS's (I never realized there were so many
DOS variants in common use out there. Dozens of them. Wow!) and the LACK of
standard methods of interfacing with the OS (such as it was) are responsible.
Most viruses are _extremely_ host-specific, where "host" means both the
hardware AND the OS.

Can we infer the general rule that a heterogeneous software population is the
best deterrent to runaway infection? (After all, people have a large number
of different HLa types. Why? Smallpox is much deadlier for people with blood
type "A" than "O". Why are there any people with bloodtype "A" still around?)
Our computer's non-standard "fingd" did not fall prey to Morris' internet
worm, even though it works fine as a "fingd". My point is that worms and
viruses usually depend on a lot of things being exactly a certain way.
Good network programs, on the other hand, can only assume the bare minimum
protocols defined in the RFCs. There may be some escape hatch like Berkeley
sendmail's "debug" option, but only ONE "genotype" of sendmail program fell
prey to that attack.


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

Date:    Sat, 14 Apr 90 05:11:28 -0700
From:    [e-mail]
Subject: WDEF A on Chessmaster 2100 and Cribgin (Mac)

VIRUS-L V3 #72 (9 Apr) contained an unconfirmed report that Chessmaster
2100 (Macintosh version) from the Software Toolworks was infected with
WDEF A.  The Toolworks was looking into it.

I contacted them Tuesday, and they have confirmed that WDEF A was on
their master disks for both Chessmaster 2100 and another game program
called Cribgin, both for the Mac.  They have started a recall on both
products, and expect to be able to ship replacements starting this Friday.

          Jim Gillogly
          [e-mail]

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

Date:    15 Apr 90 15:32:57 +0000
From:    [e-mail] (Robert J Woodhead)
Subject: Re: Loophole in VIREX 2.6? (Mac)

[e-mail] writes:

>   I wonder if this is a problem with VIREX or an anomaly in QuickBasic?
>It could be the case that, in the future, any trojan which emulates the
>structure of a QB object will be passed over by VIREX, creating a loophole
>similar to the one created by checking the "Always Compile MPW INITs" box
>in Vaccine.

No.  The problem was that, not having another example of a QuickBasic
program handy, the signature used in 2.51 unfortunately matched every
QB program.  This was an easy fix.

Thanks for the concern though.

- --
Robert J Woodhead, Biar Games, Inc.   !uunet!biar!trebor | [e-mail]
Announcing TEMPORAL EXPRESS.  For only $999,999.95 (per page), your message
will be carefully stored, then sent back in time as soon as technologically
possible.  TEMEX - when it absolutely, postively has to be there yesterday!

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

Date:    16 Apr 90 08:41:55 +0000
From:    inesc![e-mail] (Julio Raposo)
Subject: Jerusalem-B Virus (PC)

          I have made last year a program to clean the Jerusalem-B virus from
  the infected files without damaging them. I've done this because at the
  time the only other method I had was just deleting the files and restoring
  them from the backups. A few days after I got my hands on John McAfee's
  programs (Oh dear, I haven't got his name anywhere near by, please forgive
  me if I misspelled it) and decided I would go on working on my own
  program, VKILL. The version 1.0 is available from SIMTEL among other
  places, both C-source and compiled program with the Turbo-C init and
  project files.

          The reasons why I say that for me my program is better than SCAN and
  CLEAN are:

          Here the infections are mainly by Jerusalem-B virus (I don't know
                    why). After using VKILL, most of the disks are reported
                    clean by SCAN.

          VKILL is very fast because it looks for the only place in the file
                    the virus usually is. It only fails if other trash has been
                    appended to the file after it has been infected.


          Now I am working on the new version of VKILL. This new version is
  able not only of cleaning the virus but can also make all the files immune
  to new attacks. The next release will be 1.2, 1.1 being the Beta test
  version. When this new version is ready I'll send it to Keith Petersen
  (SIMTEL) and to Bill Davidsen (comp.binaries.ibm.pc postings).

          Meanwhile if someone wants more information about Jerusalem-B or the
  VKILL program, or has found any bug or inconvenience in the use of VKILL,
  please e-mail to me.

- -------
                                        Antonio Julio Raposo
                              ([e-mail] - LISBOA - PORTUGAL)

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

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