If a request is made with LDAP controls attached, but the controls have length 0, the server will err=2, failed to decode LDAP controls. This worked fine with mozldap but doesn't work with openldap.
== Here is the current status ==
{{{ [14/Feb/2013:15:18:31 +0100] conn=3 fd=64 slot=64 connection from ::1 to ::1 [14/Feb/2013:15:18:31 +0100] conn=3 op=0 BIND dn="cn=directory manager" method=128 version=2 [14/Feb/2013:15:18:31 +0100] conn=3 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=directory manager" [14/Feb/2013:15:18:31 +0100] conn=3 op=1 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs=ALL [14/Feb/2013:15:18:31 +0100] conn=3 op=1 RESULT err=0 tag=101 nentries=1 etime=0 [14/Feb/2013:15:18:31 +0100] conn=3 op=2 UNBIND [14/Feb/2013:15:18:31 +0100] conn=3 op=2 fd=64 closed - U1 }}}
[[BR]] [[BR]]
While it was rejected with mozldap [[BR]]
{{{ [14/Feb/2013:15:18:53 +0100] conn=4 fd=64 slot=64 connection from 127.0.0.1 to 127.0.0.1 [14/Feb/2013:15:18:53 +0100] conn=4 op=0 BIND dn="cn=directory manager" method=128 version=3 [14/Feb/2013:15:18:53 +0100] conn=4 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=directory manager" [14/Feb/2013:15:18:53 +0100] conn=4 op=1 SRCH base="dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs=ALL [14/Feb/2013:15:18:53 +0100] conn=4 op=1 RESULT err=2 tag=101 nentries=0 etime=0 [14/Feb/2013:15:18:53 +0100] conn=4 op=-1 fd=64 closed - B1
}}}
I suppose that openldap is not sending the "invalid" control but I need to check that
== Here are the next steps ==
Here are the next steps
Can we change get_ldapmessage_controls_ext() to not return an error if it sees a zero length sequence of controls?
This is already done, if the length of sequence of control is zero. The function get_ldapmessage_controls_ext() returns LDAP_SUCCESS and the operation is continuing.
Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=918717
commit 36425a3 This commit addresses CVE-2013-0312. git push origin 389-ds-base-1.2.11 Counting objects: 47, done. Delta compression using up to 4 threads. Compressing objects: 100% (24/24), done. Writing objects: 100% (24/24), 2.75 KiB, done. Total 24 (delta 21), reused 0 (delta 0) To ssh://git.fedorahosted.org/git/389/ds.git f32980b..36425a3 389-ds-base-1.2.11 -> 389-ds-base-1.2.11 git push origin master Counting objects: 47, done. Delta compression using up to 4 threads. Compressing objects: 100% (24/24), done. Writing objects: 100% (24/24), 2.80 KiB, done. Total 24 (delta 21), reused 0 (delta 0) To ssh://git.fedorahosted.org/git/389/ds.git da3be3f..ae13e44 master -> master git push origin 389-ds-base-1.3.0 Counting objects: 47, done. Delta compression using up to 4 threads. Compressing objects: 100% (24/24), done. Writing objects: 100% (24/24), 2.78 KiB, done. Total 24 (delta 21), reused 0 (delta 0) To ssh://git.fedorahosted.org/git/389/ds.git 8e0a35c..21c079e 389-ds-base-1.3.0 -> 389-ds-base-1.3.0 I had to commit some changes to 1.3.0/1.2.11 for two slapi attr functions: git push origin 389-ds-base-1.3.0 Counting objects: 17, done. Delta compression using up to 4 threads. Compressing objects: 100% (9/9), done. Writing objects: 100% (9/9), 1.20 KiB, done. Total 9 (delta 7), reused 0 (delta 0) To ssh://git.fedorahosted.org/git/389/ds.git 21c079e..1a194f0 389-ds-base-1.3.0 -> 389-ds-base-1.3.0 git push origin 389-ds-base-1.2.11 Counting objects: 17, done. Delta compression using up to 4 threads. Compressing objects: 100% (9/9), done. Writing objects: 100% (9/9), 1.28 KiB, done. Total 9 (delta 7), reused 0 (delta 0) To ssh://git.fedorahosted.org/git/389/ds.git 36425a3..a056542 389-ds-base-1.2.11 -> 389-ds-base-1.2.11
attachment ticket571_testcase.tar.gz
Test case for this ticket is added in ticket571_testcase.tar.gz
It provides a ldapcsdk testcase and a perl testcase. The ldapcsdk (makefile+search_empty_ctl.c) creates a openldap and mozldap version of the testcase. openldap can not reproduce the problem as it skips empty controls, but mozldap does not and sends the empty control
per script is an easy method to reproduce the problem
Backport in 1.3.1
git push origin 389-ds-base-1.3.1
Counting objects: 11, done. Delta compression using up to 4 threads. Compressing objects: 100% (6/6), done. Writing objects: 100% (6/6), 1.42 KiB, done. Total 6 (delta 4), reused 0 (delta 0) To ssh://git.fedorahosted.org/git/389/ds.git b143477..dea2a25 389-ds-base-1.3.1 -> 389-ds-base-1.3.1
git patch file (389-ds-base-1.3.1) -- covscan Defect type: COMPILER_WARNING 0002-Ticket-571-dup-47361-Empty-control-list-causes-LDAP-.patch
Reviewed by Rich (Thank you!!)
Pushed to master: 272bd14..383db4a master -> master commit 383db4a
Pushed to 389-ds-base-1.3.2: 5bf85e6..8b92149 389-ds-base-1.3.2 -> 389-ds-base-1.3.2 commit 8b92149
Pushed to 389-ds-base-1.3.2: 4f9ec32..86b76ef 389-ds-base-1.3.1 -> 389-ds-base-1.3.1 commit 86b76ef
Metadata Update from @nkinder: - Issue assigned to tbordaz - Issue set to the milestone: 1.3.1
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/571
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: Fixed)
Login to comment on this ticket.