Product
Solaris 9 Operating System
Solaris 8 Operating System

Bug Id
4701755, 4701811

Date of Resolved Release
11-APR-2006

Impact

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:

• ldapadd(1)
• ldapdelete(1)
• ldapmodify(1)
• ldapmodrdn(1)
• ldapsearch(1)

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.

Contributing Factors

These issues can occur in the following releases:

SPARC Platform

• Solaris 8 with patch 108993-14 through 108993-50 and without patch 108993-51
• Solaris 9 without patches 115677-02 and 121321-01

x86 Platform

• Solaris 8 with patch 108994-14 through 108994-50 and without patch 108994-51
• Solaris 9 without patches 115678-02 and 121322-01

Note: Solaris 10 is not impacted by these issues.

Symptoms

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.

For example:

    $ 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.)

For example:

    # 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:

• http://docs.sun.com/source/816-6699-10/logfiles.html

Workaround

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.

Resolution

These issues are addressed in the following releases:

SPARC Platform:

• Solaris 8 with patch 108993-51 or later
• Solaris 9 with patches 115677-02 or later and 121321-01 or later

x86 Platform

• Solaris 8 with patch 108994-51 or later
• Solaris 9 with patch 115678-02 or later and 121322-01 or later

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.

References

108993-51
108994-51
115677-02
121321-02
115678-02
121322-02




Attachments

This solution has no attachment