openldap-bugs

openldap-bugs@openldap.org

1 participants
20961 discussions

(ITS#5158) contrib should use separate config OID arc
by hyc＠OpenLDAP.org 29 Sep '07

29 Sep '07

Full_Name: Howard Chu Version: HEAD/RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (63.193.240.128) Submitted by: hyc Currently we track config OID allocations in slapd/bconfig.c for both core modules and contrib modules. Since we really aren't maintaining the contrib modules, they should use a separate OID arc and the OIDs should be tracked elsewhere. This has been changed in HEAD, and contrib/ConfigOIDs now exists for tracking OIDs allocated to contrib modules.

1 0

(ITS#5157) dynlist shouldn't populate values unless requested
by hyc＠OpenLDAP.org 29 Sep '07

29 Sep '07

Full_Name: Howard Chu Version: 2.4/HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (63.193.240.128) Submitted by: hyc Since populating the member list in a dynamic group may be a very expensive operation, the dynlist overlay should not perform this work if the member attribute wasn't requested in the search parameters. Already fixed in HEAD.

1 0

(ITS#5156) missing slapd.d man page
by gerard.ranke＠kmt.hku.nl 27 Sep '07

27 Sep '07

Full_Name: Gerard Ranke Version: 2.3.35, 2.3.38 OS: IRIX 6.5.30 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (192.87.216.230) Section 5.2 from the OpenLDAP Administrator's Guide mentions the slapd.d(5) man page. However, this seems to be missing from the distribution. Would it be possible to add it? Thanks for your time and effort. Best regards, Gerard Ranke

1 0

Re: (ITS#5114) pcache cache results for searches that hit size/timelimit
by rhafer＠suse.de 26 Sep '07

26 Sep '07

On Sonntag, 23. September 2007, ando(a)sys-net.it wrote: > Ralf Haferkamp wrote: > > Please note that test020 currently fails in HEAD sometime. I think this > > depends on the order in which the results for queries that hit the > > sizelimit are returned. > > I added tests for sizelimit that were consistent with my changes; > however, I'm now short of time to work on this, so feel free to back out > those test changes if you believe the code is working correctly, while > we design test improvements that are consistent with all fixes. I have rearranged the pcache test case a bit. It succeeds now on my test machine. -- Ralf

1 0

(ITS#5155) Leak in back-meta when binding as rootdn
by ando＠sys-net.it 26 Sep '07

26 Sep '07

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) back-meta leaks orb_edn after adding be_rootdn_bind() support (ITS#4962) p.

1 0

Re: (ITS#5121) IDL cache issue
by ando＠sys-net.it 26 Sep '07

26 Sep '07

Howard Chu wrote: > ando(a)sys-net.it wrote: >> To reproduce: >> >> - set idlcache >> >> - search one entry, so that the idl gets cached >> >> - delete that entry, so that the idl gets cleared - but head/tail don't >> >> - search another entry so that it gets cached - head/tail are corrupted >> >> I've a fix for this about to come (affects 2.4.5 as well, sigh; not sure >> about re23). > > Coverity shows this patch has introduced a NULL pointer dereference. > @@ -364,6 +381,9 @@ > ee = bdb->bi_idl_lru_tail; > for ( i = 0; i < 10; i++, ee = eprev ) { > eprev = ee->idl_lru_prev; > + if ( eprev == ee ) { > + eprev = NULL; > + } > if ( ee->idl_flags & CACHE_ENTRY_REFERENCED ) { > ee->idl_flags ^= CACHE_ENTRY_REFERENCED; > continue; > > What's the purpose of this change Make sure bi_idl_lru_tail gets set to NULL if purging the cache makes it empty. Perhaps it's an overshoot. > and should you be testing for a NULL > now in the for loop conditions? Yes, I realize I should test for ee != NULL in the for loop. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

RE: (ITS#5154) Sequential binds to back-meta cause assertion failiure
by mhardin＠symas.com 26 Sep '07

26 Sep '07

> -----Original Message----- > From: Pierangelo Masarati [mailto:ando@sys-net.it] > Sent: Wednesday, September 26, 2007 2:54 PM > To: mhardin(a)symas.com > Cc: openldap-its(a)openldap.org > Subject: Re: (ITS#5154) Sequential binds to back-meta cause assertion > failiure > > mhardin(a)symas.com wrote: > > Full_Name: Matthew Hardin > > Version: 2.3.38 > > OS: N/A > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (12.168.121.2) > > > > > > Multiple binds on the same connection where at least one bind ends up > being [...] > > /* FIXME: in some cases (e.g. unavailable) > > * do not assume it's not candidate; rather > > * mark this as an error to be eventually > > I think the "real" fix should be different: binds should always receive > a fresh connection from meta_back_getconn(), which shouldn't be put > into the cache at all. meta_back_bind() should cache them only in case > of success, otherwise they should be destroyed. This would allow to > remove the need to set a BINDING flag to guarantee connections used for > bind are not shared. I agree that would be a better fix. > In the meanwhile, the solution you propose should be just fine, as it > fills the hole occurring when a bind fails. > > I'll work at that ASAP. Thanks! -Matt Matthew Hardin Symas Corporation- The LDAP Guys http://www.symas.com

1 0

Re: (ITS#5121) IDL cache issue
by hyc＠symas.com 26 Sep '07

26 Sep '07

ando(a)sys-net.it wrote: > To reproduce: > > - set idlcache > > - search one entry, so that the idl gets cached > > - delete that entry, so that the idl gets cleared - but head/tail don't > > - search another entry so that it gets cached - head/tail are corrupted > > I've a fix for this about to come (affects 2.4.5 as well, sigh; not sure > about re23). Coverity shows this patch has introduced a NULL pointer dereference. @@ -364,6 +381,9 @@ ee = bdb->bi_idl_lru_tail; for ( i = 0; i < 10; i++, ee = eprev ) { eprev = ee->idl_lru_prev; + if ( eprev == ee ) { + eprev = NULL; + } if ( ee->idl_flags & CACHE_ENTRY_REFERENCED ) { ee->idl_flags ^= CACHE_ENTRY_REFERENCED; continue; What's the purpose of this change, and should you be testing for a NULL now in the for loop conditions? -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5154) Sequential binds to back-meta cause assertion failiure
by ando＠sys-net.it 26 Sep '07

26 Sep '07

mhardin(a)symas.com wrote: > Full_Name: Matthew Hardin > Version: 2.3.38 > OS: N/A > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (12.168.121.2) > > > Multiple binds on the same connection where at least one bind ends up being > passed through to a target and where the credentials for that bind are incorrect > will cause back-meta to throw an assertion failure during a subsequent bind. In > this situation back-meta prints the message "slapd: bind.c:229: meta_back_bind: > Assertion `tmpmc == mc' failed". > > Analysis: > In bind.c there is no cleanup of the metaconn structure after a failed bind to a > target database. This is ordinarily not a problem, as most applications perform > an unbind immediately after a failed bind and so fail to trigger this bug. > However, applications such as pam_ldap will perform several binds to as many as > two different identities on the same connection, and the credentials for one of > those identities are routinely incorrect. This bug causes the metaconn structure > from the failed bind to be left in the mi_conninfo.lai_tree avl tree and then > found during the re-insertion of a metaconn structure from a subsequent bind > (approx between lines 209-258 in bind.c), causing the assertion failure and > killing slapd in the process. > > Note: This bug can be exploited as a DOS attack, as the behavior is relatively > easy to reproduce on an unpatched system with a short perl script. > > > Proposed Fix: > The simplest and best fix appears to be to mark the metaconn struct from the > failed bind as tainted. This causes the struct to be deleted in the call to > meta_back_release_conn around line 281. > > The patch is as follows: > > bind.c > *************** > *** 189,194 **** > --- 189,198 ---- > > if ( lerr != LDAP_SUCCESS ) { > rc = rs->sr_err = lerr; > + /* Mark the meta_conn struct as tainted so > + * it'll be freed by meta_conn_back_destroy below */ > + LDAP_BACK_CONN_TAINTED_SET( mc ); > + > /* FIXME: in some cases (e.g. unavailable) > * do not assume it's not candidate; rather > * mark this as an error to be eventually I think the "real" fix should be different: binds should always receive a fresh connection from meta_back_getconn(), which shouldn't be put into the cache at all. meta_back_bind() should cache them only in case of success, otherwise they should be destroyed. This would allow to remove the need to set a BINDING flag to guarantee connections used for bind are not shared. In the meanwhile, the solution you propose should be just fine, as it fills the hole occurring when a bind fails. I'll work at that ASAP. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

(ITS#5154) Sequential binds to back-meta cause assertion failiure
by mhardin＠symas.com 26 Sep '07

26 Sep '07

Full_Name: Matthew Hardin Version: 2.3.38 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (12.168.121.2) Multiple binds on the same connection where at least one bind ends up being passed through to a target and where the credentials for that bind are incorrect will cause back-meta to throw an assertion failure during a subsequent bind. In this situation back-meta prints the message "slapd: bind.c:229: meta_back_bind: Assertion `tmpmc == mc' failed". Analysis: In bind.c there is no cleanup of the metaconn structure after a failed bind to a target database. This is ordinarily not a problem, as most applications perform an unbind immediately after a failed bind and so fail to trigger this bug. However, applications such as pam_ldap will perform several binds to as many as two different identities on the same connection, and the credentials for one of those identities are routinely incorrect. This bug causes the metaconn structure from the failed bind to be left in the mi_conninfo.lai_tree avl tree and then found during the re-insertion of a metaconn structure from a subsequent bind (approx between lines 209-258 in bind.c), causing the assertion failure and killing slapd in the process. Note: This bug can be exploited as a DOS attack, as the behavior is relatively easy to reproduce on an unpatched system with a short perl script. Proposed Fix: The simplest and best fix appears to be to mark the metaconn struct from the failed bind as tainted. This causes the struct to be deleted in the call to meta_back_release_conn around line 281. The patch is as follows: bind.c *************** *** 189,194 **** --- 189,198 ---- if ( lerr != LDAP_SUCCESS ) { rc = rs->sr_err = lerr; + /* Mark the meta_conn struct as tainted so + * it'll be freed by meta_conn_back_destroy below */ + LDAP_BACK_CONN_TAINTED_SET( mc ); + /* FIXME: in some cases (e.g. unavailable) * do not assume it's not candidate; rather * mark this as an error to be eventually

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