Bug 928105 - (CVE-2013-1897) CVE-2013-1897 389-ds: unintended information exposure when rootdse is enabled
CVE-2013-1897 389-ds: unintended information exposure when rootdse is enabled
Status: CLOSED ERRATA
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
low Severity low
: ---
: ---
Assigned To: Red Hat Product Security
impact=low,public=20130328,reported=2...
: Security
Depends On: 923240 928156 928157 928159 928160 928162 928945 928948
Blocks: 928163
  Show dependency treegraph
 
Reported: 2013-03-26 18:23 EDT by Vincent Danen
Modified: 2015-08-21 19:53 EDT (History)
7 users (show)

See Also:
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:


Attachments (Terms of Use)

  None (edit)
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 
access";
  allow (read, search, compare) userdn="ldap:///anyone";)
aci: (targetattr="carLicense || description || displayName || 
facsimileTelepho
  neNumber || homePhone || homePostalAddress || initials || jpegPhoto || 
labele
  dURI || mail || mobile || pager || photo || postOfficeBox || 
postalAddress ||
   postalCode || preferredDeliveryMethod || preferredLanguage || 
registeredAddr
  ess || roomNumber || secretary || seeAlso || st || street || 
telephoneNumber
  || telexNumber || title || userCertificate || userPassword || 
userSMIMECertif
  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 
Group";allow
  (all) (groupdn = "ldap:///cn=Directory Administrators, 
dc=example,dc=com");)

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

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:

http://git.fedorahosted.org/cgit/389/ds.git/commit/?h=389-ds-base-1.2.11&id=5a18c828533a670e7143327893f8171a19062286

And noted in the upstream bug tracker here:

https://fedorahosted.org/389/ticket/47308
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:

https://fedorahosted.org/freeipa/ticket/3540
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-1.2.11.21-1.fc17 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
Statement:

(none)

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