Bug 928105 (CVE-2013-1897) - CVE-2013-1897 389-ds: unintended information exposure when rootdse is enabled
Summary: CVE-2013-1897 389-ds: unintended information exposure when rootdse is enabled
Alias: CVE-2013-1897
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
Depends On: 923240 928156 928157 928159 928160 928162 928945 928948
Blocks: 928163
TreeView+ depends on / blocked
Reported: 2013-03-26 22:23 UTC by Vincent Danen
Modified: 2023-05-12 19:07 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2015-08-21 23:53:50 UTC

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Github 389ds 389-ds-base issues 645 0 None closed unintended information exposure when anonymous access is set to rootdse 2020-10-05 07:50:14 UTC
Red Hat Product Errata RHSA-2013:0742 0 normal SHIPPED_LIVE Low: 389-ds-base security and bug fix update 2013-04-15 22:21:56 UTC

Description Vincent Danen 2013-03-26 22:23:20 UTC
It was found that the 389 Directory Server did not properly restrict access to entries when the 'nsslapd-allow-anonymous-access' configuration setting is set to 'rootdse'.  An anonymous user could connect to the LDAP database and, if the search scope is set to BASE, obtain access to information outside of the rootDSE.  The 'rootdse' option exists to provide anonymous access to the rootDSE but no other entries in the directory.  An administrator could believe that directory entries are being restricted with this option enabled, however the information provided would be the same as if 'nsslapd-allow-anonymous-access' were set to 'on'.

ACI's are still properly evaluated despite this flaw, so this can easily be mitigated by removing the anonymous read ACL.

Comment 1 Vincent Danen 2013-03-26 22:26:16 UTC
Note that by default, in both 389 Directory Server and FreeIPA, that 'nsslapd-anonymous-access' is not set to 'rootdse' and this would require administrative privileges to change.

Steps to mitigate:

Because there is a single anonymous access ACI by default that is stored in the top-level suffix entry, we can verify that exists and later that it is removed (using the suffix "dc=example,dc=com"):

[root@localhost ~]# ldapsearch -x -D "cn=directory manager" -w [password] 
-b "dc=example,dc=com" -s base "aci=*" aci
# extended LDIF
# LDAPv3
# base <dc=example,dc=com> with scope baseObject
# filter: aci=*
# requesting: aci

# example.com
dn: dc=example,dc=com
aci: (targetattr!="userPassword")(version 3.0; acl "Enable anonymous 
  allow (read, search, compare) userdn="ldap:///anyone";)
aci: (targetattr="carLicense || description || displayName || 
  neNumber || homePhone || homePostalAddress || initials || jpegPhoto || 
  dURI || mail || mobile || pager || photo || postOfficeBox || 
postalAddress ||
   postalCode || preferredDeliveryMethod || preferredLanguage || 
  ess || roomNumber || secretary || seeAlso || st || street || 
  || telexNumber || title || userCertificate || userPassword || 
  icate || x500UniqueIdentifier")(version 3.0; acl "Enable self write 
for commo
  n attributes"; allow (write) userdn="ldap:///self";)
aci: (targetattr ="*")(version 3.0;acl "Directory Administrators 
  (all) (groupdn = "ldap:///cn=Directory Administrators, 

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

To remove the anonymous access ACI, you can use ldapmodify as follows:

[root@localhost ~]# ldapmodify -x -D "cn=directory manager" -w [password]
dn: dc=example,dc=com
changetype: modify
delete: aci
aci: (targetattr!="userPassword")(version 3.0; acl "Enable anonymous 
access"; allow (read, search, compare) userdn="ldap:///anyone";)

modifying entry "dc=example,dc=com"

Searching for the ACIs again should show that the anonymous access ACI 
is gone.  The anonymous data access should be restricted immediately 
without restarting the Directory Server.

Comment 4 Vincent Danen 2013-03-27 15:12:35 UTC

This issue was discovered by Martin Kosek of Red Hat.

Comment 6 Vincent Danen 2013-03-28 19:16:14 UTC
This is fixed upstream here:


And noted in the upstream bug tracker here:


Comment 7 Vincent Danen 2013-03-28 19:17:41 UTC
Created 389-ds-base tracking bugs for this issue

Affects: fedora-all [bug 928945]

Comment 8 Vincent Danen 2013-03-28 19:17:50 UTC
Created freeipa tracking bugs for this issue

Affects: fedora-all [bug 928948]

Comment 9 Vincent Danen 2013-04-03 15:28:54 UTC
For FreeIPA, the upstream ticket is here:


Comment 10 Fedora Update System 2013-04-11 10:07:04 UTC
freeipa-3.1.3-4.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 11 errata-xmlrpc 2013-04-15 18:22:56 UTC
This issue has been addressed in following products:

  Red Hat Enterprise Linux 6

Via RHSA-2013:0742 https://rhn.redhat.com/errata/RHSA-2013-0742.html

Comment 12 Fedora Update System 2013-06-13 06:11:48 UTC
389-ds-base- has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 13 Vincent Danen 2015-08-21 23:53:50 UTC


Note You need to log in before you can comment on or make changes to this bug.