From:	SMTP%"Info-VAX-Request@Mvb.Saic.Com" 20-SEP-1994 14:38:22.95
To:	EVERHART
CC:	
Subj:	Re: Problems with SYS$GRANTID

X-Newsgroups: comp.os.vms
From: vaxs09@alpha.vitro.com
Subject: Re: Problems with SYS$GRANTID
Message-ID: <1994Sep20.130014@alpha.vitro.com>
Lines: 50
Sender: news@vitro.com (USENET News System)
Organization: Vitro Corporation
Date: Tue, 20 Sep 1994 17:00:14 GMT
To: Info-VAX@Mvb.Saic.Com
X-Gateway-Source-Info: USENET

In article <35a9df$54j@gap.cco.caltech.edu>, carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick) writes:
> =  o Redefine job logical names that the spawned subprocess will use,
> =    causing it to run the attacker's images instead of the intended
> =    images.
> =
> =  o Redefine SYS$SYSTEM (and thereby cause LIB$SPAWN to run the
> =    attacker's own image instead of SYS$SYSTEM:LOGINOUT.EXE)
> 
> Both of these are quite easily dealt with by defining LNM$FILE_DEV in the
> LNM$PROCESS_DIRECTORY table to point only to LNM$SYSTEM before calling
> LIB$SPAWN.

Nice.  Simple and [almost] effective.  But the attacker can still
redefine LNM$SYSTEM to LNM$JOB in LNM$PROCESS_DIRECTORY and make sure
that he's [re]defined SYS$SYSTEM in LNM$JOB.  Yes, I know.  The defender
could make sure to deassign LNM$SYSTEM in LNM$PROCESS_DIRECTORY. While
he's at it, he'd better look out for LNM$SYSTEM_TABLE as well.

The defender has also got to make sure that he _DOES NOT_ suppress
propagation of logicals from the parent to the subprocess.  Otherwise,
the subprocess won't inherit the restricted definition of LNM$FILE_DEV
from the parent.  (The defender might also be able to finesse this by
doing a "DEFINE /TABLE=LNM$PROCESS_DIRECTORY LNM$FILE_DEV LNM$SYSTEM"
in the context of the subprocess but he'd better be careful not to
do so in the context of a command procedure whose name could be
spoofed with logical name redefinitions such as SYS$DISK, $1$DUA1234 or
MY_TRUSTED_COMMAND_PROCEDURE).

If anyone is going to use Carl's advice to stuff these particular loopholes,
(along with my second-order loophole stuffing advice) be aware that you'll
have trouble with SYS$INPUT and SYS$OUTPUT.

Even if the defender takes these steps, his system is still open to the
mailbox attack mentioned in my earlier post.

If the defender doesn't like the restricted environment imposed by
LNM$FILE_DEV = LNM$SYSTEM and attempts to build a user-friendly
environment back up, he's likely to be introducing some new security
loopholes in the process.

The point I was trying to make (with which I think Carl would agree) is
that spawning from privileged images so that the subprocess inherits
privilege is _NOT SAFE_.  It's difficult (I believe it's impossible) to
close all the loopholes.  It's doubly difficult to be sure that you've
got them all closed.

You may judge that nobody on _your_ network is devious enough or smart
enough to use these attacks.  That is, of course, _your_ business.

	John Briggs			briggs@vitro.com