[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87ziazjhca.fsf@fifthhorseman.net>
Date: Wed, 16 Aug 2017 18:08:53 -0400
From: Daniel Kahn Gillmor <dkg@...thhorseman.net>
To: Russ Allbery <eagle@...ie.org>, Florian Weimer <fweimer@...hat.com>
Cc: oss-security@...ts.openwall.com
Subject: Re: Insecure DNS dependency in many Kerberos deployments
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.
> This is a much higher bar to meet, and in a lot of organizations this
> bar cannot be easily met by an attacker.
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".
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.
> 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 :)
--dkg
Download attachment "signature.asc" of type "application/pgp-signature" (833 bytes)
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.
