[prev in list] [next in list] [prev in thread] [next in thread] 

List:       oss-security
Subject:    [oss-security] general Krb5 DNS vulnerabilities (e.g. krb5 web auth)? [was: Re: [oss-security] CVE r
From:       Daniel Kahn Gillmor <dkg () fifthhorseman ! net>
Date:       2013-06-28 20:39:11
Message-ID: 87fvw2dl74.fsf () alice ! fifthhorseman ! net
[Download RAW message or body]


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 #3 (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]