hyc@symas.com writes:
In the meantime, the arguments about secure DNS are pure red herrings:
- 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@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.