From: rpowers@panix.com (Richard Powers)
Subject: Re: Beneficial Virus?
Organization: PANIX Public Access Unix, NYC
Date: Wed, 6 Jan 1993 23:51:43 GMT

In <1993Jan6.152243.22472@nastar.uucp> phardie@nastar.uucp (Pete Hardie) writes:
>In article <C0EJAu.HuI@panix.com> rpowers@panix.com (Richard Powers) writes:
>>In <1993Jan5.153018.18935@nastar.uucp> phardie@nastar.uucp (Pete Hardie) writes:

>Consider a multi-user system where another user installed the virus, and I
>want to transfer a file to my home system, and need to transfer the marker
>file, but I do not know which file it is.

A multi-user system can be treated exactly like several single-user
systems.  If you want to transfer a file (or make available to other
users) to another user on the same _or_ to a different system you can:

(1) remove the virus first
	or
(2) also transfer (make available) the permission file.

If you're talking about a multi-user system where a super-user has
installed the virus (ie: the virus has permission to spread to _any_
users files), then I would certainly hope that the super-user would
have informed all other users that this is the case.  I don't think it
would be ethical otherwise, since the person would be changing people's
files without consent.

>>The files are not changed by being without the marker!!  The only
>>thing which is changed is that the virus will no longer spread itself.
>>The compressed file _still_ has the virus prepended.  Thus it will
>>_still_ be able to decompress the file upon execution.  It will then:
>>[commit hari-kari/notify the user/do nothing] (discussed elsewhere).

>This is noted.  See below.

>>>Still, the question arises - suppose I decide I don't want those
>>>files stored compressed any more.  How would I get rid of the virus?

>>Simple.  You remove the marker.  That is what the marker is for! 

>But the virus still remains embedded in the compressed files.  Unless the
>virus code is remove on decompression, and re-inserted on write-to-disk, it
>remains in the file, albeit dormant.

I wouldn't do it that way.  It would take too much CPU time.

>Sure, no more files are infected once
>I delete the marker file (assuming I know which file it is), but suppose I
>want/need to transfer a file to another system that is required to be virus-
>free?  How to I get an uninfected copy of my file?

This really was discussed already.  Upon failing to find the marker
file (which may contain some of the code the virus uses to
compress/spread), it could do several things:

(1) Remove itself.  The BCV would decompress the file and then save it
back to disk in its original state.  Uncompressed and w/out virus
code.

(2) Decompress as usual.  It would get the file running as usual, and
then just quit.  Letting the host file continue.  *** I _don't_ think
this is the way it should be implemented. ***

(3) Notify the user.  Tell the user it exists.  This could (should) be
combined with other methods.

(4) Create a marker file.  Give itself permission to spread.  *** I do
_not_ think this should be implemented by itself.  It defeats the
pupose of the marker file.  ***

(5) Ask the user.  Give the user a menu of choices for what it should
do.  This is the only context I see (4) being appropriate.  (3) is, of
course, not applicable.   ***  I prefer this method over all.  If (1)
were implemented and the marker file was lost w/out my knowledge, I
wouldn't want my files to mysteriously decompress. ***


Now, I also mentioned having a list in the permission file of files
the BCV was not allowed to infect.  You could just add the name of the
file you wanted to transfer to this list and the BCV would use method
(1) above.


I would probably also have one or more BCV maintenance tools.  To
check up on how it is performing, to create/update/change the
permission file, and to remove the BCV from specific files.


-- 
 Richard Powers    / Disclaimer: My keyboard is \   Computer=Amiga
rpowers@panix.com <  screwy.   Missing  letters  >  Music=Industrial
   Hail Eris!      \ should     be    expected. /   Food=Vegetarian
Newsgroups: comp.org.eff.talk