From:	CRDGW2::CRDGW2::MRGATE::"SMTP::YMIR.CLAREMONT.EDU::POSTMAST" 20-OCT-1989 04:04
To:	MRGATE::"ARISIA::EVERHART"
Subj:	PMDF security and the SPAN worm

Resent-From: postmast@YMIR.CLAREMONT.EDU
Received: from HMCVAX.BITNET by YMIR.BITNET; Thu, 19 Oct 89 23:24 PDT
Resent-Date: Thu, 19 Oct 89 23:26 PDT
Date: Thu, 19 Oct 89 23:24 PDT
From: "Ned Freed, Postmaster" <ned@YMIR.CLAREMONT.EDU>
Subject: PMDF security and the SPAN worm
Resent-To: INFO-PMDF-LIST2@YMIR.CLAREMONT.EDU
To: Ichihara@rik835.riken.go.jp, INFO-PMDF@YMIR.CLAREMONT.EDU
Errors-To: postmast@YMIR.CLAREMONT.EDU
Resent-Message-Id: <37AF1B92229F00046E@YMIR.BITNET>
Message-Id: <37AF83CA20BF8000AA@HMCVAX.BITNET>
X-Vms-To: IN%"Ichihara@rik835.riken.go.jp",IPMDF

A couple of people have asked about PMDF and possible involvement with the new
worm that's crawling around on the SPAN network. As far as I know there's
nothing in the worm that singles out PMDF in any way. However, as long as the
subject is on the table I thought I'd say a few words about PMDF and security.
I'm assuming a standard PMDF installation here, and I'm only looking at the
implications of having a PMDF account.

(1) If you don't know the password to the PMDF account, you cannot break in to
    it at all, either over async lines or via DECnet. Please pick a difficult
    password for the account! This is about the only way the SPAN worm
    could take advantage of PMDF; it is no different from any other account.

(2) If someone has the password to the PMDF account, they can obviously
    play around via various channel programs (SLAVE on async lines and
    either DSMTP_SLAVE or DN_SLAVE over DECnet) with message files. It is
    rather hard to do much unless you either have a copy of PMDF to use or
    you're good at typing a lot of hex gibberish for PhoneNet or SMTP commands
    for DSMTP_SLAVE. This is the only sort of access the password gets you
    over async lines.

(3) If you have the PMDF account password and DECnet access you can use the
    various components of DECnet to muck around with the files in
    PMDF_ROOT:[LOG] and PMDF_ROOT:[QUEUE...]. FAL access is a particular
    issue. If this is a problem it is not too hard to block -- the easiest way
    to do it is to put an ACL on SYS$SYSTEM:FAL.EXE that denies access to the
    PMDF account. Nice and clean. Task access is not possible since there are
    no .COM files in the PMDF_ROOT:[LOG] directory (you have to block FAL
    access to make sure none show up, of course). Access via any other DECnet
    objects can be blocked in similar ways.

In summary, I don't think that PMDF causes any significant security holes.

					Ned