Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!wasatch!utah-gr!uplherc!sp7040!obie!wsccs!terry
From: terry@wsccs.UUCP (Every system needs one)
Newsgroups: comp.sys.amiga
Subject: Re: The ultimate fix!!!
Summary: Genetic Engineering
Message-ID: <729@wsccs.UUCP>
Date: 12 Oct 88 03:12:10 GMT
References: <681@zehntel.UUCP> <3084@hermes.ai.mit.edu> <4197@thorin.cs.unc <9680@cup.portal.com>
Lines: 51

In article <9680@cup.portal.com>, dan-hankins@cup.portal.com writes:
> In article <2720@sugar.uu.net>, peter@sugar.uu.net (Peter da Silva) writes:
> 
> >I think you need to add "and has the ability to infect other systems it
> >comes in contact with".
> 
> I thought I had implied that;  I didn't specify that the replication was
> limited to a single system.  I said, "replicates by usurping the function
> of the host's code".  I should think this would include inter-system
> replication.
> 
> >(2) It's harder for a virus to infect UNIX, also, because it's unlikely that
> >68020 code from a sun would do much to a Microvax or even a 68010 machine
> >like a 3b1. A binary standard is a two-edged sword.

ken or dmr wrote one for UNIX way back when.  It was part of the portable C
compiler.  It recognized login.c and altered it to accept an alternate
password at compilation time.  It was especially clever, since it also
recognized the C compiler source and fixed it to fix the C compiler source
and login, so even if you fixed it, it fixed itself back.

> This provides no impedance whatsoever to a virus.  An executable-program
> virus is one that attaches itself to programs in the user's account.  The
> user then does the virus' work for it whenever he sends an executable
> program to someone else.  Why would the user send a 68020 executable to a
> person with a 68000 machine?  He wouldn't.  The virus is assured of being
> copied to environments where it will execute with no problems.

It would be relatively simple to provide a virus which crawled through the
net an replaced /bin/login by going through 2 or 3 holes in pre-5.3 uucp
(raising any hackles, anyone?).  This can be gotten around by protecting
any of the 3 holes, the easiest of which is to mount the /usr/mail
directory someplace other than the same volume as /etc.  The other two
involve breaking uucp for either calling in, out, or mail delivery.  One
other way would be to remove the C compiler entirely 8-(.

> Plus, there are interpreted languages that are at least somewhat
> system-independent.  Shell scripts and Rexx programs are as good if not
> better vectors for a virus than raw executables.

What good is a virus people can read? (for that matter, what good is a
virus, other than as an example of how to keep code running across a warm
boot?).


| Terry Lambert           UUCP: ...{ decvax, ihnp4 } ...utah-cs!century!terry |
| @ Century Software        OR: ...utah-cs!uplherc!sp7040!obie!wsccs!terry    |
| SLC, Utah                                                                   |
|                   These opinions are not my companies, but if you find them |
|                   useful, send a $20.00 donation to Brisbane Australia...   |
|                   'I have an eight user poetic liscence' - me               |