Re: (ITS#5812) New option to disable SASL host canonicalization

[rra@stanford.edu]

hyc@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@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@stanford.edu)             <http://www.eyrie.org/~eagle/>