openldap-bugs

openldap-bugs@openldap.org

1 participants
20963 discussions

(ITS#8303) An Asynchronous meta back-end for OpenLDAP
by nivanova＠symas.com 05 Nov '15

05 Nov '15

Full_Name: Nadezhda Ivanova Version: slapd 2.X OS: URL: ftp://ftp.openldap.org/incoming/Nadezhda-Ivanova-151105.patch Submission from: (NULL) (78.83.54.234) This is an asynchronous version of the meta back-end. The attached files are derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch were developed by Symas Corporation. Symas Corporation has not assigned rights and/or interest in this work to any party. I, Nadezhda Ivanova, am authorized by Symas Corporation, my employer, to release this work under the following terms. The attached modifications to OpenLDAP Software are subject to the following notice: Copyright 2015 Symas Corporation Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License.

1 0

Re: (ITS#8301) signed/unsigned confusion in ber_get_next()
by hyc＠symas.com 05 Nov '15

05 Nov '15

ryan(a)nardis.ca wrote: > On Thu, Nov 05, 2015 at 12:12:26AM +0000, ondra(a)mistotebe.net wrote: >> Hi, the following will assert in liblber on i386 (and it should be possible to >> craft a similar one for 64bit, I think): >> >> echo 'CoSSoJKSCg==' | base64 -d | ~/code/openldap/libraries/liblber/etest . > > ITYM dtest? > > slapd's sane default setting for sb_max_incoming appears to mitigate > most of the potential security impact of this one. Agreed. But I guess we need to reject any len values that exceed the range of a signed ber_len_t, since many liblber functions can only return a ber_slen_t result. -- -- 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#8302) The chain-tls failure
by benhuang＠icil.net 05 Nov '15

05 Nov '15

Full_Name: Ben Huang Version: 2.4.37 OS: Ubuntu 12.04.4 LTS URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (202.130.86.130) Two servers: Provider (A public IP) and Consumer (A private IP) both running slap 2.4.37 and ubuntu 12.04. Replica is a replication partner of Provider using syncrepl. Replication and TLS is working fine. When I attempt to add a chain overlay to Replica to send all writes over to the Privder, I cannot enable TLS from the consumer to the ldap Provider. Here is my overlay config using the rootDN and TLS (on Replica): ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: olcOverlayConfig objectClass: olcChainConfig olcOverlay: {0}chain olcChainCacheURI: FALSE olcChainMaxReferralDepth: 1 olcChainReturnError: TRUE dn: olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {0}ldap olcDbStartTLS: none starttls=no olcDbRebindAsUser: FALSE olcDbChaseReferrals: TRUE olcDbTFSupport: no olcDbProxyWhoAmI: FALSE olcDbProtocolVersion: 3 olcDbSingleConn: FALSE olcDbCancel: abandon olcDbUseTemporaryConn: FALSE olcDbConnectionPoolMax: 16 olcDbSessionTrackingRequest: FALSE olcDbNoRefs: FALSE olcDbNoUndefFilter: FALSE olcDbOnErr: continue olcDbKeepalive: 0:0:0 dn: olcDatabase={1}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {1}ldap olcDbURI: "ldap://provider.example.com" olcDbStartTLS: start starttls=no olcDbIDAssertBind: mode=self flags=prescriptive,proxy-authz-non-critical bindm ethod=simple timeout=0 network-timeout=0 binddn="cn=admin,dc=ufreight,dc=com" credentials="password" keepalive=0:0:0 olcDbRebindAsUser: FALSE olcDbChaseReferrals: TRUE olcDbTFSupport: no olcDbProxyWhoAmI: FALSE olcDbProtocolVersion: 3 olcDbSingleConn: FALSE olcDbCancel: abandon olcDbUseTemporaryConn: FALSE olcDbConnectionPoolMax: 16 olcDbSessionTrackingRequest: FALSE olcDbNoRefs: FALSE olcDbNoUndefFilter: FALSE olcDbOnErr: continue olcDbKeepalive: 0:0:0 With above configuration, I run following command is ok: #ldapsearch -xLLL -H ldap://ldap-u1.ufreight.com -ZZ uid=testuser dn dn: uid=testuser,ou=People,dc=ufreight,dc=com But below errors occurred when I try to add an entry on consumer. ldapadd -x -D "cn=admin,dc=ufreight,dc=com" -w password -f add_user.ldif -ZZ adding new entry "uid=test,ou=People,dc=ufreight,dc=com" ldap_add: Server is unavailable (52) Consumer LDAP logs: No 5 1 19:12:28 consumer slapd[6575]: conn=1005 fd=16 ACCEPT from IP=127.0.0.1:41018 (IP=0.0.0.0:389) Nov 5 19:12:29 consumer slapd[6575]: conn=1005 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Nov 5 19:12:29 consumer slapd[6575]: conn=1005 op=0 STARTTLS Nov 5 19:12:29 consumer slapd[6575]: conn=1005 op=0 RESULT oid= err=0 text= Nov 5 19:12:30 consumer slapd[6575]: conn=1005 fd=16 TLS established tls_ssf=128 ssf=128 Nov 5 19:12:31 consumer slapd[6575]: conn=1005 op=1 BIND dn="cn=admin,dc=ufreight,%c=com" method=128 Nov 5 19:12:31 consumer slapd[6575]: conn=1005 op=1 BIND dn="cn=admin,dc=ufreight,dc=com" mech=SIMPLE ssf=0 Nov 5 19:12:31 consumer slapd[6575]: conn=1005 op=1 RESULT tag=97 err=0 text= Nov 5 19:12:32 consumer slapd[6575]: conn=1005 op=2 ADD dn="uid=test,ou=People,dc=ufreight,dc=com" Nov 5 19:12:32 consumer slapd[6575]: conn=1005 op=2 RESULT tag=105 err=52 text= Nov 5 19:12:33 consumer slapd[6575]: conn=1005 op=3 UNBIND Nov 5 19:12:33 consumer slapd[6575]: conn=1005 fd=16 closed Provider LDAP logs: Nov 5 19:11:18 provider slapd[17011]: conn=312743 fd=13 ACCEPT from IP=140.207.172.138:39551 (IP=0.0.0.0:389) Nov 5 19:11:18 provider slapd[17011]: conn=312743 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Nov 5 19:11:18 provider slapd[17011]: conn=312743 op=0 STARTTLS Nov 5 19:11:18 provider slapd[17011]: conn=312743 op=0 RESULT oid= err=0 text= Nov 5 19:11:19 provider slapd[17011]: conn=312743 fd=13 closed (TLS negotiation failure) Any suggestion what cause TLS negotiation failure? Thank you very much.

1 0

Re: (ITS#8267) contributing a new overlay unicodepw
by ingo.voss＠gmail.com 05 Nov '15

05 Nov '15

2015-10-25 9:28 GMT+01:00 Howard Chu <hyc(a)symas.com>: > Ingo Voss wrote: >> >> >> >> Am 17.10.2015 um 20:58 schrieb Howard Chu: >>> >>> ingo.voss(a)gmail.com wrote: >>>> >>>> Full_Name: Ingo Voss >>>> Version: >>>> OS: >>>> URL: ftp://ftp.openldap.org/incoming/contrib-slapd-modules-unicodepw.tar >>>> Submission from: (NULL) (78.53.86.212) >>>> >>>> >>>> Hello, >>>> >>>> I wrote a small overlay, that restricts all LDAP modification requests, >>>> so >>>> that >>>> only password changes for MS unicodePwd are possible. >>>> All other LDAP requests will not be observed. >>>> If someone needs a read-only proxy (in a e.g. dmz) for an MS Active >>>> Directory, >>>> but password changes must be possible, then unicodepw is the right >>>> overlay. >>>> For more informations, a manual page is included. >>> >>> >>> If you want a read-only proxy, shouldn't this overlay also intercept and >>> deny all Add/Delete/ModDN requests? >>> >> >> Yes, you are right! But such overlay (denyop) exist already and it is >> working >> well. >> The manual page for unicodepw refers to denyop and describes the complete >> configuration in detail. > > > OK. > > This code is full of C++ comments. OpenLDAP uses C comments only. > > This code is full of SPACEs for indentation. OpenLDAP uses TAB characters > for indentation, with 4-column tab stops. OK, I'll change that. > > Your debug messages are using STATS debug level. STATS is reserved for LDAP > operation/parameter logging only and is the default level. Code should be > silent at the default level unless major errors have occurred. Please can you guide me what log level should be used for such security related messages? The messages are only logged, if a password is changed. (Normally, password changes are very seldom and makes low noise.) Thanks Ingo

1 0

Re: (ITS#8301) signed/unsigned confusion in ber_get_next()
by ryan＠nardis.ca 04 Nov '15

04 Nov '15

On Thu, Nov 05, 2015 at 12:12:26AM +0000, ondra(a)mistotebe.net wrote: >Hi, the following will assert in liblber on i386 (and it should be possible to >craft a similar one for 64bit, I think): > >echo 'CoSSoJKSCg==' | base64 -d | ~/code/openldap/libraries/liblber/etest . ITYM dtest? slapd's sane default setting for sb_max_incoming appears to mitigate most of the potential security impact of this one.

1 0

(ITS#8301) signed/unsigned confusion in ber_get_next()
by ondra＠mistotebe.net 04 Nov '15

04 Nov '15

Full_Name: Ond&#345;ej Kuzn.k Version: re24 OS: Linux i386 URL: Submission from: (NULL) (86.166.135.137) Hi, the following will assert in liblber on i386 (and it should be possible to craft a similar one for 64bit, I think): echo 'CoSSoJKSCg==' | base64 -d | ~/code/openldap/libraries/liblber/etest . My first reaction was that it encodes a length that, while still not enough to overflow the address space, will have the highest bit set and is interpreted as negative when saved into to_go in io.c:658, triggering the assert. However ber_get_next is more complex than that and I can't read BER yet.

1 0

Re: (ITS#8300) LMDB mdb_cursor_del data loss
by hyc＠symas.com 04 Nov '15

04 Nov '15

malyn(a)strangeGizmo.com wrote: > Full_Name: Michael Alyn Miller > Version: Git head > OS: Windows 8.1 x64, NixOS 14.12 x64 > URL: ftp://ftp.openldap.org/incoming/michaelalynmiller-151104.c > Submission from: (NULL) (96.251.78.237) > > > Another issue similar to ITS#8264 and ITS#8299, but this time using > mdb_cursor_del inside of the cursor causes corruption. mdb_del causes > corruption as well, but this is the first time that I have seen mdb_cursor_del > do the wrong thing. > > In this case, mdb_cursor_del incorrectly removes one extra key (a key > prefixed with 0c000000000000003a...) in addition to correctly removing all of > the keys that begin with 0d000000000000003a. > > mdb_del does not remove that extra key, but instead fails to remove two > 0d000000000000003a keys that should have been removed. > > I am not sure if these are two different bugs or if they are caused by the same > underlying issue. Similar reason, two different mistakes. Fixed now in git. > > mdb_cursor_del performs correctly on subsequent runs if you do *not* remove the > database between tests, whereas mdb_del continues to fail, but stabilizes on a > different set of results after the first run. > > -- -- 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#8299) LMDB mdb_del data loss when used in a cursor (new repro)
by malyn＠strangegizmo.com 04 Nov '15

04 Nov '15

> >> I have a new repro of an ITS#8264-like situation, but with different > >> input data and with slightly different results. Note that ITS#8264 > >> was fixed with the dataset provided in that bug; this is a different > >> dataset and produces different results. > >> > >> The referenced test runs twice: once with mdb_cursor_del and once with > mdb_del. > >> Just like before, mdb_cursor_del performs correctly whereas mdb_del > >> corrupts the database. In this case, mdb_del incorrectly removes one > >> extra key (a key prefixed with 04000000000000003a...), and > >> incorrectly leaves 21 keys in place that should have been deleted > >> (those keys begin with 05000000000000003a...). > >> This last item is the primary difference between these two bugs. > >> > >> Unlike ITS#8264, you do not need to remove the database in between > >> test runs in order to repro this issue, although the results are > >> still incorrect and will eventually cause a bus error. > > > > Thanks again for the excellent bug reports. Fixed now in git. >=20 > I should also note that this is not a sensible use case. mdb_del has to > construct a cursor to perform its work; if you already have a cursor open= you > should just use mdb_cursor_del. mdb_del is meant for one-shot use and is > much slower than mdb_cursor_del when used in an iteration. Thanks for this information. I will make the change to use mdb_cursor_del = when possible. There are a couple of circumstances where I do not currentl= y have access to the cursor though and will need to use mdb_del (or mdb_put= , for updates) inside of the cursor. I will look into passing the cursor u= p to my higher-level API callers though... Note that I just reported ITS#8300, which was found after making the switch= to mdb_cursor_del (and after applying the fix for ITS#8299). Thanks, Michael Alyn Miller

1 0

(ITS#8300) LMDB mdb_cursor_del data loss
by malyn＠strangeGizmo.com 04 Nov '15

04 Nov '15

Full_Name: Michael Alyn Miller Version: Git head OS: Windows 8.1 x64, NixOS 14.12 x64 URL: ftp://ftp.openldap.org/incoming/michaelalynmiller-151104.c Submission from: (NULL) (96.251.78.237) Another issue similar to ITS#8264 and ITS#8299, but this time using mdb_cursor_del inside of the cursor causes corruption. mdb_del causes corruption as well, but this is the first time that I have seen mdb_cursor_del do the wrong thing. In this case, mdb_cursor_del incorrectly removes one extra key (a key prefixed with 0c000000000000003a...) in addition to correctly removing all of the keys that begin with 0d000000000000003a. mdb_del does not remove that extra key, but instead fails to remove two 0d000000000000003a keys that should have been removed. I am not sure if these are two different bugs or if they are caused by the same underlying issue. mdb_cursor_del performs correctly on subsequent runs if you do *not* remove the database between tests, whereas mdb_del continues to fail, but stabilizes on a different set of results after the first run.

1 0

Re: (ITS#8299) LMDB mdb_del data loss when used in a cursor (new repro)
by hyc＠symas.com 04 Nov '15

04 Nov '15

Howard Chu wrote: > malyn(a)strangeGizmo.com wrote: >> Full_Name: Michael Alyn Miller >> Version: Git head >> OS: Windows 8.1 x64, NixOS 14.12 x64 >> URL: ftp://ftp.openldap.org/incoming/michaelalynmiller-151103.c >> Submission from: (NULL) (96.251.78.237) >> >> >> I have a new repro of an ITS#8264-like situation, but with different input data >> and with slightly different results. Note that ITS#8264 was fixed with the >> dataset provided in that bug; this is a different dataset and produces >> different >> results. >> >> The referenced test runs twice: once with mdb_cursor_del and once with mdb_del. >> Just like before, mdb_cursor_del performs correctly whereas mdb_del corrupts >> the >> database. In this case, mdb_del incorrectly removes one extra key (a key >> prefixed with 04000000000000003a...), and incorrectly leaves 21 keys in place >> that should have been deleted (those keys begin with 05000000000000003a...). >> This last item is the primary difference between these two bugs. >> >> Unlike ITS#8264, you do not need to remove the database in between test runs in >> order to repro this issue, although the results are still incorrect and will >> eventually cause a bus error. > > Thanks again for the excellent bug reports. Fixed now in git. I should also note that this is not a sensible use case. mdb_del has to construct a cursor to perform its work; if you already have a cursor open you should just use mdb_cursor_del. mdb_del is meant for one-shot use and is much slower than mdb_cursor_del when used in an iteration. -- -- 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

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