openldap-bugs November 2008

openldap-bugs@openldap.org

44 participants
242 discussions

Re: (ITS#5823) clients/tools don't honor ldap.conf defaults
by h.b.furuseth＠usit.uio.no 20 Nov '08

20 Nov '08

hyc(a)OpenLDAP.org writes: > I suggest that we use option==1 for on, and option>1 for off, to > minimize the impact of the change. (E.g., to explicitly turn off > referrals, use ldapsearch -CC.) That conflicts with today's -ZZ, which seems a bad option to create confusion about. Also with ldapsearch -L[L[L]]. Another variant is -C = on and +C = off. Backwards, but it's not our fault that Unix chose "-" for "on":-) Unless +foo means something special on Windows command lines? -- Hallvard

1 0

(ITS#5823) clients/tools don't honor ldap.conf defaults
by hyc＠OpenLDAP.org 20 Nov '08

20 Nov '08

Full_Name: Howard Chu Version: HEAD/RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.91.220.157) Submitted by: hyc Various options in clients/tools/common.c are set as follows: /* referrals */ if( ldap_set_option( ld, LDAP_OPT_REFERRALS, referrals ? LDAP_OPT_ON : LDAP_OPT_OFF ) != LDAP_OPT_SUCCESS ) This means if the commandline option was provided, the option is turned on, otherwise it is turned off. I.e., the ldap.conf setting is completely overridden at all times. All of these options cases should be fixed to only issue the ldap_set_option() call if the corresponding argument was provided, to allow the default setting to take effect when the arguments are not provided. I suggest that we use option==1 for on, and option>1 for off, to minimize the impact of the change. (E.g., to explicitly turn off referrals, use ldapsearch -CC.)

1 0

Re: (ITS#5812) New option to disable SASL host canonicalization
by rra＠stanford.edu 20 Nov '08

20 Nov '08

Howard Chu <hyc(a)symas.com> writes: > The real problem is that the standard POSIX gethost/getaddr* APIs don't > tell you the confidence level of the information they return. Nor do > they let you specify a minimum acceptable confidence level when you make > a query. (Analogous to the SSFs we use in OpenLDAP.) Yeah, that would be great. There are, unfortunately, a bunch of problems with those interfaces. Blocking behavior is another problem with them. -- Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>

1 0

Re: (ITS#5812) New option to disable SASL host canonicalization
by hyc＠symas.com 20 Nov '08

20 Nov '08

rra(a)stanford.edu wrote: > Howard Chu<hyc(a)symas.com> writes: > >> Leaving aside your followup which clarified this clause: the obvious >> point is that a Kerberos client needs to have trusted *local* data to >> protect against this attack. > > All Kerberos clients have trusted local data. It's required by the > Kerberos protocol; the server gives you a TGT that you can only decrypt > using your trusted local data. So I'm not sure what you're getting at > here. The problem with DNS canonicalization is that it allows you to > attack clients even if those clients have trusted local data to establish > mutual authentication with the KDC. This is going way beyond off topic but... The real problem is that the standard POSIX gethost/getaddr* APIs don't tell you the confidence level of the information they return. Nor do they let you specify a minimum acceptable confidence level when you make a query. (Analogous to the SSFs we use in OpenLDAP.) -- -- 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#5812) New option to disable SASL host canonicalization
by rra＠stanford.edu 20 Nov '08

20 Nov '08

My apologies for completely failing reading comprehension and including so much material that had already been mentioned in this ITS. I hadn't realized until I reviewed the whole ITS log just how much I'd duplicated of what people had already said. :/ -- Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>

1 0

Re: (ITS#5812) New option to disable SASL host canonicalization
by hyc＠symas.com 20 Nov '08

20 Nov '08

geert(a)boskant.nl wrote: > Full_Name: Geert Jansen > Version: 2.4 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/geert-jansen-081115.patch > Submission from: (NULL) (12.230.186.195) > > > This is a resubmission of my earlier patch in [1]. I'm asking for this patch to > be included into OpenLDAP. > > The patch adds an LDAP option called LDAP_OPT_X_SASL_NOCANON to disable host > name canonicalization using reverse DNS for the host name that is passed into > SASL. Instead, it passes verbatim the host name part from the LDAP URI and lets > SASL do the canonicalization. The option is disabled by default. > Since some time MIT Kerberos has support for server-side canonicalization which > is an alternative for the DNS based scheme. By default it uses both, but with an > option "rdns = no", reverse DNS can be disabled. > > The use case for this is environments that do not have reverse DNS set up > correctly. Especially in Windows Active Directory environments this is very > common. Administrators are afraid to enable scavenging for their zones, and > therefore any server IP change will leave a stale PTR record in place. This > breaks reverse DNS based canonicalization if the IP adress is reassigned. > > The behaviour enabled by this patch should remain optional and cannot become the > default. It breaks the use case when multiple LDAP servers are load balanced > using a CNAME record. In reviewing this patch, I see some technical issues to resolve: 1) You seem to be making the ldap_set_option "arg" parameter optional; there appears to be no justification for this (significant) behavioral change. 2) If you're dealing with a KDC that supports this feature, then it would make the most sense for this to be a site-wide option. As such, it should be possible for the setting to become the default, and an ldap.conf keyword should exist to control that setting. 3) Your addition of the option to the command line tools is boolean; if the command line option is present the option will be turned on, otherwise it will be turned off. This requires too much knowledge on the part of the user running the tool, to decide whether they need the option or not. Again, it should allow a system-wide setting, and the command-line option should be tri-state: on / off / default. Users should not be required to learn about this option before using the commandline tools, the sysadmin should set it site-wide when the KDC is known to support it. -- -- 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#5820) segfault with slapacl
by ghenry＠OpenLDAP.org 20 Nov '08

20 Nov '08

----- ando(a)sys-net.it wrote: > Gavin Henry wrote: > >>> Anyone else seeing this? > >>> > >> Working here. > > > > I'm on 4.7.25 with patches, 32-bit. You? > > Same here. On a different 32-bit machine it passes on Head. Weird. Will check it out. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

Re: (ITS#5812) New option to disable SASL host canonicalization
by rra＠stanford.edu 20 Nov '08

20 Nov '08

Howard Chu <hyc(a)symas.com> writes: > Leaving aside your followup which clarified this clause: the obvious > point is that a Kerberos client needs to have trusted *local* data to > protect against this attack. All Kerberos clients have trusted local data. It's required by the Kerberos protocol; the server gives you a TGT that you can only decrypt using your trusted local data. So I'm not sure what you're getting at here. The problem with DNS canonicalization is that it allows you to attack clients even if those clients have trusted local data to establish mutual authentication with the KDC. > Delegating administration authority still implies that you trust whoever > you delegated it to. Again, if you can't trust everyone then your > administrative procedures are broken and your framework has already been > compromised. Yes, it implies that you trust them to take the actions that you delegated to them. However, it *doesn't* imply that you trust them universally. You can delegate control of some principals and not others. That's a meaningful operation that is entirely valid within the Kerberos protocol trust model. Control of one principal in a realm should not imply an ability to spoof authentications to other principals in the same realm. Kerberos as a protocol can and is designed to be robust against attackers who have control over principals within your local realm provided that a client and a server agree on principal naming for a service. Kerberos clients are specifically cautioned in the Kerberos protocol specification against using insecure DNS to establish that agreement naming. Section 1.3 of RFC 4120, particularly the two paragraphs starting with: Implementations of Kerberos and protocols based on Kerberos MUST NOT use insecure DNS queries to canonicalize the hostname components of the service principal names (i.e., they MUST NOT use insecure DNS queries to map one name to another to determine the host part of the principal name with which one is to communicate). and the security considerations section of RFC 4752, namely: When constructing the input_name_string, the client SHOULD NOT canonicalize the server's fully qualified domain name using an insecure or untrusted directory service. are relevant here. The delegated administrative model that I describe is in widespread use; in fact, I don't know of any of my colleagues who *don't* do something similar to that. -- Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>

1 0

Re: (ITS#5820) segfault with slapacl
by ando＠sys-net.it 20 Nov '08

20 Nov '08

Gavin Henry wrote: >>> Anyone else seeing this? >>> >> Working here. > > I'm on 4.7.25 with patches, 32-bit. You? Same here. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5820) segfault with slapacl
by ghenry＠OpenLDAP.org 20 Nov '08

20 Nov '08

> > > > Anyone else seeing this? > > > > Working here. I'm on 4.7.25 with patches, 32-bit. You? -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

← Newer
1
...
4
5
6
7
8
9
10
...
25
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs November 2008