Full_Name: Mattias Andersson Version: 2.4.25 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.182.107.220) I have configured a proxy server using both the relay backend and the translucent overlay: backend hdb backend relay database hdb directory /var/lib/ldap suffix "dc=foo,dc=example,dc=com" rootdn "cn=admin,dc=foo,dc=example,dc=com" rootpw secret index objectClass eq database relay suffix "dc=example,dc=com" overlay rwm rwm-suffixmassage "dc=foo,dc=example,dc=com" overlay translucent uri ldap://ldap.example.com This configuration makes it possible for me to override attributes in the remote ldap directory and at the same time extend the local directory with new entries. This has been tested and works for authorization in a linux environment. If I issue an LDAP search query, as follows, ldapsearch -x -b dc=chalmers,dc=se -s base "(objectClass=*)" 1.1 it will yield the following debug output: slapd starting conn=1000 fd=11 ACCEPT from IP=127.0.0.1:36838 (IP=0.0.0.0:389) conn=1000 op=0 BIND dn="" method=128 conn=1000 op=0 RESULT tag=97 err=0 text= conn=1000 op=1 SRCH base="dc=example,dc=com" scope=0 deref=0 filter="(objectClass=*)" conn=1000 op=1 SRCH attr=1.1 conn=1000 op=1: back-relay for DN="dc=example,dc=com" would call self. conn=1000 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= conn=1000 op=2 UNBIND conn=1000 fd=11 closed However, if I query the server using the Softerra LDAP Administrator software (Windows), the slapd daemon crashes with an assertion error: slapd starting conn=1000 fd=11 ACCEPT from IP=11.22.33.44:54752 (IP=0.0.0.0:389) conn=1000 op=0 BIND dn="" method=128 conn=1000 op=0 RESULT tag=97 err=0 text= conn=1000 op=1 SRCH base="dc=example,dc=com" scope=0 deref=0 filter="(objectClass=*)" conn=1000 op=1 SRCH attr=1.1 conn=1000 op=1: back-relay for DN="dc=example,dc=com" would call self. slapd: /build/buildd/openldap-2.4.25/servers/slapd/attr.c:236: attr_dup2: Assertion `j < i' failed. Aborted This is a security vulnerability, since it would be enough to send an LDAP query to take down the server. Mattias
mattias@centaurix.com wrote: > Full_Name: Mattias Andersson > Version: 2.4.25 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (83.182.107.220) Please provide a full gdb backtrace from the assertion failure. I've reproduced this configuration locally but see no crash using ldapsearch. I don't have the Softerra browser. > I have configured a proxy server using both the relay backend and the > translucent overlay: > > backend hdb > backend relay > > database hdb > directory /var/lib/ldap > suffix "dc=foo,dc=example,dc=com" > rootdn "cn=admin,dc=foo,dc=example,dc=com" > rootpw secret > index objectClass eq > > database relay > suffix "dc=example,dc=com" > overlay rwm > rwm-suffixmassage "dc=foo,dc=example,dc=com" > overlay translucent > uri ldap://ldap.example.com > > This configuration makes it possible for me to override attributes in the remote > ldap directory and at the same time extend the local directory with new entries. > This has been tested and works for authorization in a linux environment. > > If I issue an LDAP search query, as follows, > > ldapsearch -x -b dc=chalmers,dc=se -s base "(objectClass=*)" 1.1 > > it will yield the following debug output: > > slapd starting > conn=1000 fd=11 ACCEPT from IP=127.0.0.1:36838 (IP=0.0.0.0:389) > conn=1000 op=0 BIND dn="" method=128 > conn=1000 op=0 RESULT tag=97 err=0 text= > conn=1000 op=1 SRCH base="dc=example,dc=com" scope=0 deref=0 > filter="(objectClass=*)" > conn=1000 op=1 SRCH attr=1.1 > conn=1000 op=1: back-relay for DN="dc=example,dc=com" would call self. > conn=1000 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= > conn=1000 op=2 UNBIND > conn=1000 fd=11 closed > > However, if I query the server using the Softerra LDAP Administrator software > (Windows), the slapd daemon crashes with an assertion error: > > slapd starting > conn=1000 fd=11 ACCEPT from IP=11.22.33.44:54752 (IP=0.0.0.0:389) > conn=1000 op=0 BIND dn="" method=128 > conn=1000 op=0 RESULT tag=97 err=0 text= > conn=1000 op=1 SRCH base="dc=example,dc=com" scope=0 deref=0 > filter="(objectClass=*)" > conn=1000 op=1 SRCH attr=1.1 > conn=1000 op=1: back-relay for DN="dc=example,dc=com" would call self. > slapd: /build/buildd/openldap-2.4.25/servers/slapd/attr.c:236: attr_dup2: > Assertion `j< i' failed. > Aborted > > This is a security vulnerability, since it would be enough to send an LDAP query > to take down the server. We don't consider crashes/DOS to be a security vulnerability. A vulnerability is anything which allows users to see information they should not be allowed to see; in the case of a crash no information can be retrieved so all data is completely secure. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
On Tue, 31 Jan 2012 02:27:05 +0100, Howard Chu <hyc@symas.com> wrote: > mattias@centaurix.com wrote: >> Full_Name: Mattias Andersson >> Version: 2.4.25 >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (83.182.107.220) > > Please provide a full gdb backtrace from the assertion failure. I've > reproduced this configuration locally but see no crash using ldapsearch. > I don't have the Softerra browser. Ok, see attachment. The problem is not reproducible with ldapsearch. >> This is a security vulnerability, since it would be enough to send an >> LDAP query >> to take down the server. > > We don't consider crashes/DOS to be a security vulnerability. A > vulnerability is anything which allows users to see information they > should not be allowed to see; in the case of a crash no information can > be retrieved so all data is completely secure. You're right, but it's a service vulnerability -- the server must be online in order for our users to be able to log in. In any case, I have a different configuration now, that solves the problem in another way (by using two separate local databases -- one for the translucent overlay and one for the subordinate directory.) Another problem with the previous configuration was that I was getting "user modification of overlay database not permitted" errors when using ldapadd/ldapmodify (seems the translucent overlay can not be stacked with the rwm overlay.) Mattias
Mattias Andersson wrote: > On Tue, 31 Jan 2012 02:27:05 +0100, Howard Chu<hyc@symas.com> wrote: > >> mattias@centaurix.com wrote: >>> Full_Name: Mattias Andersson >>> Version: 2.4.25 >>> OS: Linux >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (83.182.107.220) >> >> Please provide a full gdb backtrace from the assertion failure. I've >> reproduced this configuration locally but see no crash using ldapsearch. >> I don't have the Softerra browser. > > Ok, see attachment. The problem is not reproducible with ldapsearch. The assertion leads me to believe that one of the values received from the remote server violated the attribute syntax, and so the value failed in the normalizer on the local slapd. What is the remote server? It's a bit strange that changing the configuration, but leaving the remote server unchanged, avoids the problem. > In any case, I have a different configuration now, that solves the problem > in another way (by using two separate local databases -- one for the > translucent overlay and one for the subordinate directory.) Another > problem with the previous configuration was that I was getting "user > modification of overlay database not permitted" errors when using > ldapadd/ldapmodify (seems the translucent overlay can not be stacked with > the rwm overlay.) > > Mattias -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Mattias Andersson wrote: > On Tue, 31 Jan 2012 02:27:05 +0100, Howard Chu<hyc@symas.com> wrote: > >> mattias@centaurix.com wrote: >>> Full_Name: Mattias Andersson >>> Version: 2.4.25 >>> OS: Linux >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (83.182.107.220) >> >> Please provide a full gdb backtrace from the assertion failure. I've >> reproduced this configuration locally but see no crash using ldapsearch. >> I don't have the Softerra browser. > > Ok, see attachment. The problem is not reproducible with ldapsearch. Please see if the attached patch alters the behavior. Thanks. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
On Tue, 31 Jan 2012 03:56:06 +0100, Howard Chu <hyc@symas.com> wrote: > Mattias Andersson wrote: >> On Tue, 31 Jan 2012 02:27:05 +0100, Howard Chu<hyc@symas.com> wrote: >> >>> Please provide a full gdb backtrace from the assertion failure. I've >>> reproduced this configuration locally but see no crash using >>> ldapsearch. >>> I don't have the Softerra browser. >> >> Ok, see attachment. The problem is not reproducible with ldapsearch. > > Please see if the attached patch alters the behavior. Thanks. I'm getting an error that MozNSS is not found when I run ./configure. Mattias
mattias@centaurix.com wrote: > On Tue, 31 Jan 2012 03:56:06 +0100, Howard Chu<hyc@symas.com> wrote: > >> Mattias Andersson wrote: >>> On Tue, 31 Jan 2012 02:27:05 +0100, Howard Chu<hyc@symas.com> wrote: >>> >>>> Please provide a full gdb backtrace from the assertion failure. I've >>>> reproduced this configuration locally but see no crash using >>>> ldapsearch. >>>> I don't have the Softerra browser. >>> >>> Ok, see attachment. The problem is not reproducible with ldapsearch. >> >> Please see if the attached patch alters the behavior. Thanks. > > I'm getting an error that MozNSS is not found when I run ./configure. Are you building the latest source? You can use --with-tls=openssl (or gnutls) to explicitly choose. But it shouldn't be defaulting to MozNSS, unless perhaps you're on a Redhat or Fedora system. If worse comes to worse, you can configure --without-tls just to run this test. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
changed state Open to Feedback
--On Tuesday, January 31, 2012 10:41 AM +0000 mattias@centaurix.com wrote: > On Tue, 31 Jan 2012 03:56:06 +0100, Howard Chu <hyc@symas.com> wrote: > >> Mattias Andersson wrote: >>> On Tue, 31 Jan 2012 02:27:05 +0100, Howard Chu<hyc@symas.com> wrote: >>> >>>> Please provide a full gdb backtrace from the assertion failure. I've >>>> reproduced this configuration locally but see no crash using >>>> ldapsearch. >>>> I don't have the Softerra browser. >>> >>> Ok, see attachment. The problem is not reproducible with ldapsearch. >> >> Please see if the attached patch alters the behavior. Thanks. > > I'm getting an error that MozNSS is not found when I run ./configure. > > Mattias Hi Mattias, Any update? We would like to get a fix for this into OpenLDAP 2.4.29 if possible. Thanks, Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
changed notes changed state Feedback to Test moved from Incoming to Software Bugs
changed notes changed state Test to Release
On Fri, 03 Feb 2012 20:26:01 +0100, Quanah Gibson-Mount <quanah@zimbra.com> wrote: > Hi Mattias, > > Any update? We would like to get a fix for this into OpenLDAP 2.4.29 if > possible. I'm having some problems with the BDB library: 4f2c4dd3 bdb_back_initialize: BDB library version mismatch: expected Berkeley DB 5.1.29: (October 25, 2011), got Berkeley DB 5.1.25: (January 28, 2011) I'll see if I can figure it out. Mattias
On Fri, 03 Feb 2012 22:24:36 +0100, Quanah Gibson-Mount <quanah@zimbra.com> wrote: > --On Friday, February 03, 2012 10:19 PM +0100 Mattias Andersson > <mattias@centaurix.com> wrote: > >> I'm having some problems with the BDB library: >> >> 4f2c4dd3 bdb_back_initialize: BDB library version mismatch: expected >> Berkeley DB 5.1.29: (October 25, 2011), got Berkeley DB 5.1.25: (January >> 28, 2011) > > You built against BDB 5.1.29, but you have BDB 5.1.25 installed. This > would definitely happen if one system was updated when the other was not. Actually I did install BDB 5.1.29, but probably I need to adjust some library path or change a symlink. Mattias
On Fri, 03 Feb 2012 20:26:01 +0100, Quanah Gibson-Mount <quanah@zimbra.com> wrote: > --On Tuesday, January 31, 2012 10:41 AM +0000 mattias@centaurix.com > wrote: > >> On Tue, 31 Jan 2012 03:56:06 +0100, Howard Chu <hyc@symas.com> wrote: >> >>> Mattias Andersson wrote: >>>> On Tue, 31 Jan 2012 02:27:05 +0100, Howard Chu<hyc@symas.com> wrote: >>>> >>>>> Please provide a full gdb backtrace from the assertion failure. I've >>>>> reproduced this configuration locally but see no crash using >>>>> ldapsearch. >>>>> I don't have the Softerra browser. >>>> >>>> Ok, see attachment. The problem is not reproducible with ldapsearch. >>> >>> Please see if the attached patch alters the behavior. Thanks. >> >> I'm getting an error that MozNSS is not found when I run ./configure. >> >> Mattias > > Hi Mattias, > > Any update? We would like to get a fix for this into OpenLDAP 2.4.29 if > possible. Ok, I didn't apply the patch yet, but now I'm getting a different error than before (before I was using OpenLDAP 2.4.25 from the Ubuntu package repository): cornelian build_unix # /usr/local/libexec/slapd -d 256 -f /etc/ldap/slapd.conf 4f2c5a69 @(#) $OpenLDAP: slapd 2.4.28 (Feb 1 2012 02:31:50) $ root@cornelian:/root/openldap/openldap-2.4.28/servers/slapd 4f2c5a69 hdb_db_open: database "dc=rss,dc=chalmers,dc=se": unclean shutdown detected; attempting recovery. 4f2c5a69 hdb_monitor_db_open: monitoring disabled; configure monitor database to enable 4f2c5a69 slapd starting 4f2c5ac2 conn=1000 fd=12 ACCEPT from IP=127.0.0.1:39354 (IP=0.0.0.0:389) 4f2c5ac2 conn=1000 op=0 BIND dn="" method=128 4f2c5ac2 conn=1000 op=0 RESULT tag=97 err=0 text= 4f2c5ac2 conn=1000 op=1 SRCH base="dc=chalmers,dc=se" scope=2 deref=0 filter="(objectClass=*)" 4f2c5ac2 conn=1000 op=1 SRCH attr=1.1 /usr/local/libexec/slapd: symbol lookup error: /usr/local/libexec/openldap/back_ldap-2.4.so.2: undefined symbol: ldap_get_message_ber This error also happens with ldapsearch. Mattias
--On Friday, February 03, 2012 11:15 PM +0100 Mattias Andersson <mattias@centaurix.com> wrote: > On Fri, 03 Feb 2012 20:26:01 +0100, Quanah Gibson-Mount > <quanah@zimbra.com> wrote: > >> --On Tuesday, January 31, 2012 10:41 AM +0000 mattias@centaurix.com >> wrote: >> >>> On Tue, 31 Jan 2012 03:56:06 +0100, Howard Chu <hyc@symas.com> wrote: >>> >>>> Mattias Andersson wrote: >>>>> On Tue, 31 Jan 2012 02:27:05 +0100, Howard Chu<hyc@symas.com> wrote: >>>>> >>>>>> Please provide a full gdb backtrace from the assertion failure. I've >>>>>> reproduced this configuration locally but see no crash using >>>>>> ldapsearch. >>>>>> I don't have the Softerra browser. >>>>> >>>>> Ok, see attachment. The problem is not reproducible with ldapsearch. >>>> >>>> Please see if the attached patch alters the behavior. Thanks. >>> >>> I'm getting an error that MozNSS is not found when I run ./configure. >>> >>> Mattias >> >> Hi Mattias, >> >> Any update? We would like to get a fix for this into OpenLDAP 2.4.29 if >> possible. > > Ok, I didn't apply the patch yet, but now I'm getting a different error > than before (before I was using OpenLDAP 2.4.25 from the Ubuntu package > repository): > > cornelian build_unix # /usr/local/libexec/slapd -d 256 -f > /etc/ldap/slapd.conf > 4f2c5a69 @(#) $OpenLDAP: slapd 2.4.28 (Feb 1 2012 02:31:50) $ Why are you running 2.4.28? I specifically said to download the current source from RE24, which at this time includes the patch for your issue. When you rebuild, you must replace all the openldap packages, including the OpenLDAP libraries, not just the slapd binary, etc. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
On Fri, 03 Feb 2012 23:32:30 +0100, Quanah Gibson-Mount <quanah@zimbra.com> wrote: > --On Friday, February 03, 2012 11:15 PM +0100 Mattias Andersson > <mattias@centaurix.com> wrote: > >> On Fri, 03 Feb 2012 20:26:01 +0100, Quanah Gibson-Mount >> <quanah@zimbra.com> wrote: >> >>> --On Tuesday, January 31, 2012 10:41 AM +0000 mattias@centaurix.com >>> wrote: >>> >>>> On Tue, 31 Jan 2012 03:56:06 +0100, Howard Chu <hyc@symas.com> wrote: >>>> >>>>> Mattias Andersson wrote: >>>>>> On Tue, 31 Jan 2012 02:27:05 +0100, Howard Chu<hyc@symas.com> >>>>>> wrote: >>>>>> >>>>>>> Please provide a full gdb backtrace from the assertion failure. >>>>>>> I've >>>>>>> reproduced this configuration locally but see no crash using >>>>>>> ldapsearch. >>>>>>> I don't have the Softerra browser. >>>>>> >>>>>> Ok, see attachment. The problem is not reproducible with ldapsearch. >>>>> >>>>> Please see if the attached patch alters the behavior. Thanks. >>>> >>>> I'm getting an error that MozNSS is not found when I run ./configure. >>>> >>>> Mattias >>> >>> Hi Mattias, >>> >>> Any update? We would like to get a fix for this into OpenLDAP 2.4.29 >>> if >>> possible. >> >> Ok, I didn't apply the patch yet, but now I'm getting a different error >> than before (before I was using OpenLDAP 2.4.25 from the Ubuntu package >> repository): >> >> cornelian build_unix # /usr/local/libexec/slapd -d 256 -f >> /etc/ldap/slapd.conf >> 4f2c5a69 @(#) $OpenLDAP: slapd 2.4.28 (Feb 1 2012 02:31:50) $ > > Why are you running 2.4.28? I specifically said to download the current > source from RE24, which at this time includes the patch for your issue. > When you rebuild, you must replace all the openldap packages, including > the OpenLDAP libraries, not just the slapd binary, etc. Ok, I downloaded the current source from RE24 (snapshot), but I'm still getting the error that I reported initially: cornelian openldap-ad04676 # /usr/local/libexec/slapd -d 256 -f /etc/ldap/slapd.conf 4f2c6fe0 @(#) $OpenLDAP: slapd 2.4.29 (Feb 4 2012 00:34:39) $ root@cornelian:/root/openldap/openldap-ad04676/servers/slapd 4f2c6fe0 hdb_monitor_db_open: monitoring disabled; configure monitor database to enable 4f2c6fe0 slapd starting 4f2c6fe7 conn=1000 fd=12 ACCEPT from IP=83.185.96.215:52240 (IP=0.0.0.0:389) 4f2c6fe7 conn=1000 op=0 BIND dn="" method=128 4f2c6fe7 conn=1000 op=0 RESULT tag=97 err=0 text= 4f2c6fe7 conn=1000 op=1 SRCH base="dc=chalmers,dc=se" scope=0 deref=0 filter="(objectClass=*)" 4f2c6fe7 conn=1000 op=1 SRCH attr=1.1 4f2c6fe7 conn=1000 op=1: back-relay for DN="dc=chalmers,dc=se" would call self. slapd: attr.c:236: attr_dup2: Assertion `j < i' failed. Aborted Mattias
On Sat, 04 Feb 2012 00:42:10 +0100, Mattias Andersson <mattias@centaurix.com> wrote: > On Fri, 03 Feb 2012 23:32:30 +0100, Quanah Gibson-Mount Ok, I downloaded > the current source from RE24 (snapshot), but I'm still getting the error > that I reported initially: I can confirm that the source does indeed include the patch, so the patch did not fix the problem. Mattias
--On Saturday, February 04, 2012 12:47 AM +0100 Mattias Andersson <mattias@centaurix.com> wrote: > On Sat, 04 Feb 2012 00:42:10 +0100, Mattias Andersson > <mattias@centaurix.com> wrote: > >> On Fri, 03 Feb 2012 23:32:30 +0100, Quanah Gibson-Mount Ok, I downloaded >> the current source from RE24 (snapshot), but I'm still getting the >> error that I reported initially: > > I can confirm that the source does indeed include the patch, so the patch > did not fix the problem. Thanks for the confirmation, unfortunate that patch didn't work. Investigation will continue. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
mattias@centaurix.com wrote: > On Sat, 04 Feb 2012 00:42:10 +0100, Mattias Andersson > <mattias@centaurix.com> wrote: > >> On Fri, 03 Feb 2012 23:32:30 +0100, Quanah Gibson-Mount Ok, I downloaded >> the current source from RE24 (snapshot), but I'm still getting the error >> that I reported initially: > > I can confirm that the source does indeed include the patch, so the patch > did not fix the problem. OK, we need to know exactly what the difference is between the ldapsearch query and the browser query. Can you please run slapd -d7 and record first the ldapsearch query and then the browser query and post the output for each of those? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
On Sat, 04 Feb 2012 01:59:49 +0100, Howard Chu <hyc@symas.com> wrote: > mattias@centaurix.com wrote: >> On Sat, 04 Feb 2012 00:42:10 +0100, Mattias Andersson >> <mattias@centaurix.com> wrote: >> >>> On Fri, 03 Feb 2012 23:32:30 +0100, Quanah Gibson-Mount Ok, I >>> downloaded >>> the current source from RE24 (snapshot), but I'm still getting the >>> error >>> that I reported initially: >> >> I can confirm that the source does indeed include the patch, so the >> patch >> did not fix the problem. > > OK, we need to know exactly what the difference is between the > ldapsearch query and the browser query. Can you please run slapd -d7 and > record first the ldapsearch query and then the browser query and post > the output for each of those? Attached the output from the two queries. Mattias
changed notes changed state Release to Closed
Mattias Andersson wrote: > On Sat, 04 Feb 2012 01:59:49 +0100, Howard Chu<hyc@symas.com> wrote: >> OK, we need to know exactly what the difference is between the >> ldapsearch query and the browser query. Can you please run slapd -d7 and >> record first the ldapsearch query and then the browser query and post >> the output for each of those? > > Attached the output from the two queries. Thanks. The difference is that the softerra browser was searching with attrsOnly set true, so all of the returned attributes had no values. Setting this option in ldapsearch allowed the issue to be reproduced. This is now fixed in git master. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
changed notes changed state Closed to Active
changed notes changed state Active to Test
fixed in master fixed in RE24