(ITS#8964) ldap proxy segmentation fault
by praveen.adini＠fireeye.com
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" "#"
4 years, 8 months
(ITS#8963) Start TLS failed errors on back-ldap binds / short timeout, config option request
by janne.peltonen＠helsinki.fi
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.
4 years, 8 months
(ITS#8957)
by vsmith＠interlinknetworks.com
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p><font face="Calibri">I reviewed some of the initial discussion
about this same issue which lead to this fix in version 2.4.26,
"</font>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.</p>
<p>--- openldap-2.4.47/libraries/libldap/open.c 2018-12-19
10:57:06.000000000 -0500<br>
+++ openldap-2.4.47.mod/libraries/libldap/open.c 2019-01-26
18:24:48.000000000 -0500<br>
@@ -440,7 +440,7 @@<br>
#endif<br>
<br>
#ifdef HAVE_TLS<br>
- if (rc == 0 && ( ld->ld_options.ldo_tls_mode ==
LDAP_OPT_X_TLS_HARD ||<br>
+ if ((rc == 0 || rc == -2) && (
ld->ld_options.ldo_tls_mode == LDAP_OPT_X_TLS_HARD ||<br>
strcmp( srv->lud_scheme, "ldaps" ) == 0 ))<br>
{<br>
++conn->lconn_refcnt; /* avoid premature free */<br>
</p>
<p><font face="Arial,Verdana,Helvetica">Thanks,<br>
Vern</font><br>
<font face="Arial,Verdana,Helvetica"></font></p>
</body>
</html>
4 years, 8 months
Re: (ITS#8959) duplicate symbols
by quanah＠symas.com
--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>
4 years, 8 months
Re: (ITS#8959) duplicate symbols
by ruga＠protonmail.com
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
4 years, 8 months
Re: (ITS#8959) duplicate symbols
by quanah＠symas.com
--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>
4 years, 8 months
Fw: Re: (ITS#8959) duplicate symbols
by ruga＠protonmail.com
=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 12:10 PM, 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 orig=
inal bug.
> The same settings succeed with many other open source projects: openldap =
is the only one that fails.
>
> 1. install the official clang/llvm tool-chain from llvm.org;
> 2. set up the shell as follows:
>
> export CC=3D"/opt/llvm/bin/clang"; # gcc
> export CMAKE_C_COMPILER=3D"/opt/llvm/bin/clang";
> export CPP=3D"/opt/llvm/bin/clang -E"; # cpp
> export CXX=3D"/opt/llvm/bin/clang++"; # g++
> export CMAKE_CXX_COMPILER=3D"/opt/llvm/bin/clang++"; # g++
> export AR=3D"/opt/llvm/bin/llvm-ar"; # ar
> export CMAKE_AR=3D"/opt/llvm/bin/llvm-ar"; # ar
> export CMAKE_LINKER=3D"/usr/bin/ld"; # Apple's own
> export NM=3D"/opt/llvm/bin/llvm-nm"; # nm
> export CMAKE_NM=3D"/opt/llvm/bin/llvm-nm"; # nm
> export CMAKE_OBJDUMP=3D"/opt/llvm/bin/llvm-objdump";
> export RANLIB=3D"/opt/llvm/bin/llvm-ranlib";
> export CMAKE_RANLIB=3D"/opt/llvm/bin/llvm-ranlib";
> sdk_p=3D"$( /usr/bin/xcode-select -print-path )";
> sdk_v=3D"$( /usr/bin/xcrun --show-sdk-version )";
>
>
> runtime compatibility with former versions:
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> sdk_c=3D"${sdk_v}";
> case $sdk_v in
> 10.14) sdk_c=3D"10.13";;
> 10.13) sdk_c=3D"10.13";;
> esac
>
> CFLAGS=3D"";
> CCFLAGS=3D"";
> CPPFLAGS=3D"";
> LDFLAGS=3D"";
>
> export MACOSX_DEPLOYMENT_TARGET=3D"${sdk_c}";
> CFLAGS=3D"$CFLAGS -g -mmacosx-version-min=3D${sdk_c} -isysroot ${sdk_p}/P=
latforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk";
> CFLAGS=3D"$CFLAGS -arch x86_64";
>
> exploit mitigation: RELRO + BIND_NOW
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> LDFLAGS=3D"$LDFLAGS -Wl,-z,relro,-z,now";
>
> exploit mitigation: stack canary
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> CFLAGS=3D"$CFLAGS -fstack-protector-all";
>
> nicer stack traces in error messages
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> CFLAGS=3D"$CFLAGS -fno-omit-frame-pointer";
>
> exploit mitigations:
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> CFLAGS=3D"$CFLAGS -fPIC -fPIE";
> LDFLAGS=3D"$LDFLAGS -pie";
>
> exploit mitigation: protect memory and string functions
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D
>
> CFLAGS=3D"$CFLAGS -O2";
> CPPFLAGS=3D"$CPPFLAGS -D_FORTIFY_SOURCE=3D2";
>
> exploit mitigation: format string warnings as errors
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D
>
> CFLAGS=3D"$CFLAGS -Wformat -Wformat-security -Werror=3Dformat-security";
>
> export CFLAGS;
> export CCFLAGS=3D"$CFLAGS";
> export CPPFLAGS;
> export CXXFLAGS=3D"$CPPFLAGS";
> export LDFLAGS;
> export DSOFLAGS=3D"$LDFLAGS";
4 years, 8 months
Re: (ITS#8959) duplicate symbols
by ruga＠protonmail.com
This is a multi-part message in MIME format.
--b1_79bd4f6e67d888ad581efca0722453e4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: base64
PiBJdCBidWlsZHMganVzdCBmaW5lIHdpdGggemVybyBpc3N1ZXMuCgpJJ2xsIGJlbGlldmUgeW91
IHdoZW4gSSBzZWUgeW91ciBsb2cuCgpPbiBGcmksIEphbiAyNSwgMjAxOSBhdCAxNjowOSwgUXVh
bmFoIEdpYnNvbi1Nb3VudCA8cXVhbmFoQHN5bWFzLmNvbT4gd3JvdGU6Cgo+IC0tT24gRnJpZGF5
LCBKYW51YXJ5IDI1LCAyMDE5IDc6NDIgQU0gKzAwMDAgUnVwZXJ0IEdhbGxhZ2hlcgo+IDxydWdh
QHByb3Rvbm1haWwuY29tPiB3cm90ZToKPgo+Pgo+PiBJdCBpcyBldmlkZW50IGZyb20gdGhlIGJ1
ZyByZXBvcnQgdGhhdCB0aGUgbGlua2VyIGlzIHJlYWRpbmcgdHdpY2UgZnJvbQo+PiB0aGUgc2Ft
ZSBwYXRoIGluc2lkZSBvcGVubGRhcCdzIHNvdXJjZSBmb2xkZXIuCj4+Cj4+Cj4+IFRoZSBsaW5r
ZXIganVzdCBmb2xsb3dzIHlvdXIgaW5zdHJ1Y3Rpb25zLgo+Cj4gQWdhaW4sIHRoZXJlIGlzIGEg
cHJvYmxlbSBzcGVjaWZpYyB0byB5b3VyIGJ1aWxkIGVudmlyb25tZW50Lgo+Cj4gSnVzdCBmb3Ig
a2lja3MsIEkgZG93bmxvYWRlZCBhbmQgYnVpbHQgT3BlbkxEQVAgMi40LjQ3IHRvZGF5IG9uIG15
IE9TWAo+IGxhcHRvcCAoRGFyd2luIDE4LjIuMCkgd2l0aCB0aGUgY3VycmVudCBYY29kZSByZWxl
YXNlLgo+Cj4gSXQgYnVpbGRzIGp1c3QgZmluZSB3aXRoIHplcm8gaXNzdWVzLgo+Cj4gLS1RdWFu
YWgKPgo+IC0tCj4KPiBRdWFuYWggR2lic29uLU1vdW50Cj4gUHJvZHVjdCBBcmNoaXRlY3QKPiBT
eW1hcyBDb3Jwb3JhdGlvbgo+IFBhY2thZ2VkLCBjZXJ0aWZpZWQsIGFuZCBzdXBwb3J0ZWQgTERB
UCBzb2x1dGlvbnMgcG93ZXJlZCBieSBPcGVuTERBUDoKPiA8aHR0cDovL3d3dy5zeW1hcy5jb20+
--b1_79bd4f6e67d888ad581efca0722453e4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: base64
ICAgPGRpdj4mZ3Q7Jm5ic3A7PHNwYW4gc3R5bGU9Ii13ZWJraXQtdGV4dC1zaXplLWFkanVzdDog
YXV0bzsiPkl0IGJ1aWxkcyBqdXN0IGZpbmUgd2l0aCB6ZXJvIGlzc3Vlcy48L3NwYW4+PC9kaXY+
PGRpdj48c3BhbiBzdHlsZT0iLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyI+PGJyPjwv
c3Bhbj48L2Rpdj48ZGl2PjxzcGFuIHN0eWxlPSItd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1
dG87Ij5JJ2xsIGJlbGlldmUgeW91IHdoZW4gSSBzZWUgeW91ciBsb2cuPC9zcGFuPjwvZGl2PiA8
ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj5PbiBGcmksIEphbiAyNSwgMjAxOSBhdCAxNjow
OSwgUXVhbmFoIEdpYnNvbi1Nb3VudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnF1YW5haEBzeW1hcy5j
b20iIGNsYXNzPSIiPnF1YW5haEBzeW1hcy5jb208L2E+Jmd0OyB3cm90ZTo8YmxvY2txdW90ZSBj
bGFzcz0icHJvdG9ubWFpbF9xdW90ZSIgdHlwZT0iY2l0ZSI+ICAtLU9uIEZyaWRheSwgSmFudWFy
eSAyNSwgMjAxOSA3OjQyIEFNICswMDAwIFJ1cGVydCBHYWxsYWdoZXI8YnI+Jmx0O3J1Z2FAcHJv
dG9ubWFpbC5jb20mZ3Q7IHdyb3RlOjxicj48YnI+Jmd0Ozxicj4mZ3Q7IEl0IGlzIGV2aWRlbnQg
ZnJvbSB0aGUgYnVnIHJlcG9ydCB0aGF0IHRoZSBsaW5rZXIgaXMgcmVhZGluZyB0d2ljZSBmcm9t
PGJyPiZndDsgdGhlIHNhbWUgcGF0aCBpbnNpZGUgb3BlbmxkYXAncyBzb3VyY2UgZm9sZGVyLjxi
cj4mZ3Q7PGJyPiZndDs8YnI+Jmd0OyBUaGUgbGlua2VyIGp1c3QgZm9sbG93cyB5b3VyIGluc3Ry
dWN0aW9ucy48YnI+PGJyPkFnYWluLCB0aGVyZSBpcyBhIHByb2JsZW0gc3BlY2lmaWMgdG8geW91
ciBidWlsZCBlbnZpcm9ubWVudC48YnI+PGJyPkp1c3QgZm9yIGtpY2tzLCBJIGRvd25sb2FkZWQg
YW5kIGJ1aWx0IE9wZW5MREFQIDIuNC40NyB0b2RheSBvbiBteSBPU1g8YnI+bGFwdG9wIChEYXJ3
aW4gMTguMi4wKSB3aXRoIHRoZSBjdXJyZW50IFhjb2RlIHJlbGVhc2UuPGJyPjxicj5JdCBidWls
ZHMganVzdCBmaW5lIHdpdGggemVybyBpc3N1ZXMuPGJyPjxicj4tLVF1YW5haDxicj48YnI+PGJy
Pjxicj4tLTxicj48YnI+UXVhbmFoIEdpYnNvbi1Nb3VudDxicj5Qcm9kdWN0IEFyY2hpdGVjdDxi
cj5TeW1hcyBDb3Jwb3JhdGlvbjxicj5QYWNrYWdlZCwgY2VydGlmaWVkLCBhbmQgc3VwcG9ydGVk
IExEQVAgc29sdXRpb25zIHBvd2VyZWQgYnkgT3BlbkxEQVA6PGJyPiZsdDtodHRwOi8vd3d3LnN5
bWFzLmNvbSZndDs8YnI+PGJyPjwvYmxvY2txdW90ZT48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48
L2Rpdj4=
--b1_79bd4f6e67d888ad581efca0722453e4--
4 years, 8 months
