ECO NUMBER: DCEALPE01_B013 ----------- PRODUCT: Distributed Computing Environment (DCE) for OpenVMS -------- UPDATED PRODUCT: Distributed Computing Environment (DCE) for OpenVMS 1.3B ---------------- APPRX BLCK SIZE: 6084 ---------------- COVER LETTER 1 KIT NAME: DCEALPE01_B013 2 KITS SUPERSEDED BY THIS KIT: None. 3 KIT DESCRIPTION: 3.1 Version(s) of OpenVMS to which this kit may be applied: OpenVMS Alpha V1.5 thru V7.* 3.2 In order to receive the full fixes listed in this kit the following remedial kits also need to be installed: This is a list of the files to be provided in the DCE ECO kit, the directories where they must be installed, and the file protection that must be set on the files. This kit must only be installed on a system which is running DCE V1.3 MUPB. You can identify such a system by searching for the file SYS$LIBRARY:DCE$LIB_SHR.EXE and verifying that it has a link date of 25-OCT-1995 or 29-FEB-1996. The kit installation procedure will perform this check. If it finds that the SYS$LIBRARY:DCE$LIB_SHR.EXE image was not linked on one of the listed dates, the installation will abort. Please note that the kit does not include the 1996 leap year fix, as this was only necessary for a narrow window of time in effect on February 29, 1996. SYS$COMMON:[SYSEXE]DCE$CDSADV.EXE (RWED,RWED,RWED,RE) SYS$COMMON:[SYSEXE]DCE$CDSD.EXE (RWED,RWED,RWED,RE) SYS$COMMON:[SYSEXE]DCE$SECD.EXE (RWED,RWED,RWED,RE) SYS$COMMON:[SYSMGR]DCE$SETUP.COM (RWED,RWED,RWED,RE) SYS$COMMON:[SYSMGR]DCE$SETUP_MULTINET.COM (RWED,RWED,RWED,RE) SYS$COMMON:[SYSLIB]DCE$SOCKSHR_IP.EXE (RWED,RWED,RWED,RE) SYS$COMMON:[SYSLIB]DCE$SOCKSHR_DNET_OSI.EXE (RWED,RWED,RWED,RE) 3.3 Files patched or replaced: o [SYSEXE]DCE$CDSADV.EXE (new image) o [SYSEXE]DCE$CDSD.EXE (new image) -- COVER LETTER -- Page 2 27 August 1996 o [SYSEXE]DCE$SECD.EXE (new image) o [SYSLIB]DCE$SOCKSHR_DNET_OSI.EXE (new image) o [SYSLIB]DCE$SOCKSHR_IP.EXE (new image) o [SYSMGR]DCE$SETUP.COM (new file) o [SYSMGR]DCE$SETUP_MULTINET.COM (new file) 4 PROBLEMS ADDRESSED IN THE DCEALPE01_B013 KIT o On OpenVMS VAX and Alpha systems running OpenVMS DCE V1.3 MUPA or V1.3 MUPB, CDS imposes incorrect limits for the length of cell names. This limit could cause problems when configuring an OpenVMS system into a non-OpenVMS cell. o On OpenVMS VAX and Alpha systems running OpenVMS DCE V1.3 MUPA or V1.3 MUPB, configured as a CDS client in a cell where the CDS Server is not within broadcast range, the configuration and/or startup of DCE can fail when trying to define a cached server. The output from the DCE configuration and/or startup procedure may look like this: Starting CDS Name Service Advertiser daemon (DCE$CDSADV) . . . %RUN-S-PROC_ID, identification of created process is 3020013D **************************** ERROR **************************** *** An error occurred while attempting to establish a CDS cached *** server on this system. Command: *** $ Dce$Cdscp Define Cached Server "name" - *** tower "ncadg_ip_udp:xx.xx.xx.xx" This problem is intermittent and may cause a failure in configuration and/or startup only some of the time. o On OpenVMS VAX and Alpha systems running OpenVMS DCE V1.3 MUPA or V1.3 MUPB with TGV's Multinet, there can be a problem configuring DCE if the file MULTINET:HOSTS.LOCAL contains SERVICE statements for services other than DCE. If the problem exists, the log file SYS$MANAGER:DCE$SETUP.LOG will contain the following information: $ Append "'SvcCmd'" to file Multinet:Hosts.Local ********************* WARNING ******************* *** An error occurred attempting to establish the *** TCP/IP service port number needed for CDS Client *** and Clerk communication. *** *** Could not open the output file from the command: *** $ SERVICE : TCP : 1236 : cdsDiag : *** %RMS-E-FNF, file not found -- COVER LETTER -- Page 3 27 August 1996 CONFIGURE: *** Operation completed *** o On OpenVMS VAX and Alpha systems running OpenVMS DCE V1.3 MUPA or V1.3 MUPB, configured as DCE Security Servers, the DCE$SECD process can hang during startup and cause all security related operations to fail. The output from the DCE startup procedure may look like this: Starting Security Service Server daemon (DCE$SECD) . . . %RUN-S-PROC_ID, identification of created process is 40A0202E Logging in to DCE using principal "cell_admin" . . . **************************** ERROR **************************** *** An error occurred attempting to log in to DCE with principal *** name "cell_admin" Sorry. User Identification Failure. - Registry server unavailable (dce / sec) This problem is most prevalent on multi-processor systems and systems running TGV's Multinet TCP/IP software but it does not occur 100% of the time. It is possible to have DCE$SECD hang on one attempt to start DCE and have it work successfully on the next attempt. o The security of DCE services and DCE-based applications may be compromised; impersonation of legitimate users and administrators is possible. DCE uses randomly-generated encryption keys as a part of the protocols it uses to authenticate and protect communications between various parties (such as hosts, application services and DCE components). A potential security vulnerability in the way that the DCE Security Service generates such keys may allow an attacker to compromise DCE security. Such an attack would require that the attacker have direct access to the network hosting a DCE cell. A replacement for the DCE Security Server (DCE$SECD.EXE) removes this potential security vulnerability. Cell administrators should obtain and install the replacement image. The cell administrators then must also perform the following additional procedures to ensure that all potentially vulnerable keys generated by the original DCE$SECD program are replaced: o All randomly-generated keys in all keytabs (server keys) in the cell need to be changed. Each machine in the cell may have one default keytab file and a number of additional application-specific keytab files. Application-specific keytab files may be created anywhere in the filesystem. Administrators should check with application developers to determine whether their applications create such files. To view the principals whose keys are stored in keytab files on a machine perform the following: a) Log in to a privileged account and then perform a dce_login to acquire administrative DCE credentials (cell_admin is -- COVER LETTER -- Page 4 27 August 1996 the default DCE administrative account). b) Run rgy_edit and issue the command: ktlist -- to display the contents of the default keytable For every application specific keytab file on the machine issue the command: ktlist -f -- to display the contents of application keytab These commands should be performed on every machine in the cell, to construct a list of which principal keys appear in which keytab files on which machines. It is possible that the same principal key appears in multiple keytab files. If this is the case then either that principal's key is password-derived (in which case the key was not generated by the weak random number generator and does not therefore need to be replaced¹), or an application-specific key synchronization mechanism must be in use. In the latter case, the application writer should be contacted for information on how to change the key. ¹ The use of password-derived server keys should be strongly discouraged, as server keys are used to protect traffic on the network, and password-derived keys may be less resistant to discovery than machine-generate keys. o For each principal whose key appears in only a single keytab file: a) Log in to a privileged account on the machine that hosts the keytab file , and then perform a dce_login to acquire administrative DCE credentials (cell_admin is the default DCE administrative account). b) If 's key is in the default keytab file, issue the following rgy_edit command: kta -p -r -a If 's key is in an application-specific keytab file , issue the rgy_edit command: kta -p -r -a -f These commands change the principal's key in the DCE Registry, and also update the value stored in the appropriate keytab file. o One possible result of this potential security vulnerability is that a successful exploitation would allow an attacker to impersonate users, possibly including administrative users. After any such potential security -- COVER LETTER -- Page 5 27 August 1996 vulnerability is discovered and fixed, the cell administrator should verify that the DCE Registry contents have not been tampered with. After replacing DCE$SECD, the cell administrator should manually inspect the registry database, checking that no new privileged accounts have been added, that no existing accounts have acquired additional group memberships, and that ACLs within the registry have not been altered. o On OpenVMS VAX and Alpha systems running OpenVMS DCE V1.3 MUPA or V1.3 MUPB, an extraneous rpccp profile entry with " /.:/sec" is created when configuring a CDS Server. To see if your configuration contains this entry use the following command: $ rpccp show profile /.:/cell-profile If your configuration has two entries with " secidmap", then you have the problem: 0d7c1e50-113a-11ca-b71f-08001e01dc6c,1.0 /.:/sec 0 secidmap 0d7c1e50-113a-11ca-b71f-08001e01dc6c,1.0 /.:/sec-v1 0 secidmap The entry with " /.:/sec" is extraneous and should be deleted. However, the entry with " /.:/sec-v1" is correct. Please leave it alone. You can remove this entry by performing a DCE_LOGIN as a privileged DCE principal and issuing the command: $ rpccp remove element /.:/cell-profile - -i 0d7c1e50-113a-11ca-b71f-08001e01dc6c,1.0 - -m /.:/sec -a secidmap o On OpenVMS VAX and Alpha systems running OpenVMS DCE V1.3 MUPA or V1.3 MUPB, an error may be reported by DCE$DTSD during DCE startup. The error indicates that DTS may not operate properly yet all DTS functions seem to work. This problem is most prevalent on multi-processor systems but it doesn't occur 100% of the time. o On OpenVMS VAX and Alpha systems running OpenVMS DCE V1.3 MUPA or V1.3 MUPB, an error may be reported by CDS during the configuration of a DCE client system. The error indicates that a cached server could not be defined. This problem is most prevalent on multi-processor systems but it doesn't occur 100% of the time. The terminal output may look like this if you -- COVER LETTER -- Page 6 27 August 1996 have the problem: **************************** ERROR **************************** *** An error occurred while attempting to establish a CDS cached *** server on this system. Command: *** $ Dce$Cdscp Define Cached Server "mynode" - *** tower "ncacn_ip_udp:11.22.33.44" o On OpenVMS VAX and Alpha systems running OpenVMS DCE V1.3 MUPA or V1.3 MUPB, the DCE configuration command procedure may not be able to determine the DECnet ALIAS address on a system running DECnet/OSI and configured with a Cluster Alias. The result is that the Alias address may be used by DCE servers which may prevent DCE clients from contacting the servers. o On OpenVMS VAX and Alpha systems running OpenVMS DCE V1.3 MUPA or V1.3 MUPB, the DCE configuration command procedure uses incorrect values to limit the maximum length of cell names. On systems configured as CDS servers the limit should be 29 characters but is currently set to 30 characters. On systems configured as CDS clients the limit should be 128 characters but is also currently set to 30 characters. The result could be DCE systems that can't be configured properly. o On OpenVMS VAX and Alpha systems running OpenVMS DCE V1.3 MUPB and DECnet/OSI, the DCE$CDSADV process can terminate prematurely and cause a DCE configuration or startup to fail. This problem only happens on systems which are configured with a DECnet/OSI NSAP that is 17 bytes or longer. o On OpenVMS VAX and Alpha systems running OpenVMS DCE V1.3 MUPA or V1.3 MUPB, the DCE$RPCD process can terminate prematurely and cause all DCE operations to fail. The output from the DCE startup procedure may look like this: The DCE daemons on this system are now being started . . . Starting Remote Procedure Call Services daemon (DCE$RPCD) . . . %RUN-S-PROC_ID, identification of created process is 40A0289C Starting Security Service Server daemon (DCE$SECD) . . . %RUN-S-PROC_ID, identification of created process is 40A0489D ************************* ERROR ************************ *** Error - Process DCE$SECD is not running *** DCE System Management Procedure Complete *** The contents of DCE$LOCAL:[VAR.RPC.ADM]DCE$RPCD.OUT will look like this: (socket) >1 select in UCX TL *** FATAL ERROR at RPC$SOCKSHR_UCX.C;1\2118 *** %SYSTEM-F-IVCHAN, invalid I/O channel This problem is most prevalent on multi-processor systems but -- COVER LETTER -- Page 7 27 August 1996 it doesn't occur 100% of the time. It is possible to have DCE$RPCD terminate on one attempt to start DCE and have it work successfully on the next attempt. o On OpenVMS VAX and Alpha systems running OpenVMS DCE V1.3 MUPA or V1.3 MUPB, user written DCE applications may experience a problem with an increasing number of unused, UCX, BG devices being allocated to a process. DCE client and server applications communicate with each other over TCP/IP via BG devices which are dynamically created and deleted as needed. In some cases the BG devices aren't deleted, eventually causing the process to run out of resources. You can examine the BG devices allocated to a process using the DCL command: $ show process For each BG device allocated to the process you should be able to execute the UCX command: UCX> show dev BGxxxx and see the socket information for that BG device. For DCE server processes there will be one BG device for which UCX will return the error: %UCX-W-NODEVSOCK, Device_socket not found This is a normal occurrence and is not a problem. If a DCE process has numerous BG devices for which UCX returns this error then you may be experiencing this problem. 5 INSTALLATION INSTRUCTIONS: Install this kit with the VMSINSTAL utility by logging into the SYSTEM account, and typing the following at the DCL prompt: @SYS$UPDATE:VMSINSTAL DCEALPE01_B013 [location of the saveset] The saveset location may be a tape drive, or a disk directory that contains the kit saveset. No reboot is necessary after successful installation of the kit. However, before installing the kit you must stop DCE by issuing the following command: $ DCE_SETUP STOP NOCONF After the kit is installed you must restart DCE by issuing the following command: $ DCE_SETUP START NOCONF -- COVER LETTER -- Page 8 27 August 1996 Copyright Digital Equipment Corporation 1996. All Rights reserved. This software is proprietary to and embodies the confidential technology of Digital Equipment Corporation. Possession, use, or copying of this software and media is authorized only pursuant to a valid written license from Digital or an authorized sublicensor. This ECO has not been through an exhaustive field test process. Due to the experimental stage of this ECO/workaround, Digital makes no representations regarding its use or performance. The customer shall have the sole responsibility for adequate protection and back-up data used in conjunction with this ECO/workaround.