(ITS#8218) segfault on sasl auth with malformed URI in config
by best＠univention.de
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>}}
8 years, 1 month
Re: (ITS#8111) Re-ordering schema attributeTypes crashes slapd
by zach＠puppetlabs.com
--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--
8 years, 1 month
(ITS#8173)
by Adrian.Raemy＠vtg.admin.ch
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
8 years, 1 month
Re: (ITS#8212) slapd stops on consumer node
by ryan＠openldap.org
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
8 years, 1 month
Re: (ITS#8185) Clarification/enhancement request: purging stale pwdFailureTime attributes
by subbarao＠computer.org
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
8 years, 1 month
Re: (ITS#8185) Clarification/enhancement request: purging stale pwdFailureTime attributes
by hyc＠symas.com
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/
8 years, 1 month
Re: (ITS#8185) Clarification/enhancement request: purging stale pwdFailureTime attributes
by hyc＠symas.com
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/
8 years, 1 month
(ITS#8216) Windows 'make test' failures
by mhardin＠symas.com
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?)
8 years, 1 month
