From:	MERC::"uunet!ARISIA.dnet.ge.com!CRDGW2::CRDGW2::MRGATE::SMTP::CRVAX.SRI.COM::RELAY-INFO-VAX" 14-APR-1992 13:46:00.56
To:	galaxy::GleEve
CC:	
Subj:	VMS viruses

From:	RELAY-INFO-VAX@CRVAX.SRI.COM@SMTP@CRDGW2
To:	Everhart@Arisia@MRGATE

Received:  by crdgw1.ge.com (5.57/GE 1.137)
	 id AA07900; Tue, 14 Apr 92 11:08:01 EDT
Received: From RELAY1.UU.NET by CRVAX.SRI.COM with TCP; Tue, 14 APR 92 07:47:52 PDT
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA26112; Tue, 14 Apr 92 10:47:28 -0400
Message-Id: <9204141447.AA26112@relay1.UU.NET>
Received: from raxco.UUCP by uunet.uu.net with UUCP/RMAIL
	(queueing-rmail) id 104640.22924; Tue, 14 Apr 1992 10:46:40 EDT
Date: Tue, 14 Apr 92 10:19:20 -0400
From: raxco!galaxy.dnet!gleeve@uunet.UU.NET
To: "info-vax@crvax.sri.com"@uunet.UU.NET
Subject: VMS viruses

I've never heard of a real VMS virus. Neither (from private conversations)
have Ray Kaplan or Joe Bingham. There have been some instances of
covert behavior, and some network worms, however.
   The advice to avoid "foreign" programs is however wrong-headed
in the extreme. I've heard of at least 3 cases of covert behavior
in commercial programs, though I don't have names and dates (more's
the pity; I'd be delighted to publish same if I had harder evidence.)
   Avoiding covert behavior is best accomplished by KNOWING YOUR
SOURCES and using sources that are widely used; you benefit by
a mutual "watching your back" that occurs.
   New images you get from "somewhere" can to a degree be tried
in a test environment, without real privs (or on an isolated machine
you don't mind rebuilding perhaps). A powerful set of techniques involves
using SET WATCH to watch RMS accesses an "untrusted" image tries, and
using FTS or the like to watch system services it tries. An addon
which I did for FTS (now as a conditional assembly in JASMON) lets
it pretend that calls to $SETPRV always return success and tell
the image it has all privs. This can be helpful, as can setting the
date well in the future during the test. It would be nice if FTS
were modified to catch $GETJPI when it is asked for the priv mask
so that it could tell the image it had all privs that way also, and
if it could be modified to return a set date to the image via any
of the 3 or so methods vms has, without having to mess with the
system date. This would allow a more complete test. Such tests
are not bullet proof; someone could for example use the S0 calls
which can't be monitored. This however is far more work than normal,
and could perhaps be caught by judicious use of something like 
DISM32 or even the debugger to search for references to S0 space.
   In general for covert behavior to do damage it's got to get to
the file system or system services...what else is there outside its'
address space?... so the combo of monitoring both, particularly
if you can falsely convince the image it's running from a highly
priv'd account, should be a most effective testing technique.
   I suspect that the lower incidence of viruses in VMS arises
from the less-anonymous character of software sharing in this
community and from the general provisions of VMS to make it
more difficult to add bits of code to a system. By the time
one learns to do such, he's usually thought of more interesting
and useful things to do with that skill. They are certainly
possible to build. Then too, PC viruses have been found to
propagate mainly with shared disks and computers, not so much
over BBSs (due to the shared-watching effect perhaps). Anonymous
access to VMS is much rarer than anonymous PC use, and generally
much more closely watched where it does exist. How many are
foolish enough to insert a virus into a system from their
own personal accounts? 
   Trojan horse programs and the like do exist, though, so
such testing techniques as I've mentioned are useful. Now
does anyone have a way to run VMSINSTAL from a nonpriv'd environment
so that one can tell what it will do? One case I heard about
involved someone who'd made a vmsinstal kit which among other
things generated the command "delete sys$system:*.*;*" and
executed it. Fortunately its' victim had recent full backups.
I personally believe the absence of such a facility is the biggest
single security hole in VMS.
Glenn Everhart
Everhart@Raxco.com