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:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-08-21 23:53:50 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 923240, 928156, 928157, 928159, 928160, 928162, 928945, 928948    
Bug Blocks: 928163    

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 
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 15:12:35 UTC
Acknowledgements:

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:

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

https://fedorahosted.org/freeipa/ticket/3540

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-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 23:53:50 UTC
Statement:

(none)