Issue 9038 - rootdn of any db can assert any identity
Summary: rootdn of any db can assert any identity
Status: VERIFIED FIXED
Alias: None
Product: OpenLDAP
Classification: Unclassified
Component: slapd (show other issues)
Version: unspecified
Hardware: All All
: --- normal
Target Milestone: ---
Assignee: OpenLDAP project
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-06-19 11:21 UTC by Ondřej Kuzník
Modified: 2019-07-24 19:07 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description Ondřej Kuzník 2019-06-19 11:21:08 UTC
Full_Name: Ondrej Kuznik
Version: re24/master
OS: any
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (82.10.24.68)


Playing around with proxyauthz control, it looks like being a rootdn of a
database (any DB) the identity can then assume any other without restriction.

This is a problem when the admin delegates rootdn privileges but wants to retain
control over cn=config. Not a common use case, luckily.

Not sure yet whether the conditions to get that happen are even more relaxed
than that. This is even when olcAuthzPolicy == none.

There seem to be two different ways to reproduce:
- bind as a rootdn for a db, then e.g. ldapsearch -e '!authzid=dn:cn=config' -b
cn=config
- SASL bind as a rootdn but provide -X dn:cn=config

Might be we're not doing the authz check from the point of view of the target
DB? Don't know what would need to be done with glued DBs though.
Comment 1 Howard Chu 2019-06-19 11:35:50 UTC
changed notes
moved from Incoming to Software Bugs
Comment 2 Howard Chu 2019-06-19 11:36:03 UTC
changed state Open to Test
Comment 3 Quanah Gibson-Mount 2019-06-20 18:09:38 UTC
changed notes
changed state Test to Release
Comment 4 Quanah Gibson-Mount 2019-07-11 17:22:59 UTC
changed notes
Comment 5 Quanah Gibson-Mount 2019-07-24 19:06:42 UTC
changed notes
Comment 6 Quanah Gibson-Mount 2019-07-24 19:06:43 UTC
published 9038
marked public
Comment 7 OpenLDAP project 2019-07-24 19:07:08 UTC
Fixed in master
Fixed in RE24 (2.4.48)
CVE-2019-13057
Comment 8 Quanah Gibson-Mount 2019-07-24 19:07:08 UTC
changed notes
changed state Release to Closed