openldap-bugs

openldap-bugs@openldap.org

1 participants
20963 discussions

Re: (ITS#6457) hiding remote attribute with rwm-map in relay context crashes server
by masarati＠aero.polimi.it 25 Jan '10

25 Jan '10

Guillaume.Rousse(a)inria.fr wrote: > Le 18/01/2010 17:13, masarati(a)aero.polimi.it a écrit : >> Could not reproduce. Apparently, it's something else that's creating >> hassle. Please provide a stack backtrace. > > Actually, it's an assertion failure un entry.c: > slapd: entry.c:483: entry_clean: Assertion `e->e_private == ((void *)0)' > failed. > Abandon > > Here the backtrace, but compilation optimisation may hinder its usability: Well, at least it shows where the failure is. However, since I can't reproduce it, I'll need your (sanitized) slapd.conf, a LDIF to load and the operation that causes the failure. p.

1 0

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

25 Jan '10

Howard Chu wrote: > 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. What I mean is that the TLS library may handle certificates that our function does not like (as in this case). Slapd's code, while skipping fields, checks their tags. We should do the same here, IMHO. p.

1 0

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

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