NetNews Usenet Archive 1993 #1/NN_1993_1.iso/spool/comp/org/eff/talk/8577

Text File | 1993-01-11 | 6.3 KB | 135 lines

Newsgroups: comp.org.eff.talk
Path: sparky!uunet!wupost!emory!nastar!phardie
From: [e-mail] (Pete Hardie)
Subject: Re: Beneficial Virus?
Message-ID: <[e-mail]>
Organization: Digital Transmission Systems, Duluth, GA.
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Mon, 11 Jan 1993 16:37:20 GMT
Lines: 124

In article <[e-mail]> [e-mail] (Richard Powers) writes:
>Ok, I should have been a little clearer on this.  _Someone_ had to
>introduce the BCV to the multi-user system.  I am assuming that the
>user that does this only has write permissions for files s/he owns.
>The BCV will, of course, have the same privileges(sp?) as the owning
>user.  If this user wants to transfer an executable file to another
>user (or make it available to other users), then s/he should take the
>exact same precautions as would an owner of a single-user system who
>is transferring a file to a separate system without the BCV.
>
>Is it clear how (IMO) a multi-user system does not have to be taken
>into account as a separate case?

I'm afraid not.  Using a UNIX system as an example, not every user keeps
his/her files protected from other users.  Yes, this is poor security, but
there is little that can be done to change this facet of human nature
without ticking people off.

I agree that there is not *necessarily* a problem with the BCV on a multi-
user system, but there easily *can* be a problem with it.

>You imply that a sysadmin would place a BCV on his system without
>informing his users.  Either there is no reason for him/her to inform
>his/her users, in which case; fine, no reason to worry.  Or else there
>is a reason for the sysadmin to inform her/his users.  In that case
>s/he should do so.  If the sysadmin fails to do so, it is the fault of
>the sysadmin, not something inherent in the BCV.

I am stating that the BCV can be present in the system and operating on
a given user's files w/o that user's knowledge, whether the BCV was installed
by the admin or another user.  And that is what I see causing problems.

>(IMO this should not happen.  But anyway...)  Either one of two things
>will occur.  (1) You never notice it is on the system.  It works fine,
>and you never had a reason to edit an executable, etc.  In this case,
>whats the difference?  (2) _Something_ that you didn't expect happens.
>You noticed _some_ type of effect of the presence of the BCV.  Here
>you ask a question of the sysadmin, and s/he says "Oh yeah.  Forgot to
>tell you about that.  Heres how it works...".

Certainly, if the sysadmin was the installer.  But if Mary User was
the installer, and Joe Public gets his files compressed, and can't uncompress
them, or is concerned when the "Warning:  VIRUSOK.MK not found.  Install?"
message appears on his home machine when a copied executable is run, how
does the info get to Joe?

>You can't have it both ways!  If it *IS* *totally* transparent, (AS
>TRANSPARENT AS A DEVICE DRIVER), then there is no reason for the users
>to know of its existence.  If there _are_, on the other hand, things
>the user should be aware of, then the sysadmin should make the user
>aware!

Yes, *should*;  not *WILL*.

Since the BCV only takes effect on execution, I can copy a file that is
compressed to another machine.  A device driver would uncompress during
the copy off the hard drive, and not on the write to floppy (or perhaps it
would re-compress....)

Again, if we are talking about use on one system, the BCV is not a problem
for the installer, and almost never a problem for anyone else.  Once we are
discussing 2+ machines, it *can become* a problem for the other users, since
they suddenly find a section of code *that they did not write* residing in
their executables, and asking them questions about a file *they may know
nothing about*.

>>How will I know, if I arrive after the installation
>>of the BCV, that it is in place?
>
>See above.

I'm not clear on this.  If the marker file is present, and I do not have
any executables from before, how do I know?

>>If the marker file is gone, the re-compression code is gone, right?  Every
>>executable will be decompressed over time, leading to this very state.
>
>No, wait a minute.  This would happen if method (1), and only method
>(1), was used when the BCV could not find the marker file.  That is
>why I argued against your "...only ethical option.." statement.

>_If_ the compression code is only in the marker file, and _if_ you no
>longer have a backup or any other way of restoring the marker file,
>then, yes your files will decompress if you told them to.  (I
>advocated that the BCV ask the user what to do when the marker is not
>found.  The user in this case would _not_ tell _every_ BCV-bearing
>file to decompress until more/another storage media is found.)

Ok, I'll buy that.

>>No.  I meant that Joe User could install the virus and marker file on the
>>multi-user system run by Mary Sysadmin.
>
>But so what if he did?  If Joe User can write to anything other than
>his own files, then Mary Sysadmin has more problems than someone
>trying to compress executable files!  If he can't, then what is the
>problem?

You are assuming that every user can (and should) have all his/her files
locked up tighter than a drum, on a multi-user system.  The first is possible,
but the second is debatable.

>>That's the problem with a beneficial virus - we don't all agree that
>>X action is always beneficial.
>
>Aaaaargh!  It is irrelevant!  The only characteristic which a virus
>exhibits that makes it different from other programs is
>self-replication.  If everything else is equal, why should this factor
>make the program suddenly evil?

You miss my point.  That the BCV is a virus (or could be one), is not the
issue - the issue is "Is it *beneficial*?"  Since it is a virus, is will
infect other files (and systems) without the owner's knowledge, and they
may not agree that the compression is a benefit.  They might consider it
a harmful act.

It is the assumption that you (or the virus writer) know better than I what
is beneficial to my system/files that is the problem.

--
Pete Hardie:  phardie@nastar  (voice) [phone]
Digital Transmission Systems, Inc., Duluth GA
Member, DTS Dart Team           |  cat * | egrep -v "signature virus|infection"
Position:  Goalie               |