[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <87fvw2dl74.fsf@alice.fifthhorseman.net>
Date: Fri, 28 Jun 2013 16:39:11 -0400
From: Daniel Kahn Gillmor <dkg@...thhorseman.net>
To: Kurt Seifried <kseifried@...hat.com>, oss-security@...ts.openwall.com
Cc: Vincent Danen <vdanen@...hat.com>, Ghe Rivero <ghe@...ian.org>, Mike Hommey <glandium@...ian.org>
Subject: general Krb5 DNS vulnerabilities (e.g. krb5 web auth)? [was: Re: CVE request: rpc-gssd is vulnerable to DNS spoofing]
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@...ce:~$ klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: dkg@...MPLE.COM
Valid starting Expires Service principal
28/06/2013 10:32 29/06/2013 01:32 krbtgt/EXAMPLE.COM@...MPLE.COM
renew until 29/06/2013 10:32
0 dkg@...ce:~$
[ 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@...ce:~$ klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: dkg@...MPLE.COM
Valid starting Expires Service principal
28/06/2013 10:32 29/06/2013 01:32 krbtgt/EXAMPLE.COM@...MPLE.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@...MPLE.COM
renew until 29/06/2013 10:32
0 dkg@...ce:~$
-------------------------
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
Content of type "application/pgp-signature" skipped
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.
