[comp.os.vms] Security problem in DQS

smith%eri.DECnet@MGHCCC.HARVARD.EDU ("ERI::SMITH") (12/04/87)

In the process of installing DQS (the distributed queue service), I was
mildly surprised to discover what looks to me like a fairly gross security
problem with its installation procedure.  I'm not a security maven.  I
don't think there's any harm in discussing it because if I've noticed it,
it's obvious.  And if I'm wrong and it's not a problem, I'd like someone
to explain to me why it isn't.

During VMSINSTAL, on a server node, DQS creates an account for its own
use.  More specifically, the account is for use by a network object that
is part of DQS.  It also creates a startup .COM file, to be invoked in
your SYSTARTUP and executed whenever the system is booted.

The file contains the NCP commands to DEFINE and SET the network object,
and it contains the password for the account which the network object
uses.

In other words, it writes a permanent file which contains an account
password in it.  Worse yet, it's a file that a) is REALLY permanent,
since it's going to be invoked by SYSTARTUP, b) is a file that has
a well-defined name, resides in a well-defined place, and refers to
an account that has a well-defined name and UIC.

They encourage you to let the installation process generate a random
password for you rather than choosing one yourself.  Hey, it's better
than "MANAGER".  And the account is only authorized for network
access.  I mean, _I_ don't know enough to exploit the hole it produces.

But I thought writing account passwords into files was a no-no.
--------------------------------------------------------------------
Daniel P. B. Smith         ARPA: smith%eri.decnet@mghccc.harvard.edu
Eye Research Institute     CompuServe: 74706,661
20 Staniford Street        Telephone (voice): 617 742-3140
Boston, MA 02114
--------------------------------------------------------------------
"We are in great haste to construct a magnetic telegraph from Maine to
Texas; but Maine and Texas, it may be, have nothing important to
communicate."--Thoreau
------

klb@philabs.Philips.Com (Ken Bourque) (12/07/87)

In article <8712050259.AA29107@ucbvax.Berkeley.EDU> "ERI::SMITH" <smith%eri.decnet@mghccc.harvard.edu> writes:
->
->During VMSINSTAL, on a server node, DQS creates an account for its own
->use.  More specifically, the account is for use by a network object that
->is part of DQS.  It also creates a startup .COM file, to be invoked in
->your SYSTARTUP and executed whenever the system is booted.
->
->The file contains the NCP commands to DEFINE and SET the network object,
->and it contains the password for the account which the network object
->uses.

Passwords are already stored in the clear in the permanent DECnet database, for
whatever that's worth....This startup procedure seems superfluous - once the
object is DEFINEd in the permanent DECnet database there is no need to
redefine it, and it will be SET into the volatile database automatically when
DECnet is started.

-- 
Ken Bourque    klb@philabs.philips.com    ...!{uunet,ihnp4,decvax}!philabs!klb

IMHW400@INDYVAX.BITNET (12/08/87)

It should do no harm to simply delete the offending file after it has been
executed once, instead of doing it at SYSTARTUP time.  Since it does a DEFINE,
the password will be in the permanent DECnet database and need never be set
again, unless one wishes to change it.  I can't help feeling that the person
who wrote the DQS startup procedure has no previous experience with DECnet
management.  (*sigh*)

This *does* mean that the password is *still* stored in a file, but we can
hope that DECnet uses the system password encryption routine to hash it
(as LOGINOUT, AUTHORIZE, and SET PASSWORD do).  Are you listening, DEC?

carl@CITHEX.CALTECH.EDU (Carl J Lydick) (12/09/87)

 > It should do no harm to simply delete the offending file after it has been
 > executed once, instead of doing it at SYSTARTUP time.  Since it does a DEFINE,
 > the password will be in the permanent DECnet database and need never be set
 > again, unless one wishes to change it.  I can't help feeling that the person
 > who wrote the DQS startup procedure has no previous experience with DECnet
 > management.  (*sigh*)

Good point.

 > This *does* mean that the password is *still* stored in a file, but we can
 > hope that DECnet uses the system password encryption routine to hash it
 > (as LOGINOUT, AUTHORIZE, and SET PASSWORD do).  Are you listening, DEC?

From the way you phrase this, I conclude that you ARE aware of the fact
that the password is stored in the clear (though the installation procedure
for VMS [or for DECnet, if you're on a uVAX] protects the file against reading
by world).  Unfortunately, the way things seem to work is that DECnet takes
the password given it (from the default DECnet account [privileged or
non-privileged, as appropriate], or from the definition of the object in
question, or from an ACE), hashes it, then compares it to what's in SYSUAF.
If my impression as to how DECnet handles access attempts from remote machines
is correct, then the password MUST be stored in the clear.  One remedy would,
of course, be to hash the password twice in normal usage before the compare,
but have DECnet hash it once before storing it in a file, then hash it the
second time before it makes its own comparison.