[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <874lt7awbt.fsf@hope.eyrie.org>
Date: Wed, 16 Aug 2017 17:09:58 -0700
From: Russ Allbery <eagle@...ie.org>
To: Daniel Kahn Gillmor <dkg@...thhorseman.net>
Cc: Florian Weimer <fweimer@...hat.com>, oss-security@...ts.openwall.com
Subject: Re: Insecure DNS dependency in many Kerberos deployments
Daniel Kahn Gillmor <dkg@...thhorseman.net> writes:
> On Wed 2017-08-16 10:52:54 -0700, Russ Allbery wrote:
>> Florian Weimer <fweimer@...hat.com> writes:
>>> As a rule of thumb, the impact is similar to running TLS with CA-based
>>> certificate validation, but without host name checks (but perhaps
>>> slightly less because the trust domains could be much smaller).
>> I think this overstates the impact somewhat. This is more worrisome
>> with TLS because for most TLS applications there is a single global
>> trust domain with certificates issued by dozens or hundreds of parties
>> and no organizational scoping.
> fwiw, I think that's what Florian means by his parenthetical aside.
Yes, apologies, I should have noted that.
> While i understand the desire to be clear about the constrained scope of
> the risk, i think another way of saying what you're saying is "control
> over one service in a domain and the ability to poison the DNS allows
> that service operator to masquerade as any other service in the domain".
Well, it has to be a service of the same type. If you can control the key
for host/foo.example.com and poison DNS, you can masquerade as
host/bar.example.com, but it does you no good for masquerading as
nfs/bar.example.com. But yes, certainly still a bad thing.
> Even for domains where a single administrator controls all machines,
> this violates principles of privilege separation that admins rely on to
> be able to deploy potentially-buggy services without putting the other
> services at risk.
> So i think it's worth taking this seriously, despite(?) its age and
> widespread deployment.
Oh, certainly, I agree.
>> For the record, those are settings for *a* Kerberos client library, not
>> *the* Kerberos client library (specifically, the MIT Kerberos
>> implementation). Heimdal does not use those settings, and there are
>> other Kerberos implementations as well.
> The fact that some client libraries *don't* do this should give us hope
> that it's fixable, even in existing deployments :)
Well... I'm not making the assertion that the implementations don't do
this, only that they don't support the same configuration options. I
haven't verified how Heimdal handles DNS canonicalization, only that it
doesn't use those krb5.conf options. It's more of an aside to warn people
that just turning off those options may not be adequate.
--
Russ Allbery (eagle@...ie.org) <http://www.eyrie.org/~eagle/>
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
