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 , 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 . >> >> 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 . >> >>  http://marc.info/?l=linux-nfs&m=136491998607561&w=2  >> http://marc.info/?l=linux-nfs&m=136500502805121&w=2  >> http://marc.info/?l=linux-nfs&m=136493115612397&w=2  >> 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.