Note: This is an archival copy of Security Sun Alert 201118 as previously published on http://sunsolve.sun.com.|
Latest version of this security advisory is available from http://support.oracle.com as Sun Alert 1000838.1.
Solaris 9 Operating System
Solaris 8 Operating System
Date of Resolved Release
Local unprivileged users may discover the Directory Server root Distinguished Name (rootDN) password if a privileged user uses the idsconfig(1M) command.
The rootDN password may also be observed if a privileged user runs any of the following LDAP commands insecurely:
The rootDN password may then be used to add, change delete and search records within the Directory Server.
Sun acknowledges, with thanks, Michael Gerdts for bringing these issues to our attention.
These issues can occur in the following releases:
Note: Solaris 10 is not impacted by these issues.
Directory server access logs may show unexpected connections made using the Directory Server rootDN which are not associated with the activities of trusted LDAP administrators.
The Directory Server access log location is dependent on the Directory Server. The Sun Java System Directory Server 5.0 or greater may be queried using ldapsearch(1) for the location of the access log.
$ ldapsearch -D "cn=Directory Manager" \ > -b cn=config -s base cn=config nsslapd-accesslog Enter bind password: <enter Directory Manager (rootDN) password> version: 1 dn: cn=config nsslapd-accesslog: /usr/iplanet/ds5/slapd-slapd-dss-on81/logs/access $
The access log is a text file with entries for each access to the directory. So assuming a rootDN of "Directory Manager" the following would show access times, connection number and access method:
# cd /usr/iplanet/ds5/slapd-slapd-dss-on81/logs # file access access: ascii text # grep -i 'dn="cn=Directory Manager"' access* | cut -d' ' -f1-3,8 [13/Dec/2005:13:41:09 +0000] conn=2123 method=128 [13/Dec/2005:13:43:00 +0000] conn=2126 method=128 [13/Dec/2005:13:43:41 +0000] conn=2127 method=128
You may then look in more detail at a particular connection using the connection number with grep(1). (The use of "cut" here is simply for aesthetics purposes.)
# grep conn=2126 access* | cut -d' ' -f 3- conn=2126 fd=31 slot=31 connection from 192.168.173.21 to 192.168.208.159 conn=2126 op=0 BIND dn="cn=Directory Manager" method=128 version=3 conn=2126 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=directory Manager" conn=2126 op=1 SRCH base="cn=config" scope=0 filter="(cn=config)" attrs="nsslapd-accesslog conn=2126 op=1 RESULT err=0 tag=101 nentries=1 etime=0 conn=2126 op=2 UNBIND conn=2126 op=2 fd=31 closed - U1 #
From the output above we can deduce that a successful (op=0 RESULT err=0) remote access occurred (the "from" and "to" IP addresses differ) using a LDAPv3 connection and plain text password (method=128). The query returned with 1 result (nentries=1)
For further information on the access log, refer to Chapter 8 "Access Logs and Connection Codes" of the Sun ONE Directory Server 5.2 Reference Manual:
To work around the described issues, have the LDAP Directory Server on a dedicated system where only trusted users have login access. Commands that use the directory Server RootDN, such as idsconfig(1M), should only be used locally on the dedicated secure LDAP server to prevent other users from observing the Directory Server RootDN and password.
For the commands ldapdelete(1), ldapmodify(1) or ldapsearch(1) use the identically named commands delivered with the Directory Server. The location of these commands depends on which Directory Server you are using.
On Solaris 9 the bundled iPlanet Directory Server is delivered in package "IPLTdsu" which by default installs the commands to "/usr/iplanet/ds5/shared/bin".
The un-packaged version of the Sun Java System Directory Server version 5.2 downloaded from http://www.sun.com installs these binaries by default in the "/var/Sun/mps/shared/bin" directory.
These issues are addressed in the following releases:
Note: Sun recommends that any existing scripts/programs written which use the ldapadd(1), ldapmodify(1), ldapmodrdn(1) or ldapsearch(1) commands with the -w option, should be changed to use the secure -j option instead.
The secure -j option is now available with the patches listed above. Examples of how to use this are available in the patched "/usr/lib/ldap/idsconfig" file.
This solution has no attachment