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

Text File | 1995-01-03 | 25KB | 541 lines

VIRUS-L Digest   Wednesday, 14 Feb 1990    Volume 3 : Issue 42

Today's Topics:

WDEF at Naval PG School (Mac)
"Expert System" virus scanner
Forwarded: Re: *UNCONFIRMED* PC virus
Re: The AIDS "Trojan" is a Copy Protection System
Retraction of previous statement (Mac)
Strange Beep... (Mac)
AIDS -program? AND Class Action Suit
Can DOS Extensions (indirectly) help fight viruses? (PC)
Re: Jerusalem-B (PC)
Re: Checksums
Re: Identification strings
How to notify campus community members about viruses
The AIDS Trojan as Copy Protection Scheme
The ethics of virus eradication

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

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

Date:    13 Feb 90 20:27:20 +0000
From:    [e-mail] (Jeff Kulp x2174)
Subject: WDEF at Naval PG School (Mac)

        WDEF A was found on one Mac in a restricted use Mac Lab.  The
virus was removed using Disinfectant 1.5.

Jeff Kulp
[e-mail]

[Ed. Due to the sheer volume of WDEF infection reports...  Someone
recently asked for all WDEF infection reports to be sent to the list;
could that person please identify him/herself to me, and I'll start
forwarding these reports directly to him/her?  Thanks.]

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

Date:    13 Feb 90 22:26:20 +0000
From:    [e-mail] (Russell McFatter)
Subject: "Expert System" virus scanner

[e-mail] (GEORGE SVETLICHNY) writes:
>Now there just _*MAY*_ (note the triple enphasis) be a theorem of the
>following type:
>
>        I. Given such-and-such memory and microprocessor architecture,
>        then any program containing a virus (however that is defined)
>        will necessarily have a certain patern P in the object code.
>        II. Any program that does not contain a virus can be written in
>        a way that does not lead to pattern P in the object code.

I was going to suggest this type of approach myself; if "pattern" is very
loosely defined, as is "virus".  I put forward this simple hypothesis:

        An algorithm (A) exists which can positively determine that a
        given set of programs (Pg) do NOT exhibit harmful behavior.

"harmful behavior" can be defined however we want; self-reproduction,
direct access to hardware, modification of other executables, and so on.

Trivial proof: We can enumerate the set Pg and write an algorithm to
identify a program as "good" if it is included in the set.

This is not ENTIRELY impractical (a program which compares the
executables on a disk to the "original" would fall in this class).
This isn't very useful for most situations.  We need to be able to add
a statement like part II of George's theorem.

        Any program which is NOT harmful can be written in such a way as
        to satisfy algorithm A.

This would be very difficult to prove.  In reality, though:

1:  We are not restricted to a single virus-checking algorithm; we can use a
    number of them (A1 ... An), each of which can "clear" a subset of the
    programs we wish to test.  We may need to know which virus "disprover"
    algorithm applies to each given test subject  ("You can check UltraGame
    PD 1.4 for virus-safety using 'class 5' checking methods").

2:  The set of "harmless" programs is not as clearly defined as we'd like;
    some programs that we'd ordinarily call "harmful" will be, in fact,
    exceptions to the rules.

3:  We'd settle for a set of virus-disproving algorithms that works on MOST
    software, if we have other means to insure the integrity of the
    "exceptions" we need to install.

4:  The usefulness of the virus-disprover varies with the percentage of
    real-world programs that it can successfully clear.

5:  Measures have to be taken to make sure that the virus-disprover's
    environment is "clean".

6:  A set of "safe" system calls could be used to decrease the number of
    "exception" programs. A pair of calls that create/delete temporary
    files, for example, could be considered "safe" by a virus scanner, as could
    most routines which perform "dangerous" acts after prompting the user.
    (PromptDelete, for example, might pop up a dialog box with a message such
    as:  "Ok to delete <filename>?" before deleting the file.  This would be
    considered "safe" by the virus-disprover, unlike the call that deletes
    without prompting.)

We can submit, to the software authors of the world, a set of rules that
they must follow if we are to accept their products (hey, if the world
can stem the copy-protection wars simply by refusing to purchase
any software with copy protection, we can do the same for virus-testability).
These can include all the difficult-to-test issues that have been
mentioned here so far, such as:

        1:  No self-modifying code or execution of data.
        2:  No direct access to hardware-- use approved system calls only.
        3:  No modification of executable files.
        4:  No transformations of "data" files into executables or writing
            executable files (loaders/compilers would fail here).
        5:  Substantial restrictions on calculated (register) jumps
            (designed to accommodate most high-level constructs, but not
            much else).

To some extent, these rules overlap simple good programming practice.
Self- modifying code is hard to debug, direct hardware access is
nonportable, computed jumps are "risky"; the others are generally
"antisocial".

When you think about it, you'll realize that we sometimes DO go this
far to protect ourselves against viruses-- this is exactly what
happens when you review source code before compiling and executing it.
The fact that you're getting (high-level) source code means that the
author has obeyed some rules, making the program easy to understand
(so that you'll trust it), and not writing any "suspicious" or
"dangerous" code. If YOU can "virus-check" a program, it seems
reasonable that a computer could do some of the same, not only faster,
but more reliably.

- --- Russell McFatter  [[e-mail]]
std. disclaimer applies.

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

Date:    Tue, 13 Feb 90 15:18:34 -0800
From:    [e-mail] (Rollo D. Rogers)
Subject: Forwarded: Re: *UNCONFIRMED* PC virus

hi, does anyone else have knowledge/experience with this alleged PC
virus?

[Ed. As with all such reports, I urge people to NOT BELIEVE this
without some reliable third party confirmation.  We've all seen that
rumors can be just as time consuming as The Real Thing...]

Forwarded mail follows:
Date: Tue, 13 Feb 90 14:52:02 -0800
From: Yong Kim <[e-mail]>
Subject: Re: virus

I went to a local computer store and one of the salesmen complained
about the new kind of virus.  He said that unlike the conventional
ones (residing in the first track or other part of command.com, etc)
this one lives in the setup-memory (CMOS) that was backed up by the
computer battery.  All the infected disketts can be reformated and can
be purified, but this one lives there until human disconnects the
battery from the unit and restart the machine.  The story seems quite
plausible and that's why I decided to hear from experts' opinion on
the net.  Since today's AT usually uses CMOS memory, this looks a
serious problem.  The story went further: once the scan program is
loaded, the virus in there can recognize his eternal enemy (wel I
might be exaggerating, or making a fairly tale..) and destroy it.
Sounds like a SIFI fiction, but it looks like possible.  I wish we had
some kind of ANSI anti-virus detection scheme:-)

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

Date:    Tue, 13 Feb 90 18:35:00 -0500
From:    [e-mail]
Subject: Re: The AIDS "Trojan" is a Copy Protection System

munnari!mqccsunc.mqcc.mq.oz.au![e-mail] (Ian Farquhar) writes:

>This is not a trojan: it is a COPY PROTECTION SYSTEM.  The
>consequences of using the program without paying are quite adequately
>laid out in the license, which apparently has not been read.

>If the author of this program is convicted, it will be the first
>conviction ever for the hidious crime of writing a copy protection
>system, and will be one of the biggest farces of justice ever
>witnessed.

Well, no.

1. It is unacceptable and actionable that a copy protection system
   delete unrelated material.

2. Why did the "copy protection system" count down from a random
   number before "protecting" things?

3. Unsolicited material received in the mail is the property of the
   recipient, the presence or absence of a licence being immaterial.
   (Or, to be more precise, that is law in this country.)

4. Why did the perpetrators attempt, beforehand, to hide their
   tracks? And why didn't they come forward immediately? A judge
   will interpret this as a clear demonstration of intent.

Don             D.C.Lindsay     Carnegie Mellon Computer Science

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

Date:    Tue, 13 Feb 90 18:18:00 -0500
From:    Peter W. Day <[e-mail]>
Subject: Retraction of previous statement (Mac)

Dave Platt is correct and I am wrong about the accessibility of the
desktop file on an AppleShare server, and I appreciate his clarifying
the situation.  When I tried it previously, I had neglected to login
to my server with adequate privileges.

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

Date:    Tue, 13 Feb 90 18:12:08 +1100
From:    "Alejandro Kurczyn S." <[e-mail]>
Subject: Strange Beep... (Mac)

  We have a strange problem here, working on a Macintosh II, sometimes
it beeps when a file is open or closed and sometimes during starup. I
read some time ago that a WDEF (or nVir) sounds the bell when present.
So, I tested the hard disk (20 M) with disinfectant 1.6 and it didn't
show anything. I also re-created the DeskTop file, but the same
problem persist. My questions are:

  Is this a virus?   how can I get rid of it?
  Is a know virus?

Please mail me directly, Thanks in advance.

- -Alejandro J. Kurczyn S.
ITESM CEM
Mexico

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

Date:    Tue, 13 Feb 90 20:09:06 -0500
From:    woodb!scsmo1![e-mail]
Subject: AIDS -program? AND Class Action Suit

First of all can someone answer this question with a yes or no for
me...  Did the AIDS disk come with an AIDS program??

AND

Is there anyway that a class action suit could be made for those who
suffered damages against a convicted virus writer.  Ie, could those
hit by the famous WORM now sue for damages??

- --
 DON INGLI-United States Department of Agriculture - Soil Conservation Service
 INTERNET: scsmo1![e-mail]    PHONEnet: 314!875!5344
 UUCP(short): uunet!scsmo1!don        UUCP(long): uunet!mimsy!woodb!scsmo1!don
              These are my opinions. I represent myself.
   Who do you think you are, Bjorn Nitmo?  David Letterman '90 Catch Phrase

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

Date:    Tue, 13 Feb 90 23:10:52 -0600
From:    [e-mail] (Tim Williams)
Subject: Can DOS Extensions (indirectly) help fight viruses? (PC)

I was wondering if running a DOS extension, like 4DOS, which totally
replaces COMMAND.COM, would provide any measure of protection against
a virus attack.  I know that it would not provide any help directly
(as a feature, I mean), but might subtle changes in the OS throw off
some viruses?

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

Date:    Wed, 14 Feb 90 14:05:07 +0200
From:    Y. Radai <[e-mail]>
Subject: Re: Jerusalem-B (PC)

  Michael Greve writes:
>  I want to thank all the people who sent me messages on using the
>CLEAN program.  Unfortunately the program did not work.  It removed
>the virus and shrank the .exe file from 260,000+ bytes to 84,000.
>Needless to say this file didn't run.  Does anybody have any other
>ways of getting rid of this virus.  Is the Jerusalem virus a
>particularly difficult virus to get rid of???

  Ordinarily, the Jerusalem virus is easy to get rid of using any of
the common anti-virus programs (CLEANUP, UNVIRUS, F-FCHK, VB, etc.).
  However, a few EXE files contain a file-length in their header which
is less than their actual length.  If such a file is infected by the
Jerusalem virus, it overwrites part of the file instead of extending
it.  In that case, it's obvious that no program can restore the file.

  There's seems to be some misunderstanding on this subject.  For
example, Brad Fisher writes:
>                                              The only problem is that
>this paticular flavor of virus can not always be removed without some
>damage to the original file ... but a least it can be removed!

This is misleading; it sounds as if the disinfecting program does the
damage.  If the virus hasn't overwritten the file, I don't think any
of the above programs ever damage the file.  And if it has overwritten
it, then the truncation performed by the program doesn't matter.

                                     Y. Radai
                                     Hebrew Univ. of Jerusalem, Israel
                                     [e-mail]

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

Date:    Wed, 14 Feb 90 13:51:12 +0200
From:    Y. Radai <[e-mail]>
Subject: Re: Checksums

  IA88000 asks:
>If you had your choice, which checksum routine would you consider most
>secure, and why. ....
>To make the question a little more specific, of the checksum routines
>available today, which would you select.

  It's strange that Mr. IA88000 makes no reference to the discussion
which has been taking place so far on this forum.  We've been talking
of checksum *algorithms* and checksum *programs*, and I'm not sure
which he's referring to when he writes "routine".  And if he means a
*program*, then for what computer.  Since I have already answered the
question in the case of algorithms, I'm going to assume here that he's
asking which *PC* checksum *program* available today do we consider
best or most secure.

  Among those that I've seen, the one which is certainly the most se-
cure, and probably best all around, is V-Analyst (name changed from
VirAlarm to avoid conflict with another product of the same name).  I
know the authors, Omri Mann and Yuval Rakavy, but that in no way in-
fluences my evaluation.
  It's a commercial product, costing $79.  It implements Prof. Rabin's
CRC algorithm in which the generator is chosen at random from among
all 31st-degree irreducible polynomials when each user initially sets
up his checksum base.  It is activated either on demand or by virtue
of the command being placed in AUTOEXEC.BAT (which does not necessari-
ly mean that it must be activated on *every* boot), and does not re-
main resident.  The user is given complete control over selection of
the files which are to be checksummed (e.g. one can choose to checksum
a small set of files on every boot and all files on the disk every two
weeks) and both the initial selection and subsequent updating can be
performed very conveniently, by wildcard notation and/or by "pointing-
and-shooting".

  Most important, great care has been taken to prevent virus writers
from circumventing the checksumming.  This is the only program I've
seen which blocks every loophole in DOS that I know of, provided check-
summing is performed only when memory is uninfected (i.e. immediately
after booting from a clean diskette).
  In May 88 this program was the subject of a $6000 bet on Israeli
television.  A software house threw 10 specially-written test viruses
at it, and none succeeded in going undetected.  (Although the attack-
ers lost the bet, so did the defenders.  Apparently, the judges deci-
ded that in order to win, the latter would have to prove that their
program could detect *all possible* viruses!)

  Checksumming a given file takes about 3 times as long as performing
a COPY of that file to NUL.  (This is on an XT; the factor is probably
smaller than 3 on a faster machine.)  The checksum feature of FSP is
somewhat faster than this (it uses a simpler algorithm than CRC), and
Sentry is much faster (since it checksums only the beginnings of
files) and therefore will be preferred by some users.  But both Sentry
and FSP are potentially insecure.  Also (as I mentioned previously),
checksumming in FSP is extremely tedious (apparently the commercial
version FSPP is less so), and Sentry suffers from a lack of flexibi-
lity, particularly when it becomes necessary to update the checksum
base.

                                     Y. Radai
                                     Hebrew Univ. of Jerusalem, Israel
                                     [e-mail]

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

Date:    Wed, 14 Feb 90 14:18:37 +0200
From:    Y. Radai <[e-mail]>
Subject: Re: Identification strings

Fridrik Skulason:
>         Identification string: A sequence of bytes, used by anti-virus
>         programs to check if a program is infected.
>         Signature string: A sequence of bytes, used by the virus to check
>         if a program is infected.

David Chess:
>Well, by an unhappy coincidence, we tend to use the terms more or less
>the other way around, around here.  We call the thing that a virus
>checks for the "self-identification", and we call the things that our
>scanner scans for "signatures".

  Since the term "signature" already has too many meanings (checksum,
for example), I suggest as a compromise that we drop it entirely and
use the terms "scan-id" and "self-id" instead, i.e.:

Scan-id = a string (or set of strings) used by an anti-virus identifi-
          cation program to check if a program is infected by a known
          virus;
Self-id = a string or pattern used by a virus to detect if a program
          is already infected by it (or perhaps by some related virus).

                                     Y. Radai
                                     Hebrew Univ. of Jerusalem, Israel
                                     [e-mail]

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

Date:    Wed, 14 Feb 90 08:43:45 -0500
From:    [e-mail] (Eloise Kleban)
Subject: How to notify campus community members about viruses

Getting the word out to faculty, students and staff is a major problem
that computer center consultants face.  If you don't publicize the
problem, you may be liable in some sense for damage that occurs.  On
the other hand, you must avoid accusing individuals or groups.  For
example, most of the virus infections I see are on faculty machines,
and one major reason is the sharing of computer software that goes on
among them.  (There are other people on campus who deal more with
students - I'm not implying that the students don't spread viruses
also!)  This is an issue that must be handled diplomatically.

I publish articles in our newsletter, I make sure that the other
consultants in the University system have the same info I have and the
software tools, and every time I talk to a user about micro software,
I mention the problem of viruses.  However, we are very careful not to
point any fingers.

Eloise Kleban                     BITNET:   ELOISE@MAINE
Computing Center                  INTERNET: [e-mail]
University of Maine

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

Date:    Wed, 14 Feb 90 09:28:00 -0500
From:    Jim Shanesy <[e-mail]>
Subject: The AIDS Trojan as Copy Protection Scheme

When the AIDS trojan alerts first appeared I faxed them to a dear
friend of mine, Mr. Paul R. Paletti, Jr., Esq. of Siler and Handmaker
in Louisville, Ky.  Paul is a licensed, practicing attorney at law.
He gave me his informal opinion over the phone as to the significant
facts in the case, to wit:

1) The disk was unsolicited and was sent through the mail.  The
recipient therefore owns the disk outright and the sender is
automatically waiving any rights to ownership.  The whole concept of
"copy protection" goes right into the dumpster at this point.  Paul
was very emphatic in pointing out that there is no defense on this
point. He said this is the most significant legal fact in the case.

2) The software on the disk sabotages another's personal property,
with an accompanying demand for money.  This is blatant extortion.  No
matter how profuse and explanatory any printed disclaimers may be, the
intent is clear.  The author is attempting to profit by placing
another individual under duress.

That boy's in a heap o' trouble.

Jim Shanesy <[e-mail]>
Office of Computer and Information Technology
National Research Council
2101 Constitution Ave., NW
Washington, DC  20418

[Ed. Is this the case under British law as well as U.S. law?  If he
did this in Britain, did he break any U.S. laws?  Will Dr.  Popp be
tried here or in Britain?  Just a few thoughts...]

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

Date:    Wed, 14 Feb 90 10:22:39 -0500
From:    Kevin_Haney@NIHDCRT
Subject: The ethics of virus eradication

With regard to Alan Federman's questions concerning the ethics of
virus eradication, it has unfortunately become the prevailing tendency
in many quarters, especially the business world, to deny and try to
cover up incidences of viral infection.  However, the situation boils
down to this: A computer professional does not (usually) take any sort
of oath of confidentiality.  His primary responsibility is to the user
community as a whole, not to any single individual.  That does not
mean, however, that reports of viral attacks should be distributed
indiscriminately.  As a professional, you have a responsibility to
balance the feelings of the 'infectee' and the dangers of unnecessary
hype against the danger of the possible spread of the virus and the
potential damage it may cause to other people in the community.

I don't know the particular circumstances of Federman's situation, but
it sounds like he did exactly what should have been done.  If there is
a good probability that telling people about a particular virus might
prevent them from getting it, then that should outweigh the potential
embarrassment that a single person might suffer (especially since
Federman did not reveal the particular name of the person involved).
If someone were to contract the virus later and learned that you had
known about it but did not warn anyone, the professional and political
repercussions would most likely be greater than the scoldings of one
irate faculty member (many of whom have a tendency to become irate
with little provocation).

To again revert to the medical analogy (which is admittedly
imperfect), what if a physician who treats a very contagious disease
refused to report it to the National Center for Disease Control and,
as a result, the disease spread further.  That would amount to an
abdication of responsibility on the part of the physician tantamount
to malpractice.  The only situation where withholding the information
would be permissible would be when, for some reason or other, there
was little chance that the disease (or virus) would spread any
further.  Since there were a number of people on Federnam's campus
studying fractals, there was a good possibility that someone else
might have purchased or come across the infected program and thereby
spread the virus further.  So, while we all have to deal with
unreasonable people occasionally, I do not think Federman's actions
lacked any professional or ethical justification.

    _______________________________________________________
   |                                                       |
   |   Kevin Haney, Computer Specialist                    |
   |   Division of Computer Research and Technology        |
   |   National Institutes of Health                       |
   |   BITNET - Kevin Haney:dcrt:nih                       |
   |_______________________________________________________|

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

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