[Info-vax] Unexpected DECnet Phase IV functionality with possible captive account implications

[Mark Berryman]

On 5/11/21 11:34 AM, Simon Clubley wrote:
> On 2021-05-11, Dave Froble <davef at tsoft-inc.com> wrote:
 > .
 > .
> >
> I only found out about the remote batch submission capability after
> reading the FAL specification recently and that's from someone who
> has been actively discussing security issues in VMS for a number of years.
> 
 > .
 > .
 > .

<facepalm>

If this is how you found out about it then I have to assume there are a 
number of manuals you haven't read since remote batch submission is both 
known and documented.

I am also guessing that you have never been responsible for maintaining 
a captive account, or that you've read the various sections in the 
manuals you should read when setting one up.  In particular, you might 
want to pay attention to this line:

"Accounts under which network objects run, for example, require 
temporary access to DCL. "

To test, I set up a captive account WITHOUT any of the protections 
normally associated with a captive account.  For example, with rare 
exception, almost any captive account login procedure is going to have a 
line similar to the following near the top:

$ if f$mode() .nes. "INTERACTIVE" then logout

But let's skip that.  Let's pretend this account was set up by someone 
who didn't read the manuals.

This captive account simply runs a menu.  When the menu exits, the 
account exits.  Fortunately, VMS provides us with a nice menu to test 
with.  Here are the contents of the captive account's login procedure:

$ @ssl111$com:ssl111$cert_tool.com
$ logout

No sanity or security checks of any kind.  Just call the menu and logout 
when done.  Now, let's use DECnet to copy a file into the captive 
account so we can do something nefarious:

$ copy tmp.tmp aldur1"james password"::
%COPY-E-OPENOUT, error opening ALDUR1"james password"::[]tmp.tmp;1 as output
-RMS-E-CRE, ACP file create failed
-SYSTEM-F-LINKEXIT, network partner exited
%COPY-W-NOTCOPIED, USERS:[BERRYMAN]tmp.tmp;1 not copied

Oh dear, the copy failed.  I wonder why.  Let's check the netserver.log 
file to find out.  It turns out that network jobs happen to run the 
captive account's login procedure, which was a menu, which didn't 
understand what FAL was sending, so it retried a few times (several, 
actually) until it gave up and quit.

So let's simulate having some way to bypass that menu.  I've changed the 
login procedure to the following:

$ if f$mode() .eqs. "INTERACTIVE" then @ssl111$com:ssl111$cert_tool.com
$ logout

Same result, the copy fails.  So does $ SUBNET/REMOTE

In practice, Captive accounts will typically have quite a few sanity and 
security checks in them.  F$MODE checks in the login procedure, NOBATCH, 
NONETWORK, etc. in the UAF settings, lack of NETMBX privs, etc.  Any or 
all of these will prevent what you are trying to do.

So, tempest in a teapot anyone?

Mark Berryman