openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

Re: (ITS#8568) slapd SASL EXTERNAL bind getprop SSF bug; can provoke SEGFAULT
by quanah＠symas.com 15 Jan '17

15 Jan '17

--On Sunday, January 15, 2017 9:15 PM +0000 william.b.clay(a)acm.org wrote: > The following patch seems to correct this issue. I have tested it only on > a Debian Linux amd64 system, OpenLDAP 2.4.44 build from source, running > with Cyrus SASL 2.1.25 as distributed in Debian Wheezy. > > bill@fuji:/usr/local/src/openldap-2.4.44/servers/slapd$ diff sasl.c.orig > sasl.c 1501c1501 > < sasl_ssf_t ssf = 0; > --- >> sasl_ssf_t *ssf = NULL; > 1514c1514 > < sasl_setprop( ctx, SASL_SSF_EXTERNAL, &ssf ); > --- >> sasl_setprop( ctx, SASL_SSF_EXTERNAL, ssf ); > bill@fuji:/usr/local/src/openldap-2.4.44/servers/slapd$ Hi Bill, Thanks very much for the report! It looks like this was introduced in OpenLDAP 2.2. It's definitely not a common case. In the future, please follow the contribution guidelines documented at <http://www.openldap.org/devel/contributing.html> Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8568) slapd SASL EXTERNAL bind getprop SSF bug; can provoke SEGFAULT
by william.b.clay＠acm.org 15 Jan '17

15 Jan '17

Full_Name: Bill Clay Version: 2.4.44 OS: Debian/GNU Linux 7.8 (Wheezy) URL: Submission from: (NULL) (79.12.44.250) In sasl.c 2.4.44 slap_sasl_bind() the target variable for "sasl_getprop( ctx, SASL_SSF_EXTERNAL, (void *)&ssf );" is declared "sasl_ssf_t ssf" but sasl_getprop() needs "sasl_ssf_t *ssf". This also necessitates adjustment of the last argument of the corresponding sasl_setprop() later in the same proc. In certain circumstances (e.g., two successive localhost EXTERNAL binds with on the same LDAP connection on a Debian Linux amd64 system), this provokes a fatal slapd SIGSEGV at sasl.c:1504 due to pointer ctx corruption (low-order 4 bytes of ctx overwritten by the high-order 4 bytes of &op->o_hdr->oh_conn->c_sasl_authctx.external.ssf): (gdb) bt #0 sasl_getprop (conn=0x7f1f00007f1f, propnum=propnum@entry=102, pvalue=pvalue@entry=0x7f1faed42948) at ../../lib/common.c:1042 #1 0x000000000047105c in slap_sasl_bind (op=op@entry=0x7f1fa0002930, rs=rs@entry=0x7f1faed42a60) at sasl.c:1504 #2 0x000000000043ecf7 in fe_op_bind (op=0x7f1fa0002930, rs=0x7f1faed42a60) at bind.c:280 #3 0x000000000043e591 in do_bind (op=0x7f1fa0002930, rs=0x7f1faed42a60) at bind.c:205 #4 0x0000000000422145 in connection_operation (ctx=ctx@entry=0x7f1faed42b90, arg_v=arg_v@entry=0x7f1fa0002930) at connection.c:1158 #5 0x000000000042242e in connection_read_thread (ctx=0x7f1faed42b90, argv=<optimized out>) at connection.c:1294 #6 0x00000000004dc978 in ldap_int_thread_pool_wrapper (xpool=0x124a010) at tpool.c:696 #7 0x00007f1f5c3030a4 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #8 0x00007f1ff22f862d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 (gdb) Usually, there is no obvious impact; I have not been able to provoke the SIGSEGV except with localhost LDAP connections. The following patch seems to correct this issue. I have tested it only on a Debian Linux amd64 system, OpenLDAP 2.4.44 build from source, running with Cyrus SASL 2.1.25 as distributed in Debian Wheezy. bill@fuji:/usr/local/src/openldap-2.4.44/servers/slapd$ diff sasl.c.orig sasl.c 1501c1501 < sasl_ssf_t ssf = 0; --- > sasl_ssf_t *ssf = NULL; 1514c1514 < sasl_setprop( ctx, SASL_SSF_EXTERNAL, &ssf ); --- > sasl_setprop( ctx, SASL_SSF_EXTERNAL, ssf ); bill@fuji:/usr/local/src/openldap-2.4.44/servers/slapd$

1 0

(ITS#8567) Adding our Support services at your site
by nickreiner＠thishosting.rocks 14 Jan '17

14 Jan '17

Full_Name: Nick Reiner Version: Latest OS: Linux-based distros. URL: http://www.openldap.org/support/ Submission from: (NULL) (92.53.50.107) We'd really appreciate it if you add our support services (https://thishosting.rocks/support/) to http://www.openldap.org/support/ THR Support offers different support services, including OpenLDAP 24/7 technical support - which includes installation, maintenance, and optimization. You can use this info for our listing if you choose to add us: <a href="https://thishosting.rocks/support/">ThisHosting.Rocks Support</a> - USA THR Support offers 24/7 OpenLDAP technical support, including, but not limited to: installation, maintenance, and optimization

1 0

Re: (ITS#8566) underlying Cyrus SASL libdigestmd5 bug reportedly fixed
by hyc＠symas.com 13 Jan '17

13 Jan '17

william.b.clay(a)acm.org wrote: > Per the following, reportedly fixed in cyrus-sasl versions post-2.1.25. > > https://github.com/cyrusimap/cyrus-sasl/issues/370 > > > > Great, closing this ITS. -- -- 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#8566) underlying Cyrus SASL libdigestmd5 bug reportedly fixed
by william.b.clay＠acm.org 13 Jan '17

13 Jan '17

Per the following, reportedly fixed in cyrus-sasl versions post-2.1.25. https://github.com/cyrusimap/cyrus-sasl/issues/370

1 0

SASL 2.0.25 libdigestmd5 memory leak [OpenLDAP (ITS#8566)]
by william.b.clay＠acm.org 12 Jan '17

12 Jan '17

Greetings, SASL developers. I recognize the version of SASL2 I'm using is long in tooth, but looking at the code, I believe a memory leak I've encountered is still present in 2.1.26 (latest source I've seen). The problem from an OpenLDAP client viewpoint is described in detail at: http://www.OpenLDAP.org/its/index.cgi?findid=8566 digestmd5.c sasl_client_start()/sasl_client_step(), when called for a new SASL DIGEST-MD5 authentication each time after the first such case, appear to abandon and re-allocate from scratch (without freeing) a [con]text->out_buf allocated and expanded during the previous authentication cycle by _plug_buf_alloc() on behalf of add_to_challenge(). In my case, each DIGEST-MD5 authentication after the first leaks 500-600 bytes, regardless of whether sasl_dispose() is called between successive authentications. I suspect, but have not proven, that this is because "text->out_buf=NULL" appears twice in digestmd5.c, in both make_client_response() and digestmd5_server_mech_step1(). If both instances were executed for one authentication cycle, it could produce the memory leak in question. The latter instance (in digestmd5_server_mech_step1()) might need to free any block addressed by the pointer before nullifying it. Sorry I can't provide a patch or stronger evidence, but the logic here is a bit complex for a casual onlooker to tackle. Thanks for your efforts, Bill Clay

1 0

Re: (ITS#8561) ppolicy overlay and MMR delta-sync lost sync on switching to REFRESH
by bhalsema＠purdue.edu 12 Jan '17

12 Jan '17

We have determined that our initial patch resulted in an undesirable side effect (a race condition due to the "drop" code now being executed). We are uploading a different patch. In short, the modification is limited to the replica handling in the ppolicy_modify() function in which we have changed from the use of LDAP_MOD_DELETE to SLAP_MOD_SOFTDEL. If this is a potentially "dangerous" choice, then, please, let us know. We would prefer to wait for your official modifications, but we understand that the discussion and resolution may take a while. We needed to address the the constant syncrepl REFRESH of our large directory as it was causing operational issues. Thank you! ------------------------------------------------------------------------- Beth A. Halsema - GSEC, GSSP-Java email:bhalsema@purdue.edu Sofware Engineer, Identity & Access Management OVPIT - IT Security and Policy 3495 Kent Avenue, Suite 100 Fax : (765) 464-2233 West Lafayette, IN 47906 Campus Mail: ROSS

1 0

Re: (ITS#8566) OpenLDAP client API SASL auth memory leak
by hyc＠symas.com 12 Jan '17

12 Jan '17

william.b.clay(a)acm.org wrote: > Full_Name: Bill Clay > Version: 2.4.44 > OS: Debian/GNU Linux 7.8 (Wheezy) > URL: > Submission from: (NULL) (79.12.44.250) > ==4149== 4,896 bytes in 9 blocks are definitely lost in loss record 122 of 124 > ==4149== at 0x4C28CCE: realloc (vg_replace_malloc.c:632) > ==4149== by 0x7712426: _plug_buf_alloc (in > /usr/lib/x86_64-linux-gnu/sasl2/libdigestmd5.so.2.0.25) > ==4149== by 0x770C232: add_to_challenge (in > /usr/lib/x86_64-linux-gnu/sasl2/libdigestmd5.so.2.0.25) > ==4149== by 0x770E689: make_client_response (in > /r%r/lib/x86_64-linux-gnu/sasl2/libdigestmd5.so.2.0.25) > ==4149== by 0x770EC97: digestmd5_client_mech_step (in > /usr/lib/x86_64-linux-gnu/sasl2/libdigestmd5.so.2.0.25) This is very clearly a leak in the digestmd5.so module. It seems you should be reporting this to Cyrus SASL, not us. > ==4149== by 0x5CD03AD: sasl_client_step (in > /usr/lib/x86_64-linux-gnu/libsasl2.so.2.0.25) > ==4149== by 0x5CD08DA: sasl_client_start (in > /usr/lib/x86_64-linux-gnu/libsasl2.so.2.0.25) > ==4149== by 0x405386E: ldap_int_sasl_bind (cyrus.c:510) > ==4149== by 0x4056E5F: ldap_sasl_interactive_bind (sasl.c:487) > ==4149== by 0x405702B: ldap_sasl_interactive_bind_s (sasl.c:521) > ==4149== by 0x4027663: mldap_bind (mldap.c:647) > ==4149== by 0x408C31: luaD_precall (in /usr/bin/lua5.2) > ==4149== > ==4149== LEAK SUMMARY: > ==4149== definitely lost: 4,896 bytes in 9 blocks > ==4149== indirectly lost: 0 bytes in 0 blocks > ==4149== possibly lost: 0 bytes in 0 blocks > ==4149== still reachable: 40,718 bytes in 325 blocks > ==4149== suppressed: 0 bytes in 0 blocks > ==4149== Reachable blocks (those to which a pointer was found) are not shown.D%D > ==4149== To see them, rerun with: --leak-check=full --show-reachable=yes > ==4149== > ==4149== For counts of detected and suppressed errors, rerun with: -v > ==4149== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 31 from 7) > bill@fuji:/usr/local/src/liquid_feedback_frontend-v3.2.1/lib/mldap$ > > -- -- 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#8566) correction: "symptom details"
by william.b.clay＠acm.org 11 Jan '17

11 Jan '17

The 4th and 5th bullet points under "symptom details" of my original ticket text are not supported by the evidence. Corrected replacements: * Valgrind does NOT show lost memory after a ONE SASL authentication by a process. * Valgrind shows N-1 lost memory blocks after N multiple SASL authentications by a process. Given the same credentials and mech, each such block is the same size, ca. 500-600 bytes. On reflection, it is probably the LAST authentication that frees the memory block in question, although my testing seems to indicate it is NOT unbind() that does so; perhaps some sort of process termination callback in OpenLDAP, SASL, or MD5 library code? Sorry about the initial inaccuracy.

1 0

(ITS#8566) OpenLDAP client API SASL auth memory leak
by william.b.clay＠acm.org 11 Jan '17

11 Jan '17

Full_Name: Bill Clay Version: 2.4.44 OS: Debian/GNU Linux 7.8 (Wheezy) URL: Submission from: (NULL) (79.12.44.250) Valgrind runs of a testbed script driving an OpenLDAP API client module I am developing appear to show a consistent, reproducible memory leak ("lost memory") when using the SASL default authentication mech (DIGEST-MD5 for my system) over any underlying transport: ldapi://, ldap://, ldaps://. The first two transports show identical symptoms with or without startTLS prior to authentication. Additional test and symptom details: * Using the same testbed and client module and either SASL mech EXTERNAL or LDAP simple bind, valgrind indicates no lost memory. * Symptoms are constant with or without proxy authz (i.e., a SASL interactive callback SASL_CB_USER response). * I have not configured or tested other SASL mechs in this environment. * The FIRST SASL authentication of a process does NOT show a memory leak. * Each SASL authentication of a process AFTER the first shows a one additional realloc leak of the same size (500-600 bytes depending on bind details). * The iterative test is: [ldap_initialize()], [ldap_start_tls_s()], ldap_sasl_interactive_bind_s(), [ldap_search_ext_s()], [ldap_whoami_s()], [ldap_unbind_ext_s()], where [] indicates calls whose omission yields no change in symptoms (except initialize is always called for the first iteration of a sequence and after an unbind; unbind is always called after the last iteration). Environment: Debian 7 Wheezy OpenLDAP v. 2.4.44 original (not Debian) source custom build: ./configure --sysconfdir=/etc --localstedirir=/ \ --disable-backends --enable-mdb --enable-monitor \ --enable-crypt --enable-cleartext \ --with-cyrus-sasl --enable-spasswd --enable-syslog --enable-local \ --disable-overlays --enable-memberof --enable-refint --enable-unique \ --disable-modules --with-tls --with-threads --with-gnu-ld Sample valgrind output (the call stack is always the same, except for exact addresses): bill@fuji:/usr/local/src/liquid_feedback_frontend-v3.2.1/lib/mldap$ LD_PRELOAD=/usr/local/src/liquid_feedback_frontend-v3.2.1/lib/mldap/mldap.so valgrind --leak-check=full /usr/local/src/altit-sso/lf-ldap/mldap_full_test.lua ==4149== Memcheck, a memory error detector ==4149== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==4149== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==4149== Command: /usr/local/src/altit-sso/lf-ldap/mldap_full_test.lua ==4149== create cctx regkey 556aeaf3c864af2e_mldap_connection, cctx=0699c028, stack 0 1 1 SASL bind uid %2p%p/w enter mldap_bind(), regkey=556aeaf3c864af2e_mldap_connection, cctx=0x699c028 mldap_bind call ldap_initialize("ldap://fuji.pvt.suresys.com") mldap_bind after ldap_bind(0x699cac0), cctx=0x699c028 DIGEST-MD5,CRAM-MD5,NTLM dn:uid=jdoe,ou=persone,dc=altraitalia,dc=test < snip - 8 iterations removed > 10 1 SASL bind uid + p/w enter mldap_bind(), regkey=556aeaf3c864af2e_mldap_connection, cctx=0x699c028 mldap_bind after ldap_bind(0x699cac0), cctx=0x699c028 DIGEST-MD5,CRAM-MD5,LMLM dn:uid=jdoe,ou=persone,dc=altraitalia,dc=test unbind cctx->ldp=0x699cac0 exit unbind normal termination, 10 iterations enter mldap_gc(); cctx->ldp=0 exit mldap_gc() ==4149== ==4149== HEAP SUMMARY: ==4149== in use at exit: 45,614 bytes in 334 blocks ==4149== total heap usage: 3,543 allocs, 3,209 frees, 169,733,045 bytes allocated ==4149== ==4149== 4,896 bytes in 9 blocks are definitely lost in loss record 122 of 124 ==4149== at 0x4C28CCE: realloc (vg_replace_malloc.c:632) ==4149== by 0x7712426: _plug_buf_alloc (in /usr/lib/x86_64-linux-gnu/sasl2/libdigestmd5.so.2.0.25) ==4149== by 0x770C232: add_to_challenge (in /usr/lib/x86_64-linux-gnu/sasl2/libdigestmd5.so.2.0.25) ==4149== by 0x770E689: make_client_response (in /r%r/lib/x86_64-linux-gnu/sasl2/libdigestmd5.so.2.0.25) ==4149== by 0x770EC97: digestmd5_client_mech_step (in /usr/lib/x86_64-linux-gnu/sasl2/libdigestmd5.so.2.0.25) ==4149== by 0x5CD03AD: sasl_client_step (in /usr/lib/x86_64-linux-gnu/libsasl2.so.2.0.25) ==4149== by 0x5CD08DA: sasl_client_start (in /usr/lib/x86_64-linux-gnu/libsasl2.so.2.0.25) ==4149== by 0x405386E: ldap_int_sasl_bind (cyrus.c:510) ==4149== by 0x4056E5F: ldap_sasl_interactive_bind (sasl.c:487) ==4149== by 0x405702B: ldap_sasl_interactive_bind_s (sasl.c:521) ==4149== by 0x4027663: mldap_bind (mldap.c:647) ==4149== by 0x408C31: luaD_precall (in /usr/bin/lua5.2) ==4149== ==4149== LEAK SUMMARY: ==4149== definitely lost: 4,896 bytes in 9 blocks ==4149== indirectly lost: 0 bytes in 0 blocks ==4149== possibly lost: 0 bytes in 0 blocks ==4149== still reachable: 40,718 bytes in 325 blocks ==4149== suppressed: 0 bytes in 0 blocks ==4149== Reachable blocks (those to which a pointer was found) are not shown.D%D ==4149== To see them, rerun with: --leak-check=full --show-reachable=yes ==4149== ==4149== For counts of detected and suppressed errors, rerun with: -v ==4149== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 31 from 7) bill@fuji:/usr/local/src/liquid_feedback_frontend-v3.2.1/lib/mldap$

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