openldap-bugs August 2015

openldap-bugs@openldap.org

24 participants
69 discussions

(ITS#8218) segfault on sasl auth with malformed URI in config
by best＠univention.de 19 Aug '15

19 Aug '15

Full_Name: Version: 2.4.40-1 OS: debian / UCS 4.1 amd64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.198.197.8) A malformed URI in the sasl-regexp directive of slapd.conf caused a segfault of slapd. """ sasl-regexp uid=(.*),cn=saml,cn=auth ldap:///0.0.0.0:7389,389/"dc=dev,dc=local"??sub?uid=$1 """ The URI starts with 3 slashes after the scheme instead of 2 slashes. When doing authentication via SASL /usr/sbin/slapd segfaults. I think it is easy to reproduce. I can provide a core dump if needed. The backtrace: Thread 1 (Thread 0x7f933827c700 (LWP 18575)): #0 *__GI___li_freree (mem=0x20) at malloc.c:3709 #1 0x000000000044d08e in ava_free (op=0x1aa6ce0, ava=0x1aa8410, freeit=1) at ../../../../servers/slapd/ava.c:50 #2 0x00000000004354aa in filter_free_x (op=0x1aa6ce0, f=0x1aa8450, freeme=1) at ../../../%./servers/slapd/filter.c:531 #3 0x00000000004798a3 in slap_sasl2dn (opx=opx@entry=0x1aa6ce0, saslname=saslname@entry=0x7f933827b600, sasldn=sasldn@entry=0x7f933827b450, flags=flags@entry=2) at ../../../../servers/slapd/saslauthz.c:2018 #4 0x0000000000480c0f in slap_sasl_getdn (conn=<optimized out>, op=0x1aa6ce0, op@entry=0x0, id=id@entry=0x7f933827b610, user_realm=user_realm@entry=0x0, dn=dn@entry=0x7f933827b600, flags=2) at ../../../../servers/slapd/sasl.c:1884 #5 0x00000000004811a1 in slap_sasl_canonicalize (sconn=0x190a7e0, context=<optimized out>, in=0x1a864b0 "Administrator", inlen=13, flags=<optimized out>, user_realm=0x0, out=0x190b581 "", out_max=1024, out_len=0x190b06c) at ../../../../servers/slapd/sasl.c:656 #6 0x00007f93c16b2558 in _sasl_canon_user (conn=conn@entry=0x190a7e0, user=0x1a864b0 "Administrator", ulen=13, flags=flags@entry=3, oparams=oparams@entry=0x190b050) at ../../lib/canonusr.c:109 #7 0x00007f93c16b2870 in _sasl_canon_user_lookup (conn=0x190a7e0, user=<optimized out>, ulen=<optimized out>, flags=3, oparams=0x190b050) at ../../lib/canonusr.c:273 #8 0x00007f93bd46b936 in saml_server_mech_step (conn_context=0x1a2e8e0, params=0x190b9f0, clientin=0x1a55bea "", clientinlen=<optimized out>, serverout=<optimized out>, serveroutlen=<optimized out>, oparams=0x190b050) at cy2_saml.c:281 #9 0x00007f93c16be605 in sasl_server_step (serveroutlen=<optimized out>, serverout=0x7f933827b958, clientinlen=<optimized out>, clientin=<optimized out>, conn=0x190a7e0) at ../../lib/server.c:1614 #10 sasl_server_ste%2(conn=0x190a7e0, clientin=<optimized out>, clientinlen=<optimized out>, serverout=0x7f933827b958, serveroutlen=<optimized out>) at ../../lib/server.c:1585 #11 0x00007f93c16beb44 in sasl_server_start (conn=<optimized out>, mech=<optimized out>, clientin=0x1a55bea "", clientinlen=<optimized out>, serverout=serverout@entry=0x7f933827b958, serveroutlen=serveroutlen@entry=0x7f933827b938) at ../../lib/server.c:1529 #12 0x000000000048020e in slap_sasl_bind (op=op@entry=0x1aa6ce0, rs=rs@entry=0x7f933827ba60) at ../../../../servers/slapd/sasl.c:1512 #13 0x000000000044e217 in fe_op_bind (op=0x1aa6ce0, rs=0x7f933827ba60) at ../../../../servers/slapd/bind.c:280 #14 0x000000000044dab1 in do_bind (op=0x1aa6ce0, rs=0x7f933827ba60) at ../../../../servers/slapd/bind.c:205 #15 0x00000000004315d5 in connection_operation (ctx=ctx@entry=0x7f933827bba0, arg_v=arg_v@entry=0x1aa6ce0) at ../../../../servers/slapd/connection.c:1155 #16 0x00000000004318be in connection_read_thread (ctx=0x7f933827bba0, argv=<optimized out>) at ../../../../servers/slapd/connection.c:1291 #17 0x00007f93c22e4c33 in ldap_int_thread_pool_wrapper (xpool=0x1447450) at ../../../../libraries/libldap_r/tpool.c:688 #18 0x00007f93c03c3b50 in start_thread (arg=<optimized out>) at pthread_create.c:304 #19 0x00007f93c010d70d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #20 0x0000000000000000 in ?? () Some more context: (gdb) f 1 #1 0x000000000044d08e in ava_free (op=0x1aa6ce0, ava=0x1aa8410, freeit=1) at ../../../../servers/slapd/ava.c:50 50 op->o_tmpfree( ava->aa_value.bv_val, op->o_tmpmemctx ); (gdb) list 45 { 46 #ifdef LDAP_COMP_MATCH 47 if ( ava->aa_cf && ava->aa_cf->cf_ca->ca_comp_data.cd_mem_op ) 48 nibble_mem_free ( ava->aa_cf->cf_ca->ca_comp_data.cd_mem_op ); 49 #endif 50 op->o_tmpfree( ava->aa_value.bv_val, op->o_tmpmemctx ); 51 if ( ava->aa_desc->ad_flags & SLAP_DESC_TEMPORARY ) 52 op->o_tmpfree( ava->aa_desc, op->o_tmpmemctx ); 53 if ( freeit ) op->o_tmpfree( (char *) ava, op->o_tmpmemctx ); 54 } (gdb) up #2 0x00000000004354aa in filter_free_x (op=0x1aa6ce0, f=0x1aa8450, freeme=1) at ../../../../servers/slapd/filter.c:531 531 ava_free( op, f->f_ava, 1 ); (gdb) list 526 527 case LDAP_FILTER_EQUALITY: 528 case LDAP_FILTER_GE: 529 case LDAP_FILTER_LE: 530 case LDAP_FILTER_APPROX: 531 ava_free( op, f->f_ava, 1 ); 532 break; 533 534 case LDAP_FILTER_SUBSTRINGS: 535 if ( f->f_sub_initial.bv_val != NULL ) { (gdb) up #3 0x00000000004798a3 in slap_sasl2dn (opx=opx@entry=0x1aa6ce0, saslname=saslname@entry=0x7f933827b600, sasldn=sasldn@entry=0x7f933827b450, flags=flags@entry=2) at ../../../../servers/slapd/saslauthz.c:2018 2018 filter_free_x( opx, op.ors_filter, 1 ); (gdb) list 1313 } 2014 if( !BER_BVISNULL( &op.o_req_ndn ) ) { 2015 slap_sl_free( op.o_req_ndn.bv_val, opx->o_tmpmemctx ); 2016 } 2017 if( op.ors_filter ) { 2018 filter_free_x( opx, op.ors_filter! 1 ); 2019 } 2020 if( !BER_BVISNULL( &op.ors_filterstr ) ) { 2021 ch_free( op.ors_filterstr.bv_val ); 2022 } (gdb) up (gdb) up #4 0x0000000000480c0f in slap_sasl_getdn (conn=<optimized out>, op=0x1aa6ce0, op@entry=0x0, id=id@entry=0x7f933827b610, user_realm=user_realm@entry=0x0, dn=dn@entry=0x7f933827b600, flags=2) at ../../../../servers/slapd/sasl.c:1884 1884 slap_sasl2dn( op, dn, &dn2, flags ); (gdb) list 1879 } 1880 *dn = dn2; 1881 } 1882 1883 /* Run thru regexp */ 1884 slap_sasl2dn( op, dn, &dn2, flags ); 1885 if( !BER_BVISNULL( &dn2 ) ) { 1886 slap_sl_free( dn->bv_val, op->o_tmpmemctx ); 1887 *dn = dn2; 1888 Debug( LDAP_DEBUG_TRACE, (gdb) up #5 0x00000000004811a1 in slap_sasl_canonicalize (sconn=0x190a7e0, context=<optimized out>, in=0x1a864b0 "Administrator", inlen=13, flags=<optimized out>,seser_realm=0x0, out=0x190b581 "", out_max=1024, out_len=0x190b06c) at ../../../../servers/slapd/sasl.c:656 656 rc = slap_sasl_getdn( conn, NULL, &bvin, (char *)user_realm, &dn, (gdb) list 651 if ( !rc ) goto nene; 652 } 653 654 bvin.bv_val = (char *)in; 655 bvin.bv_len = inlen; 656 rc = slap_sasl_getdn( conn, NULL, &bvin, (char *)user_realm, &dn, 657 (flags & SASL_CU_AUTHID) ? SLAP_GETDN_AUTIDID : SLAP_GETDN_AUTHZID ); 658 if ( rc != LDAP_SUCCESS ) { 659 sasl_seterror( sconn, 0, ldap_err2string( rc ) ); 660 return SASL_NOAUTHZ; (gdb) up #6 0x00007f93c16b2558 in _sasl_canon_user (conn=conn@entry=0x190a7e0, user=0x1a864b0 "Administrator", ulen=13, flags=flags@entry=3, oparams=oparams@entry=0x190b050) at ../../lib/canonusr.c:109 109 ../../lib/canonusr.c: Datei oder Verzeichnis nicht gefunden. (gdb) list 104 result = _sasl_getcallback(conn, 105 SASL_CB_CANON_USER, 106 (sasl_callback_ft *)&cuser_cb, 107 &context); 108 if(result == SASL_OK && cuser_cb) { 109 result = cuser_cb(conn, 110 context, 111 user, 112 ulen, 113 flags, 114 (conn->type == SASL_CONN_SERVER ? 115 sconn->user_realm : 116 NULL), 117 user_buf, 118 CANON_BUF_SIZE, 119 lenp); (gdb) up #7 0x00007f93c16b2870 in _sasl_canon_user_lookup (conn=0x190a7e0, user=<optimized out>, ulen=<optimized out>, flags=3, oparams=0x190b050) at ../../lib/canonusr.c:273 271 int result; 272 273 result = _sasl_canon_user (conn, 274 user, 275 ulen, 276 flags, 277 oparams); (gdb) up #8 0x00007f93bd46b936 in saml_server_mech_step (conn_context=0x1a2e8e0, params=0x190b9f0, clientin=0x1a55bea "", clientinlen=<optimized out>, serverout=<optimized out>, serveroutlen=<optimized out>, oparams=0x190b050) at cy2_saml.c:281 281 if ((error = params->canon_user(params->utils->conn, userid, 0, (gdb) list 276 goto out; 277 if ((error = params->canon_user(params->utils->conn, userid, 0, 278 SASL_CU_AUTHID, oparams)) != SASL_OK) 279 goto out; 280 } else { 281 if ((error = params->canon_user(params->utils->conn, userid, 0, 282 SASL_CU_AUTHID|SASL_CU_AUTHZID, oparams)) != SASL_OK) 283 goto out; 284 } 285 Memory information: In frame1 ava->bv_val is not "Administrator" (the user I authenticated with) but the bv_len is 13. (gdb) print *ava $13 = {aa_desc = 0x1444650, aa_value = {bv_len = 13, bv_val = 0x20 <Address 0x20 out of bounds>}}

1 0

Re: (ITS#8111) Re-ordering schema attributeTypes crashes slapd
by zach＠puppetlabs.com 18 Aug '15

18 Aug '15

--cDyoBSpeMmeqjtIY Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 17, 2015 at 05:35:11PM -0700, Ryan Tandy wrote: >Hi Zach, > >I just pushed a patch for another ITS that reminded me of this one. > >Assuming you can still reproduce this, would you please try the patch=20 >mentioned at the end of http://www.openldap.org/its/?findid=3D8199 and=20 >let us know whether it resolves your crash? I've upgraded to 2.4.41.1 from the LTB packages an no longer have the=20 issue. --=20 Zach Leslie :: Puppet Labs --cDyoBSpeMmeqjtIY Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iQEcBAABCgAGBQJV02IGAAoJEH5UaJShK/iwqlwH/2Dc1xZor0I4of/4wWKN/o/y 73ZrwM/jsYsGez9jxU2t4gIhDfSBx38hqBFj801hGmF0Ef3xY8fDTlv7nEhXZ30J CEk2zQ4py0aBJG6kAe8sfZdmS8SPS6o2FzNoCR4w833oj11qYMIUbJLHzLsA6LWg STCcBapBIf0iHSfDBlwN3w93C5UXp71pWLAJEqcfSCtxhCCpAJr3WdndLjboN89c YVKl5NzDTmgInHmne4Ob+QFCN1nNw5z1uE2tkhV0FAw3QpVZsnDXIVW9Gjmr835c +UfQHqErY5PstxHY1V42h6CyX8IDby3rB5NuR31H/8uI0ToNaQry5EX40ZCvaa4= =BGFe -----END PGP SIGNATURE----- --cDyoBSpeMmeqjtIY--

1 0

(ITS#8173)
by Adrian.Raemy＠vtg.admin.ch 18 Aug '15

18 Aug '15

Dear Howard, The fix runs stable now over weeks.=20 slapd didn't crashed anymore. Thank you for the help. I guess we can close the ticket. Best Regards Adrian=20

1 0

Re: (ITS#8212) slapd stops on consumer node
by ryan＠openldap.org 14 Aug '15

14 Aug '15

Hi, I experimented with openldap 2.4.41 and the files you posted and did not experience any crashes. Please try to reduce the example setup as far as possible, until you find that the crash disappears after you disable a particular directive. Please also make sure you have the debugging symbols for slapd and libldap installed, and then try to provide a backtrace from gdb after triggering the crash, as well as the exact config files (and, if possible, relevant DIT contents, such as ppolicy configuration) that were in use at the time. Thanks for your help, Ryan

1 0

Re: (ITS#8185) Clarification/enhancement request: purging stale pwdFailureTime attributes
by subbarao＠computer.org 14 Aug '15

14 Aug '15

On 08/14/2015 10:38 AM, Howard Chu wrote: > subbarao(a)computer.org wrote: >> In the particular situation that's prompting this request, it's not just >> two or three values -- for one entry it was over 38000 values that had >> accumulated over time! (and generally high values for many other >> entries). > > If you have entries with tens of thousands of Bind failures being > recorded, you have a security monitoring problem. The limit applied by > the patch for this ITS will only mask the problem. The fact that your > security auditors haven't already noticed these tens of thousands of > Bind failures and stopped them at their source means you've got a > major vulnerability in your network security. Hi Howard, what's happening here is that an application account's password has expired, and its owners have neglected to change the password. Meanwhile, the old password remains hardcoded in the application, which continues to issue BIND requests that fail. The functionality of this particular application isn't mission-critical -- it may even be deprecated at this point by another application, so it's likely not a priority for the account owners given everything else on their plates. In this customer environment, the monitoring of password failures has historically been done outside of LDAP, and focuses on user accounts which tend to have higher privileges. LDAP application accounts (which tend to have minimal privileges) aren't treated the same. These bind failures may get cleaned up at some point during a periodic review of application accounts with expired passwords, but it's not likely to happen soon, given the lower level of risk/impact. Given that the bind failures themselves aren't causing a problem (the system as a whole has ample capacity), the only operations-impacting issue is the continually increasing entry size. So for this customer environment, I feel the best approach for now is to simply purge the stale failure timestamps (which I would prefer to do with a standard OpenLDAP configuration setting than with an external script). As I mentioned in an earlier message, I see the slapo-ppolicy man page as being friendly to this feature request: "Excess timestamps beyond those allowed by pwdMaxFailure may also be purged." From my perspective, it's a valuable hygienic feature for environments such as this one. Regards, -Kartik

1 0

Re: (ITS#8133) segfault at startup with memberof+dds
by ryan＠nardis.ca 14 Aug '15

14 Aug '15

Hi, On Wed, May 06, 2015 at 05:48:53PM +0000, alexoz66(a)gmail.com wrote: >When those two overlays are configured in this order: {0}memberof, {1}dds, slapd >will segfault at startup if dds finds a dynamicObject entry that is past its >expiration time. This does not occur if an object expires while slapd is >running, only during startup. A patch for this is in git master now. Please test it. http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=patch;h=1c4942413… thanks, Ryan

1 0

Re: (ITS#8185) Clarification/enhancement request: purging stale pwdFailureTime attributes
by hyc＠symas.com 14 Aug '15

14 Aug '15

subbarao(a)computer.org wrote: > In the particular situation that's prompting this request, it's not just > two or three values -- for one entry it was over 38000 values that had > accumulated over time! (and generally high values for many other entries). If you have entries with tens of thousands of Bind failures being recorded, you have a security monitoring problem. The limit applied by the patch for this ITS will only mask the problem. The fact that your security auditors haven't already noticed these tens of thousands of Bind failures and stopped them at their source means you've got a major vulnerability in your network security. -- -- 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

Re: (ITS#8185) Clarification/enhancement request: purging stale pwdFailureTime attributes
by hyc＠symas.com 14 Aug '15

14 Aug '15

subbarao(a)computer.org wrote: > On 07/06/2015 01:30 PM, Michael Ströder wrote: >> Consider that you are under on-going attack with many different >> accounts affected by the lockout treshold. Then you cannot simply wait >> for pwdFailureCountInterval seconds because your system is changing >> all the time. >> >> Such a situation is a real world scenario. > > Ok -- I'm probably not understanding enough about your particular > scenario to fully appreciate the concerns that you express. But I think > there could be ways to address them in this enhancement -- for instance, > by adding optional parameter(s) like ppolicy_purge_failures <nfailures> > and/or ppolicy_purge_olderthan <timestamp>, which could then be > configured to accommodate the scenario you describe. > > At this point, I'll think I'll leave it up to the OpenLDAP developers as > to how they want to proceed on this, and/or to ask for more information. I've added a pwdMaxRecordedFailure attribute to the policy schema. Overloading pwdMaxFailure would be a mistake. MaxRecordedFailure will default to MaxFailure if that is set. It defaults to 5 if nothing is set. There's no good reason to allow the timestamps to accumulate without bound. This is now available for testing 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/

1 0

(ITS#8217) Add msvc support to lmdb
by nacho.resa＠gmail.com 13 Aug '15

13 Aug '15

Full_Name: Ignacio Casal Quinteiro Version: OS: Windows 7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.30.165.68) On the url below you can find a fork that adds support for msvc builds: https://github.com/nice-software/lmdb/tree/wip/msvc https://github.com/nice-software/lmdb/commit/e871e736949dafee4e84f07c6cfb1b…

1 0

(ITS#8216) Windows 'make test' failures
by mhardin＠symas.com 11 Aug '15

11 Aug '15

Full_Name: Matthew Hardin Version: 2.4.40 OS: Windows 7/64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (69.43.206.100) Many 'make test' test fail, for a variety of reasons, with LMDB and BDB/HDB backends. OpenLDAP 2.4.40 Berkeley DB 4.8.30 Environment: MSYS from MinGW/MSYS 2013072300 Win-Builds MinGW 32- and 64-bit toolchain The following tests fail: test0-c-concurrency: problems reported by slapd-tester test039-glue-ldap-concurrency: seems to fail for the same reasons as test008 test043-delta-syncrepl: lmdb always fails, hdb/bdb sometimes test049-sync-config: config parsing problems test050-syncrepl-multimaster: config parsing problems test056-monitor: incorrect monitor output test058-syncrepl-asymmetric: parsing problems test059-slave-config: parsing problems test061-syncreplication-initiation: parsing prlelems test063-delta-multimaster: undetermined test064-constraint: include file processing (parsing?)

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs August 2015