openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

Re: (ITS#6460) SASL EXTERNAL fails with long certificate serial numbers
by hyc＠symas.com 24 Jan '10

24 Jan '10

masarati(a)aero.polimi.it wrote: >> * masarati(a)aero.polimi.it [2010-01-24 16:01:23 +0100]: >>> Funny enough, the same thing is dealt with correctly in certificate >>> validation/normalization in slapd/schema_init.c >> >> That was a result of ITS#5070 (which you filed). > > right :) > >> Maybe there is an >> opportunity for refactoring, but I wouldn't be a good judge of that. > > I don't quite bother about refactoring to minimize code duplication. > Rather, I think the libldap function x509_cert_get_dn() should first > validate the certificate, much like slapd's certificateValidate() does. Since the cert was obtained thru a TLS handshake, we assume it has already been validated by the TLS library. Further validation is not needed. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#6461) back-sql quote characters in query
by tolich.arz＠gmail.com 24 Jan '10

24 Jan '10

Full_Name: Anatoly Version: 2.4.19 OS: GNU/Linux URL: Submission from: (NULL) (89.169.85.181) I'm using openldap 2.4.19 with sql backend. I have a troubles with queries that contains single-quote ( ' ) character. For example, if I searching for (cn=Zool'man): <==backsql_srch_query() returns SELECT DISTINCT ldap_entries.id,phpbb_users.user_id,varchar_ci('phpbbUser') AS objectClass,ldap_entries.dn AS dn FROM ldap_entries,phpbb_users WHERE phpbb_users.user_id=ldap_entries.keyval AND ldap_entries.oc_map_id=? AND 9=9 AND (varchar_ci(phpbb_users.username)='ZOOL'MAN') Constructed query: SELECT DISTINCT ldap_entries.id,phpbb_users.user_id,varchar_ci('phpbbUser') AS objectClass,ldap_entries.dn AS dn FROM ldap_entries,phpbb_users WHERE phpbb_users.user_id=ldap_entries.keyval AND ldap_entries.oc_map_id=? AND 9=9 AND (varchar_ci(phpbb_users.username)='ZOOL'MAN') id: '2' backsql_oc_get_candidates(): error executing query Return code: -1 nativeErrCode=7 SQLengineState=S1000 msg="[unixODBC]ERROR: syntax error at or near "MAN" at character 271; In this case query should be like varchar_ci(phpbb_users.username)='ZOOL\'MAN' instead of 'ZOOL'MAN' Additionally, I fear this opens a possibility of sql injection, depending on RDBMS.

1 0

Re: (ITS#6460) SASL EXTERNAL fails with long certificate serial numbers
by Sergio.Gelato＠astro.su.se 24 Jan '10

24 Jan '10

* masarati(a)aero.polimi.it [2010-01-24 19:14:02 +0100]: > I'm applying the fix, please test. I'm in production with the fix (on 2.4.11; I don't have the time to deploy HEAD right now). syncrepl (which is what I'm using SASL EXTERNAL for) now works again. As for the need to validate the certificate: shouldn't this have been taken care of during the preceding TLS handshake?

1 0

Re: (ITS#6460) SASL EXTERNAL fails with long certificate serial numbers
by masarati＠aero.polimi.it 24 Jan '10

24 Jan '10

> * masarati(a)aero.polimi.it [2010-01-24 16:01:23 +0100]: >> Funny enough, the same thing is dealt with correctly in certificate >> validation/normalization in slapd/schema_init.c > > That was a result of ITS#5070 (which you filed). right :) > Maybe there is an > opportunity for refactoring, but I wouldn't be a good judge of that. I don't quite bother about refactoring to minimize code duplication. Rather, I think the libldap function x509_cert_get_dn() should first validate the certificate, much like slapd's certificateValidate() does. I'm applying the fix, please test. p.

1 0

Re: (ITS#6460) SASL EXTERNAL fails with long certificate serial numbers
by Sergio.Gelato＠astro.su.se 24 Jan '10

24 Jan '10

* masarati(a)aero.polimi.it [2010-01-24 16:01:23 +0100]: > Funny enough, the same thing is dealt with correctly in certificate > validation/normalization in slapd/schema_init.c That was a result of ITS#5070 (which you filed). Maybe there is an opportunity for refactoring, but I wouldn't be a good judge of that.

1 0

Re: (ITS#6460) SASL EXTERNAL fails with long certificate serial numbers
by masarati＠aero.polimi.it 24 Jan '10

24 Jan '10

> Full_Name: Sergio Gelato > Version: 2.4.11 (problem also in HEAD) > OS: Debian GNU/Linux > URL: > Submission from: (NULL) (85.225.123.197) > > > Using (X.509 certificate-based) SASL EXTERNAL authentication fails when > the > serial number of the certificate is longer than 4 octets. > > I have traced the problem to the use, by > libraries/libldap/tls.c:x509_cert_get_dn(), > of ber_get_int() to consume the serial number. This fails when the value > to be > decoded > doesn't fit in a ber_int_t. > > I discovered this bug with Debian's OpenLDAP 2.4.11-1+lenny1 but a look at > the > OpenLDAP CVS indicates that the problem is still present in the current > HEAD > (1.167). > > I've successfully tested the following patch: > ==================================================================================== > RFC5280 §4.1.2.2 says "[c]ertificate users MUST be able to handle > serialNumber > values up to 20 octets". ber_get_int() fails beyond 4 octets. Since we > don't > actually care about the certificate serial number, let's just skip it. > > --- a/libraries/libldap/tls.c > +++ b/libraries/libldap/tls.c > @@ -1673,7 +1673,8 @@ > tag = ber_skip_tag( ber, &len ); /* Context + Constructed (version) */ > if ( tag == 0xa0 ) /* Version is optional */ > tag = ber_get_int( ber, &i ); /* Int: Version */ > - tag = ber_get_int( ber, &i ); /* Int: Serial */ > + tag = ber_skip_tag( ber, &len ); /* *Big* integer: Serial */ > + ber_skip_data( ber, len ); > tag = ber_skip_tag( ber, &len ); /* Sequence: Signature */ > ber_skip_data( ber, len ); > if ( !get_subject ) { Funny enough, the same thing is dealt with correctly in certificate validation/normalization in slapd/schema_init.c p.

1 0

(ITS#6460) SASL EXTERNAL fails with long certificate serial numbers
by Sergio.Gelato＠astro.su.se 23 Jan '10

23 Jan '10

Full_Name: Sergio Gelato Version: 2.4.11 (problem also in HEAD) OS: Debian GNU/Linux URL: Submission from: (NULL) (85.225.123.197) Using (X.509 certificate-based) SASL EXTERNAL authentication fails when the serial number of the certificate is longer than 4 octets. I have traced the problem to the use, by libraries/libldap/tls.c:x509_cert_get_dn(), of ber_get_int() to consume the serial number. This fails when the value to be decoded doesn't fit in a ber_int_t. I discovered this bug with Debian's OpenLDAP 2.4.11-1+lenny1 but a look at the OpenLDAP CVS indicates that the problem is still present in the current HEAD (1.167). I've successfully tested the following patch: ==================================================================================== RFC5280 §4.1.2.2 says "[c]ertificate users MUST be able to handle serialNumber values up to 20 octets". ber_get_int() fails beyond 4 octets. Since we don't actually care about the certificate serial number, let's just skip it. --- a/libraries/libldap/tls.c +++ b/libraries/libldap/tls.c @@ -1673,7 +1673,8 @@ tag = ber_skip_tag( ber, &len ); /* Context + Constructed (version) */ if ( tag == 0xa0 ) /* Version is optional */ tag = ber_get_int( ber, &i ); /* Int: Version */ - tag = ber_get_int( ber, &i ); /* Int: Serial */ + tag = ber_skip_tag( ber, &len ); /* *Big* integer: Serial */ + ber_skip_data( ber, len ); tag = ber_skip_tag( ber, &len ); /* Sequence: Signature */ ber_skip_data( ber, len ); if ( !get_subject ) {

1 0

Re: (ITS#6364) refint needs to have rootdn set
by apm＠mutex.dk 22 Jan '10

22 Jan '10

This may be related. I've veryfied that my refint overlay is not working. However I have a rootdn defined for the database, but it is set to cn=config. Could it be that the rootdn has to be in the scope of the database for refint to work? slapd 2.4.20, back-hdb, BerkeleyDB 4.8.24 /Peter

1 0

(ITS#6459) memory leak in syncprov
by rhafer＠suse.de 21 Jan '10

21 Jan '10

Full_Name: Ralf Haferkamp Version: HEAD, RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (92.252.21.216) When sending SYNC_NEW_COOKIE intermedia results syncprov_qplay() does not free the entry from the syncres structure. A fix is on the way...

1 0

(ITS#6458) syncrepl fails if attribute has no equalty maching rule
by pcernko+openldap＠mpi-sws.org 20 Jan '10

20 Jan '10

Full_Name: Patrick Cernko Version: 2.4.21 OS: Linux URL: http://www.mpi-inf.mpg.de/~pcernko/syncrepl_fails_if_attribute_has_no_equal… Submission from: (NULL) (139.19.3.67) Hi OpenLDAP-Programmers, although some related bug reports were posted in the past years, this issue still seems not to be fixed: OpenLDAP's syncrepl replication fails if it comes to removing one of a multi-value attribes of an object if this attribute does not have a equality matching rule defined in the schema. Modification works on the master server but fails to replicate to the slave(s) leaving them with the dit version just before and not replicating any other changes any more. I compiled a small example how to reproduce the problem with the (maybe "well-known") nisNetgroupTriple attribute from nis.schema as shipped with openldap-2.4.21: - extract the files from http://www.mpi-inf.mpg.de/~pcernko/syncrepl_fails_if_attribute_has_no_equal… into an empty working directory - download the tarball to that working dir and configure similar to the just extracted configure.sh - build and install it to get an install subdir in the working dir - start the master using sh master.sh in the working dir This will create the "master" database in your working dir, slapadd the dit.ldif and start a master slapd with a unix socket /tmp/master. - start the slave using sh slave.sh This will create "slave" database in your working dir and start the slave slapd with a unix socket /tmp/slave which will immediately start syncing from the running master - if you want you can search the 2 servers with install/bin/ldapsearch -H ldapi://%2ftmp%2fmaster/ -b ou=openldap -LLL resp. install/bin/ldapsearch -H ldapi://%2ftmp%2fslave/ -b ou=openldap -LLL - use "python mod.py" to remove one of the nisNetgroupTriple attributes from the netgroup object - you will see a debug message from the slave server like this: bdb_modify_internal: delete nisNetgroupTriple bdb_modify_internal: 18 modify/delete: nisNetgroupTriple: no equality matching rule send_ldap_result: err=18 matched="" text="modify/delete: nisNetgroupTriple: no equality matching rule" null_callback : error code 0x12 slap_graduate_commit_csn: removing 0x29931c0 20100120124712.028626Z#000000#000#000000 syncrepl_entry: rid=001 be_modify cn=netgroup,ou=openldap (18) syncrepl_entry: rid=001 be_modify failed (18) if not, use "python mod.py add" to re-add the removed nisNetgroupTriple and try again. Sometimes, it seems to work (race condition?). - you can also verify the difference with: install/bin/ldapsearch -H ldapi://%2ftmp%2fmaster/ -b ou=openldap -LLL cn=netgroup install/bin/ldapsearch -H ldapi://%2ftmp%2fslave/ -b ou=openldap -LLL cn=netgroup - from now on, the slave will fail to sync any succeeding changes, as it continuously tries to sync the modification above first. :-( Now, obviously having an attribute without equality matching rule is not a good idea in the first place. However, the (official?) nis.schema comes with such an attribute which we must use like this (e.g. we would have to patch the Solaris kernel to change it for the Solaris NFS server). It is possible to modify a nisNetgroup object like this: according to the debugging output, I guess the master removes simply ALL nisNetgroupTriple attributes and adds only the attributes that should remain. When the corresponding syncrepl_entry is handled by the slave, it seems the it in contrast tries to really only remove the 2-be-removed attribute which does not work as it cannot identify the right one due to a missing eq-match operator. I suggest the best way to solve this issue is to try to get syncrepl do exactly the same actions (not resulting changes) as the server does.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs