Bug 928105 (CVE-2013-1897)

Summary: CVE-2013-1897 389-ds: unintended information exposure when rootdse is enabled
Product: [Other] Security Response Reporter: Vincent Danen <vdanen>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED ERRATA QA Contact:
Severity: low Docs Contact:
Priority: low    
Version: unspecifiedCC: jgalipea, mkosek, nhosoi, nkinder, rcritten, rmeggins, security-response-team
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard: impact=low,public=20130328,reported=20130321,source=redhat,cvss2=2.6/AV:N/AC:H/Au:N/C:P/I:N/A:N,fedora-all/389-ds-base=affected,rhel-6/389-ds-base=affected,fedora-all/freeipa=affected,rhel-6/ipa=affected
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-08-21 19:53:50 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On: 923240, 928156, 928157, 928159, 928160, 928162, 928945, 928948    
Bug Blocks: 928163    

Description Vincent Danen 2013-03-26 18:23:20 EDT
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 18:26:16 EDT
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 11:12:35 EDT

This issue was discovered by Martin Kosek of Red Hat.
Comment 6 Vincent Danen 2013-03-28 15:16:14 EDT
This is fixed upstream here:


And noted in the upstream bug tracker here:

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

Affects: fedora-all [bug 928945]
Comment 8 Vincent Danen 2013-03-28 15:17:50 EDT
Created freeipa tracking bugs for this issue

Affects: fedora-all [bug 928948]
Comment 9 Vincent Danen 2013-04-03 11:28:54 EDT
For FreeIPA, the upstream ticket is here:

Comment 10 Fedora Update System 2013-04-11 06:07:04 EDT
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 14:22:56 EDT
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 02:11:48 EDT
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 19:53:50 EDT