From:	MERC::"uunet!CRVAX.SRI.COM!RELAY-INFO-VAX" 17-NOV-1992 01:45:30.03
To:	INFO-VAX@SRI.COM
CC:	welchb@woods.ulowell.edu
Subj:	Re: Failures in system security.

Brendan Welch, welchb@woods.ulowell.edu, writes:

>        Does anyone have a program which monitors the phone object (29) to
>catch "blast" programs.  A blast program is defined as one which allows
>the user to make an unidentified message appear on another user's
>screen (in real time).
>        We have been having a lot of trouble with such users.  (I should
>complain?  They typically tell a pretty girl to report to the computer room.)
>
>        More generally, for an operating system (VMS) which is considered
>so secure, the blast message is a poke in the eye.  I hear that DEC's
>answer will be to simply remove the phone utility.

The two problems you mention are related to VMS's trusting the underlying 
network.

>        But a perhaps worse hole is the "fake mail" message, i.e., it uses
>the mail utility (object 27), but the name of the sender is replaced with a
>fake one.  [If I receive a message that says for me to report to the president's
>office at 7am, and act upon it, that is not a secure system.]  It seems to me
>that DEC could easily change mail to check for this switch, but maybe I do
>not understand about who is really accessing the object (is it the privileged
>system or is it the unprivileged user?).  

Normally, mail (on the local node) access the mail object on the remote node
on behalf of the local user.  Mail (on the local node) fills in the appropriate
from/to fields.  A user wishing to send a fake mail message need only connect
to the mail object on the remote node (the "remote node" could be the local
node if you specify 0::, nodename::) and fill in what they think should be
the "appropriate" fields.  The problem is that the local system allows a 
non-privileged user to connect to the mail object on a remote node (this can
be restricted in VMS V5.5-2 to require that only privileged users or images
can connect to the mail object on a remote node).

>And maybe if DEC changes the mail
>utility, the user will simply be able to supply an alternate one, for
>reasons unclear to me.
>        Does anyone have a program to check for this problem also?

The MAIL problem is "solved" (note the quotes, and see the last paragraph) in 
VMS V5.5-2.  The PHONE problem could be circumvented by taking away NETMBX 
from all your users and Installing those images that need NETMBX (MAIL.EXE, 
RTPAD.EXE) with the NETMBX privilege.

An idea to secure PHONE (similar to VMS V5.5-2's method to secure MAIL):

I just experimented with settting the PHONE object to require SYSNAM for 
outgoing connections (PHONE.EXE is installed with SYSNAM, among others), for
outgoing connections (just like VMS V5.5-2's release notes regarding Mail)
by performing the NCP command:  SET OBJECT PHONE OUTGOING PRIV SYSNAM.  This
seemed to prevent non-privileged users from using the PHONE object to 
connect to remote systems (or the local (0::) node).  VMS V5.5-1.  Could
someone else verify this?

If this does "secure" the PHONE object, it is the same as the VMS V5.5-2
"secure" of MAIL -- it doesn't prevent your system from receiving illegitimate 
messages from somewhere else on the DECnet network, it just prevents 
non-privileged users from sending illegitimate messages from your node to
other nodes.

-Dan Wing, dwing@uh01.colorado.edu or wing_d@ucolmcc.bitnet (DGW11)
 Systems Administrator, University Hospital, Denver