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.