openldap-bugs

openldap-bugs@openldap.org

1 participants
20963 discussions

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

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

20 Nov '08

ghenry(a)OpenLDAP.org wrote: > ----- "Pierangelo Masarati" <ando(a)sys-net.it> wrote: > >> ghenry(a)OpenLDAP.org wrote: >> >>> I've just hit this: >>> >>> /usr/local/sbin/slapacl -f /usr/local/etc/openldap/slapd.conf -b >>> "dc=suretecsystems,dc=com" -U ghenry "userPassword/read:" >>> authcDN: "uid=ghenry,cn=auth" >>> read access to userPassword=: DENIED >>> Segmentation fault >> Fixed in HEAD, please test. Thanks, p. > > Thanks. I'm trying to build HEAD, but it's failing test43: > >>>>>> ./scripts/test043-delta-syncrepl failed (exit 1) > make[2]: *** [bdb-mod] Error 1 > make[2]: Leaving directory `/anything/src/openldap/ldap/tests' > make[1]: *** [test] Error 2 > make[1]: Leaving directory `/anything/src/openldap/ldap/tests' > make: *** [test] Error 2 > > [ghenry@suretec testrun]$ diff -urN server1.out server2.out > --- server1.out 2008-11-20 20:49:08.000000000 +0000 > +++ server2.out 2008-11-20 20:49:08.000000000 +0000 > @@ -151,7 +151,7 @@ > contextCSN: 20081120204853.248356Z#000000#000#000000 > entryDN: dc=example,dc=com > subschemaSubentry: cn=Subschema > -auditContext: cn=log > +hasSubordinates: TRUE > > dn: cn=Gern Jensen,ou=Information Technology Division,ou=People,dc=example,dc= > com > > Anyone else seeing this? > Working 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

----- "Pierangelo Masarati" <ando(a)sys-net.it> wrote: > ghenry(a)OpenLDAP.org wrote: > > > I've just hit this: > > > > /usr/local/sbin/slapacl -f /usr/local/etc/openldap/slapd.conf -b > > "dc=suretecsystems,dc=com" -U ghenry "userPassword/read:" > > authcDN: "uid=ghenry,cn=auth" > > read access to userPassword=: DENIED > > Segmentation fault > > Fixed in HEAD, please test. Thanks, p. Thanks. I'm trying to build HEAD, but it's failing test43: >>>>> ./scripts/test043-delta-syncrepl failed (exit 1) make[2]: *** [bdb-mod] Error 1 make[2]: Leaving directory `/anything/src/openldap/ldap/tests' make[1]: *** [test] Error 2 make[1]: Leaving directory `/anything/src/openldap/ldap/tests' make: *** [test] Error 2 [ghenry@suretec testrun]$ diff -urN server1.out server2.out --- server1.out 2008-11-20 20:49:08.000000000 +0000 +++ server2.out 2008-11-20 20:49:08.000000000 +0000 @@ -151,7 +151,7 @@ contextCSN: 20081120204853.248356Z#000000#000#000000 entryDN: dc=example,dc=com subschemaSubentry: cn=Subschema -auditContext: cn=log +hasSubordinates: TRUE dn: cn=Gern Jensen,ou=Information Technology Division,ou=People,dc=example,dc= com Anyone else seeing this? -- 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 hyc＠symas.com 20 Nov '08

20 Nov '08

Russ Allbery wrote: > My impression is that the broader Kerberos community is increasingly > leaning towards not doing DNS canonicalization. That Kerberos libraries > have been canonicalizing hostnames using DNS for quite some time is > certainly true, but it's considered an unfortunate bug that needs to be > supported for backward compatibility but that is clearly not the right way > to do things. This is the reason why Kerberos implementations are > increasingly adding options to disable DNS canonicalization. > > (1) is a vulnerability that Kerberos can protect against if you use it > properly. It's called the Zanarotti attack, and the way that you defend > against it is by obtaining a service ticket for a principal in a local > keytab after initial authentication and verifying that the service ticket > matches. This uses your shared secret with the KDC to verify that you're > talking to the right KDC. 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. Delegating the trust to the KDC obviously doesn't solve this problem. (Not to mention that again, a KDC is by definition a trusted 3rd party. If you can't trust it, then the entire Kerberos framework is compromised.) > Your analysis of (2) assumes that every ldap principal in your KDC is > created by someone you trust not to spoof any other ldap principal in your > KDC. Yes, again, that is implicit in the fact that the KDC is a trusted 3rd party. > That's a high bar to meet and many sites are not going to meet that > bar, nor want to given a competing desire for distributed administration. 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. > For example, Stanford allows students to run Kerberized services on their > personal computers if they wish, and therefore allows them to download > keytabs (and hence create ldap principals) for those computers. If they > can use DNS hijacking to return a CNAME for an LDAP server pointing to > their computer instead, they can obtain a legitimate keytab for the ldap > principal for that computer, and can successfully trick a client that > trusts DNS canonicalization. Trust within a realm is all-or-nothing. And of course, Kerberos trust is transitive... But the right way to handle regions under different administrative control is to place them in separate realms. For your example of students creating their own principals, independently from the centrally administered realm, you should be using a separate realm (and setup a cross-realm trust if that's appropriate.) That at least gives you consistent accountability, and you can uniformly limit the privileges granted to tickets from non-default realms. > Another, possibly more obvious case where (2) doesn't hold is in the > presence of cross-realm trust. If I can use DNS spoofing to return a > CNAME of ldap.stanford.edu to dorm-machine.mit.edu, and stanford.edu and > ATHENA.MIT.EDU have cross-realm trust, I can perform the same attack. So > you not only have to trust everyone who can create ldap principals in your > local realm, but everyone who can create ldap principals in any realm with > which you have cross-realm trust. Yes, and again, that is basic to the definition of Kerberos. If you don't actually trust everyone, then you should not be adding them into your KDC, because their presence in the KDC is a declaration of trust. Garbage-in-garbage-out applies here. > There are a lot of nasty things that you can do with DNS spoofing, and > this almost certainly isn't the most likely attack, but it is a potential > vulnerability that's been widely discussed within the Kerberos community, > including transition plans for how to get away from always doing > canonicalization. You can, for example, see part of the opinion of the > MIT developers in the comments around the relevant segment of code: > > if (maybe_use_reverse_dns(context, DEFAULT_RDNS_LOOKUP)) { > /* > * Do a reverse resolution to get the full name, just in > * case there's some funny business going on. If there > * isn't an in-addr record, give up. > */ > /* XXX: This is *so* bogus. There are several cases where > this won't get us the canonical name of the host, but > this is what we've trained people to expect. We'll > probably fix it at some point, but let's try to > preserve the current behavior and only shake things up > once when it comes time to fix this lossage. */ > > This is the reason why there's an rdns option in krb5.conf to disable this > code. There has been other discussion of it on krbdev and > kerberos(a)mit.edu in the past. > > I would agree that there's no way that you can change the default; too > much stuff would break. That's also why the Kerberos libraries continue > to do this by default. But I think the original bug reporter isn't > unreasonable for wanting a way to disable canonicalization if they know > that their code and environment will handle that appropriately. You've already proven that the option being discussed here is *not appropriate* because a non-local KDC cannot be trusted. So once again, solve the real problem. What's been proposed here is not a solution. -- -- 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

rra(a)stanford.edu writes: > (1) is a vulnerability that Kerberos can protect against if you use it > properly. It's called the Zanarotti attack, and the way that you defend > against it is by obtaining a service ticket for a principal in a local > keytab after initial authentication and verifying that the service > ticket matches. I'm sorry -- this is wrong. I overthought this. The scenario discussed here is not the Zanarotti attack. The Zanarotti attack involves spoofing the KDC so that you don't have to know the correct key for a principal; you instead use a key that you know and fool the system into talking to a KDC that uses the same key. It's an attack on login or a screen saver to allow someone to use a bogus password to authenticate. The protection against the scenario (1) listed here is integral into the Kerberos protocol. The Kerberos authentication process involves requesting a TGT from the KDC that's encrypted in your private key and then decrypting the return with your private key. You cannot spoof Kerberos initial authentication from a keytab or a correct password by using DNS to redirect the authentication to a bogus KDC because the bogus KDC won't know your correct private key and hence won't be able to return a TGT that you can decrypt. Similarly, you can't successfully redirect a TGS_REQ to a bogus KDC because that KDC doesn't have the private key and can't complete the protocol exchange. This is why kinit doesn't bother to protect against the Zanarotti attack; there's no need, since kinit doesn't provide increased local privileges and the Zanarotti attack is an attack only on the local system, not against a network service. -- Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>

1 0

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

20 Nov '08

hyc(a)symas.com writes: > In the meantime, the arguments about secure DNS are pure red herrings: > 1. if your DNS has been hijacked, it's most likely that you'll be > directed to a rogue KDC first, so the question of which service you're > talking to is moot. > 2. there's nothing to gain from directing you to a rogue service, since if > you managed to contact the legitimate KDC, you're going to have a service > ticket that can only be decoded by the legitimate service principal. > On the other hand, if the rogue service is actually a valid principal in > your trusted KDC's database, then you clearly have an administrative problem > in your KDC. > > This patch attempts to provide a band-aid without actually solving the > real problem. It merely masks the problem temporarily, until it gets > even worse. My impression is that the broader Kerberos community is increasingly leaning towards not doing DNS canonicalization. That Kerberos libraries have been canonicalizing hostnames using DNS for quite some time is certainly true, but it's considered an unfortunate bug that needs to be supported for backward compatibility but that is clearly not the right way to do things. This is the reason why Kerberos implementations are increasingly adding options to disable DNS canonicalization. (1) is a vulnerability that Kerberos can protect against if you use it properly. It's called the Zanarotti attack, and the way that you defend against it is by obtaining a service ticket for a principal in a local keytab after initial authentication and verifying that the service ticket matches. This uses your shared secret with the KDC to verify that you're talking to the right KDC. Software such as PAM modules that do Kerberos authentications do this check as a matter of course. Once you've done that, further communication with the KDC is done using the session keys in your TGT, and a hijacked KDC won't be able to complete the protocol exchange because it can't decrypt the TGT. kinit and similar programs currently don't do this check by default, but there's no reason why they couldn't if an appropriate keytab is available. Your analysis of (2) assumes that every ldap principal in your KDC is created by someone you trust not to spoof any other ldap principal in your KDC. That's a high bar to meet and many sites are not going to meet that bar, nor want to given a competing desire for distributed administration. For example, Stanford allows students to run Kerberized services on their personal computers if they wish, and therefore allows them to download keytabs (and hence create ldap principals) for those computers. If they can use DNS hijacking to return a CNAME for an LDAP server pointing to their computer instead, they can obtain a legitimate keytab for the ldap principal for that computer, and can successfully trick a client that trusts DNS canonicalization. Another, possibly more obvious case where (2) doesn't hold is in the presence of cross-realm trust. If I can use DNS spoofing to return a CNAME of ldap.stanford.edu to dorm-machine.mit.edu, and stanford.edu and ATHENA.MIT.EDU have cross-realm trust, I can perform the same attack. So you not only have to trust everyone who can create ldap principals in your local realm, but everyone who can create ldap principals in any realm with which you have cross-realm trust. There are a lot of nasty things that you can do with DNS spoofing, and this almost certainly isn't the most likely attack, but it is a potential vulnerability that's been widely discussed within the Kerberos community, including transition plans for how to get away from always doing canonicalization. You can, for example, see part of the opinion of the MIT developers in the comments around the relevant segment of code: if (maybe_use_reverse_dns(context, DEFAULT_RDNS_LOOKUP)) { /* * Do a reverse resolution to get the full name, just in * case there's some funny business going on. If there * isn't an in-addr record, give up. */ /* XXX: This is *so* bogus. There are several cases where this won't get us the canonical name of the host, but this is what we've trained people to expect. We'll probably fix it at some point, but let's try to preserve the current behavior and only shake things up once when it comes time to fix this lossage. */ This is the reason why there's an rdns option in krb5.conf to disable this code. There has been other discussion of it on krbdev and kerberos(a)mit.edu in the past. I would agree that there's no way that you can change the default; too much stuff would break. That's also why the Kerberos libraries continue to do this by default. But I think the original bug reporter isn't unreasonable for wanting a way to disable canonicalization if they know that their code and environment will handle that appropriately. -- 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

ghenry(a)OpenLDAP.org wrote: > I've just hit this: > > /usr/local/sbin/slapacl -f /usr/local/etc/openldap/slapd.conf -b > "dc=suretecsystems,dc=com" -U ghenry "userPassword/read:" > authcDN: "uid=ghenry,cn=auth" > read access to userPassword=: DENIED > Segmentation fault Fixed in HEAD, please test. Thanks, 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#5821 Small mistake in man page
by ando＠sys-net.it 20 Nov '08

20 Nov '08

Fixed in HEAD; please check. Thanks, 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

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