openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

Re: (ITS#8957)
by quanah＠symas.com 29 Jan '19

29 Jan '19

--On Tuesday, January 29, 2019 4:51 PM +0000 vsmith(a)interlinknetworks.com wrote: > --- openldap-2.4.47/libraries/libldap/open.c?????? 2018-12-19 > 10:57:06.000000000 -0500 > +++ openldap-2.4.47.mod/libraries/libldap/open.c?????? 2019-01-26 > 18:24:48.000000000 -0500 > @@ -440,7 +440,7 @@ > ??#endif > > ??#ifdef HAVE_TLS > -?????? if (rc == 0 && ( ld->ld_options.ldo_tls_mode == > LDAP_OPT_X_TLS_HARD || +?????? if ((rc == 0 || rc == -2) && ( > ld->ld_options.ldo_tls_mode == LDAP_OPT_X_TLS_HARD || > ???????? ?????? strcmp( srv->lud_scheme, "ldaps" ) == 0 )) > ???????? { > ???????? ?????? ++conn->lconn_refcnt;?????? /* avoid premature free */ This is not a valid patch. I don't know if it's your email client that is destroying the patch? I suggest uploading it to the FTP site and responding with the link to the file. Thanks, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8957)
by vsmith＠interlinknetworks.com 29 Jan '19

29 Jan '19

I reviewed some of the initial discussion about this same issue which lead to this fix in version 2.4.26, "Fixed libldap ASYNC TLS setup (ITS#6828)", and looked at the code that Ian Puleston suggested should be fixed in ldap_int_open_connection. This routine does have the code to do what was need for TSL to work but was not called since it received an error code of -2 not 0. The -2 simply indicated that this was an asynchronous call. I changed the test to call the TSL setup if the return code was either 0 or -2. This fixes my issue. Here is my patch. --- openldap-2.4.47/libraries/libldap/open.c 2018-12-19 10:57:06.000000000 -0500 +++ openldap-2.4.47.mod/libraries/libldap/open.c 2019-01-26 18:24:48.000000000 -0500 @@ -440,7 +440,7 @@ #endif #ifdef HAVE_TLS - if (rc == 0 && ( ld->ld_options.ldo_tls_mode == LDAP_OPT_X_TLS_HARD || + if ((rc == 0 || rc == -2) && ( ld->ld_options.ldo_tls_mode == LDAP_OPT_X_TLS_HARD || strcmp( srv->lud_scheme, "ldaps" ) == 0 )) { ++conn->lconn_refcnt; /* avoid premature free */ Thanks, Vernon

1 0

(ITS#8965) ldap proxy segmentation fault
by praveen.adini＠fireeye.com 29 Jan '19

29 Jan '19

Full_Name: Praveen Adini Version: 2.4.47-r2 OS: Alpine Containers URL: Submission from: (NULL) (209.135.212.252) I'm trying to setup a openldap proxy wherein the proxy denies any search requests for uid=root. When i tried using the rwm overlay to stop the operation(#), i'm getting a segmentation fault although i see the unwilling to perform operation 53 message being printed. here is the snippet of the conf that i'm using. overlay rwm rwm-rewriteEngine on rwm-rewriteContext searchFilter rwm-rewriteRule "(.*)(uid=root)(.*)" "$1$2$3" "#"

1 0

Re: (ITS#8957)
by quanah＠symas.com 29 Jan '19

29 Jan '19

Hi, Please read: <https://www.openldap.org/devel/contributing.html> and re-submit the patch accordingly. Please do not use HTML email. Thanks! --On Tuesday, January 29, 2019 6:05 AM +0000 vsmith(a)interlinknetworks.com wrote: > <html> > <head> > > <meta http-equiv="content-type" content="text/html; charset=UTF-8"> > </head> > <body text="#000000" bgcolor="#FFFFFF"> > I reviewed some of the initial discussion > about this same issue which lead to this fix in version 2.4.26, > "Fixed libldap ASYNC TLS setup (ITS#6828)", and looked at > the code that Ian Puleston suggested should be fixed in > ldap_int_open_connection. This routine does have the code to do > what was need for TSL to work but was not called since it received > an error code of -2 not 0. The -2 simply indicated that this was > an asynchronous call. I changed the test to call the TSL setup if > the return code was either 0 or -2. This fixes my issue. Here is > my patch. > --- openldap-2.4.47/libraries/libldap/open.c?????? 2018-12-19 > 10:57:06.000000000 -0500 > +++ openldap-2.4.47.mod/libraries/libldap/open.c?????? 2019-01-26 > 18:24:48.000000000 -0500 > @@ -440,7 +440,7 @@ > ??#endif > ?? > ??#ifdef HAVE_TLS > -?????? if (rc == 0 && ( ld->ld_options.ldo_tls_mode == > LDAP_OPT_X_TLS_HARD || > +?????? if ((rc == 0 || rc == -2) && ( > ld->ld_options.ldo_tls_mode == LDAP_OPT_X_TLS_HARD || > ???????? ?????? strcmp( srv->lud_scheme, "ldaps" ) == 0 )) > ???????? { > ???????? ?????? ++conn->lconn_refcnt;?????? /* avoid premature > free */ > Thanks, > Vern > > </body> > </html> > > > -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8964) ldap proxy segmentation fault
by praveen.adini＠fireeye.com 29 Jan '19

29 Jan '19

1 0

(ITS#8963) Start TLS failed errors on back-ldap binds / short timeout, config option request
by janne.peltonen＠helsinki.fi 29 Jan '19

29 Jan '19

Full_Name: Janne Peltonen Version: 2.4.44 OS: Red Hat Enterprise Linux 7 URL: https://www.openldap.org/lists/openldap-technical/201901/msg00038.html Submission from: (NULL) (2001:708:110:1820:3664:a9ff:fe04:7363) Proxied BINDs on back-ldap sometimes create Start TLS failed errors on the connection from proxy to backend, and the client of the proxy receives the error 52. We had a look at the code, and it appears that in back-ldap/bind.c, the timeout argument of the function ldap_back_start_tls always ends up as zero, so the timeout tv.sec and tv.usec end up being set as 0 and 100000, respectively, by the macro LDAP_BACK_TV_SET defined in back-ldap/back-ldap.h. This means that the actual timeout waiting for starttls operation to complete will be 0.1 seconds, which is sometimes too little if there are latencies. We did a quick&dirty hack to just set tv.sec to 3 and tv.usec to 0, and were no longer able to get any Start TLS failed errors on the proxy bind. We did find that the back-ldap has an "extended" timeout defined in back-ldap/config.c - except that is commented out as "not implemented". Seems to us that if that were implemented, you could set the timeout in your ldap database section by something like "timeout extended=" and then you could have a longer timeout. Steps to reproduce: 1. Configure an openldap proxy-backend pair, the proxy using the "ldap" database and using ldap urls to connect to the backend (using ldaps urls might actually be a workaround). Configure the binds to be proxied to the backend, too. 2. Create a script that creates multiple - say, 200 - simultaneous connections to the proxy, using an ldaps url to connect to the proxy, and using the same DN to bind as. (We haven't tried to connect to the frontend using ldap+starttls, but I would suppose that would have a similar result, since the client establishes TLS anyway before trying to bind to the proxy.) 3. Observe some of the binds fail (we typically get 5-6 fails for 200 simultaneous connection), with the client of the proxy getting a "Server is unavailable: 52" type of error, and the proxy log containing lines such as "conn=7716 op=0 RESULT tag=97 err=52 text=Start TLS failed" after the BIND from the client. Possible workaround: Configure the proxy to use ldaps urls to the backend. Suggested fix: Implement the "extended" timeout type in back-ldap/config.c timeout_table, so that people can set the StartTLS timeout to a larger value than the default 0.1 seconds. References: discussion thread on the OpenLDAP-Technical mailing list.

1 0

(ITS#8957)
by vsmith＠interlinknetworks.com 29 Jan '19

29 Jan '19

<html> <head> <meta http-equiv="content-type" content="text/html; charset=UTF-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> I reviewed some of the initial discussion about this same issue which lead to this fix in version 2.4.26, "Fixed libldap ASYNC TLS setup (ITS#6828)", and looked at the code that Ian Puleston suggested should be fixed in ldap_int_open_connection. This routine does have the code to do what was need for TSL to work but was not called since it received an error code of -2 not 0. The -2 simply indicated that this was an asynchronous call. I changed the test to call the TSL setup if the return code was either 0 or -2. This fixes my issue. Here is my patch. --- openldap-2.4.47/libraries/libldap/open.c 2018-12-19 10:57:06.000000000 -0500 +++ openldap-2.4.47.mod/libraries/libldap/open.c 2019-01-26 18:24:48.000000000 -0500 @@ -440,7 +440,7 @@ #endif #ifdef HAVE_TLS - if (rc == 0 && ( ld->ld_options.ldo_tls_mode == LDAP_OPT_X_TLS_HARD || + if ((rc == 0 || rc == -2) && ( ld->ld_options.ldo_tls_mode == LDAP_OPT_X_TLS_HARD || strcmp( srv->lud_scheme, "ldaps" ) == 0 )) { ++conn->lconn_refcnt; /* avoid premature free */ Thanks, Vern </body> </html>

1 0

Re: (ITS#8959) duplicate symbols
by quanah＠symas.com 28 Jan '19

28 Jan '19

--On Monday, January 28, 2019 3:35 PM +0000 Rupert Gallagher <ruga(a)protonmail.com> wrote: > As you can see, I am using the default Apple linker, and hardened > settings for the compiler. Try using those settings yourself, and see > what comes out. I tested on FreeBSD12 (since it uses clang rather than gcc) with the following flags and the build completed w/o issue: CFLAGS= -g -fstack-protector-all -fno-omit-frame-pointer -fPIC -fPIE -O2 -Wformat -Wformat-security -Werror=format-security LDFLAGS= -Wl,-z,relro,-z,now -pie CPPFLAGS= -D_FORTIFY_SOURCE=2 -D_FORTIFY_SOURCE=2 -D_FORTIFY_SOURCE=2 In any case, I think we've well established the problem you're hitting has zero to do with OpenLDAP in and of itself. You'll need to take this up elsewhere. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8959) duplicate symbols
by ruga＠protonmail.com 28 Jan '19

28 Jan '19

As you can see, I am using the default Apple linker, and hardened settings = for the compiler. Try using those settings yourself, and see what comes out= . =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me= ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 On Monday, January 28, 2019 3:16 PM, Quanah Gibson-Mount <quanah(a)symas.com>= wrote: > --On Monday, January 28, 2019 12:10 PM +0000 Rupert Gallagher > ruga(a)protonmail.com wrote: > > > I can replicate your log when using the default tool-chain by Apple. > > The following causes my system to fail with openldap, replicating my > > original bug. The same settings succeed with many other open source > > projects: openldap is the only one that fails. > > Then it sounds like OpenLDAP is tripping a bug in LLVM or related tools. > Again, there are no duplicate symbols in the liblber library. > > --Quanah

1 0

Re: (ITS#8959) duplicate symbols
by quanah＠symas.com 28 Jan '19

28 Jan '19

--On Monday, January 28, 2019 12:10 PM +0000 Rupert Gallagher <ruga(a)protonmail.com> wrote: > I can replicate your log when using the default tool-chain by Apple. > > The following causes my system to fail *with openldap*, replicating my > original bug. The same settings succeed with *many* other open source > projects: openldap is the only one that fails. Then it sounds like OpenLDAP is tripping a bug in LLVM or related tools. Again, there are no duplicate symbols in the liblber library. --Quanah > 1. install the official clang/llvm tool-chain from llvm.org; > 2. set up the shell as follows: > > export CC="/opt/llvm/bin/clang"; # gcc > export CMAKE_C_COMPILER="/opt/llvm/bin/clang"; > export CPP="/opt/llvm/bin/clang -E"; # cpp > export CXX="/opt/llvm/bin/clang++"; # g++ > export CMAKE_CXX_COMPILER="/opt/llvm/bin/clang++"; # g++ > export AR="/opt/llvm/bin/llvm-ar"; # ar > export CMAKE_AR="/opt/llvm/bin/llvm-ar"; # ar > export CMAKE_LINKER="/usr/bin/ld"; # Apple's own > export NM="/opt/llvm/bin/llvm-nm"; # nm > export CMAKE_NM="/opt/llvm/bin/llvm-nm"; # nm > export CMAKE_OBJDUMP="/opt/llvm/bin/llvm-objdump"; > export RANLIB="/opt/llvm/bin/llvm-ranlib"; > export CMAKE_RANLIB="/opt/llvm/bin/llvm-ranlib"; > sdk_p="$( /usr/bin/xcode-select -print-path )"; > sdk_v="$( /usr/bin/xcrun --show-sdk-version )"; > ># runtime compatibility with former versions: > sdk_c="${sdk_v}"; > case $sdk_v in > 10.14) sdk_c="10.13";; > 10.13) sdk_c="10.13";; > esac > > CFLAGS=""; > CCFLAGS=""; > CPPFLAGS=""; > LDFLAGS=""; > > export MACOSX_DEPLOYMENT_TARGET="${sdk_c}"; > CFLAGS="$CFLAGS -g -mmacosx-version-min=${sdk_c} -isysroot > ${sdk_p}/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk"; > CFLAGS="$CFLAGS -arch x86_64"; > ># exploit mitigation: RELRO + BIND_NOW > LDFLAGS="$LDFLAGS -Wl,-z,relro,-z,now"; > ># exploit mitigation: stack canary > CFLAGS="$CFLAGS -fstack-protector-all"; > ># nicer stack traces in error messages > CFLAGS="$CFLAGS -fno-omit-frame-pointer"; > ># exploit mitigations: > CFLAGS="$CFLAGS -fPIC -fPIE"; > LDFLAGS="$LDFLAGS -pie"; > ># exploit mitigation: protect memory and string functions > CFLAGS="$CFLAGS -O2"; > CPPFLAGS="$CPPFLAGS -D_FORTIFY_SOURCE=2"; > ># exploit mitigation: format string warnings as errors > CFLAGS="$CFLAGS -Wformat -Wformat-security -Werror=format-security"; > > export CFLAGS; > export CCFLAGS="$CFLAGS"; > export CPPFLAGS; > export CXXFLAGS="$CPPFLAGS"; > export LDFLAGS; > export DSOFLAGS="$LDFLAGS"; > -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

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