general Krb5 DNS vulnerabilities (e.g. krb5 web auth)? [was: Re: [oss-security] CVE request: rpc-gssd is vulnerable to DNS spoofing]

[Daniel Kahn Gillmor <dkg () fifthhorseman net>]

On Thu 2013-04-04 13:01:13 -0400, Kurt Seifried wrote:

> On 04/03/2013 04:43 PM, Vincent Danen wrote:
> > This has been discussed on the linux-nfs mailing list, so fully
> > public. Just cutting and pasting from our bugzilla:
> >
> > It was reported [1],[2] that rpc.gssd in nfs-utils is vulnerable to
> > DNS spoofing due to it depending on PTR resolution for GSSAPI 
> > authentication.  Because of this, if a user where able to poison
> > DNS to a victim's computer, they would be able to trick rpc.gssd
> > into talking to another server (perhaps with less security) than
> > the intended server (with stricter security).  If the victim has
> > write access to the second (less secure) server, and the attacker
> > has read access (when they normally might not on the secure
> > server), the victim could write files to that server, which the
> > attacker could obtain (when normally they would not be able to).
> > To the victim this is transparent because the victim's computer
> > asks the KDC for a ticket to the second server due to reverse DNS
> > resolution; in this case Krb5 authentication does not fail because
> > the victim is talking to the "correct" server.
> >
> > A patch that prevents this issue has been posted [3].
> >
> > To workaround this issue, set the IP/host pair in /etc/hosts so
> > that it cannot be spoofed.
> >
> > A good explanation is also available here [4].
> >
> > [1] http://marc.info/?l=linux-nfs&m=136491998607561&w=2 [2]
> > http://marc.info/?l=linux-nfs&m=136500502805121&w=2 [3]
> > http://marc.info/?l=linux-nfs&m=136493115612397&w=2 [4]
> > http://ssimo.org/blog/id_015.html
> >
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=948072
> >
> >
> > Since this is fairly new, I don't think a CVE would have been
> > requested already.  Could one be assigned to this?
>
> Please use CVE-2013-1923 for this issue.

I'm wondering if this isn't actually a larger issue, outside of NFS.
For example, when i use SPNEGO/Negotiate authentication in a
firefox/iceweasel browser to foo.example.com, firefox appears to
normalize the request via a DNS reverse lookup before requesting a krb5
ticket.

-------------------------
0 dkg@alice:~$ klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: dkg () EXAMPLE COM

Valid starting    Expires           Service principal
28/06/2013 10:32  29/06/2013 01:32  krbtgt/EXAMPLE.COM () EXAMPLE COM
        renew until 29/06/2013 10:32
0 dkg@alice:~$ 

 [ then i point my browser (debian iceweasel 22.0-1, maintainer Cc'ed
   here) at http://foo.example.com/login, which does WWW Negotiate
   authentication, but the PTR record refers to bar.example.com ]

0 dkg@alice:~$ klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: dkg () EXAMPLE COM

Valid starting    Expires           Service principal
28/06/2013 10:32  29/06/2013 01:32  krbtgt/EXAMPLE.COM () EXAMPLE COM
        renew until 29/06/2013 10:32
28/06/2013 15:02  29/06/2013 01:32  HTTP/bar.example.com@
        renew until 29/06/2013 10:32
28/06/2013 15:02  29/06/2013 01:32  HTTP/bar.example.com () EXAMPLE COM
        renew until 29/06/2013 10:32
0 dkg@alice:~$ 
-------------------------


On the server side, using debian's libapache2-mod-kerb 5.4-2 (maintainer
cc'ed as well), apache does a reverse lookup on its own virtualhost name
(confirmed by observing traffic with tcpdump).

So it seems like the same argument used above for NFS applies to the
web/negotiate/spnego/gssapi/krb5 use case: an attacker capable of
poisoning the DNS and intercepting traffic could make an authenticated
victim do something on server A while thinking that they were
manipulating server B, based on their kerberos credentials.

Is it possible that this is a bigger problem that needs to be addressed
at the krb5 level?  iirc, reverse DNS has traditionally been a known
point of concern for krb5 deployments, but maybe the specific attacks
just haven't been explicitly articulated or identified as a problem?

I might also be confused; feel free to point me to corrective material.

  --dkg

Attachment: _bin
Description: