#571 server does not accept 0 length LDAP Control sequence
Closed: wontfix None Opened 11 years ago by rmeggins.

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

  • I reproduced the different behavior with openldap (openldap-devel-2.4.33) vs mozldap (mozldap-6.0.5)
    [[BR]]
    Sending a null length known control, the operation was successfully processed with openldap
    [[BR]]

{{{
[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 ==

  • Continue investigations

Here are the next steps

  • Checks done by openldap while encoding the control prevents openldap to send NULL control. This is not done by mozldap and so it is rejected at the server level

Here are the next steps

  • need to discuss what should be done next

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.

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

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

7 years ago

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.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Fixed)

3 years ago

Login to comment on this ticket.

Metadata