Last Comment Bug 389625 - DNS rebinding vulnerabilities in plug-ins
: DNS rebinding vulnerabilities in plug-ins
Status: RESOLVED FIXED
[sg:want]
:
Product: Core
Classification: Components
Component: Networking (show other bugs)
: unspecified
: x86 Windows XP
: P2 normal with 1 vote (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: Patrick McManus [:mcmanus]
Mentors:
http://crypto.stanford.edu/dns/
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-07-25 21:14 PDT by chris hofmann
Modified: 2008-02-04 12:38 PST (History)
19 users (show)
mtschrep: blocking1.9+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Patch for Firefox 3 (NSPR 4.7) by Adam Barth (5.87 KB, patch)
2007-09-05 11:42 PDT, Wan-Teh Chang
no flags Details | Diff | Splinter Review

Description chris hofmann 2007-07-25 21:14:57 PDT
more info at URL listed above.

fix may involve broader changes beyond networking so we might want to spin off more bugs and use this as a tracking bug.
Comment 2 chris hofmann 2007-07-25 21:28:00 PDT
some notes from an earlier group session that analyzed the problem...

Their research makes them pretty confident that widespread DNS rebinding attacks are happening right now.  We encouraged them to figure out a way to try and get some metrics and they sounded interested in that.  Enabling some code that heuristically try to identify a rebinding attack might be interesting to put into nightly builds, or enable some kind of spider.

The forms of attack that seem to provide the most risk were directory navigation behind firewalls, and search click fraud.  Google and Yahoo were most interested in the click fraud angle, and Adobe and Sun were most interested in cutting off the dir navigation attacks.

Adobe seem to understand the risks in current flash versions and confident they would seal off most holes with an up coming release of the player.

The liveconnect problems could be solved by just disabling live connect.   Is that on a schedule for doing before Mozilla 2?  Could we pull this off in Firefox 3?

The research team proposed a variety of solutions to solving the problem.  The two that got the most discussion were a policy file solution where a site would show the combined names and ip's of systems that were authorized.  Adobe offered up their policy file as a system that all the other vendors might leverage.   This didn't seem to make much sense to me and I tried to steer discussion to another solution that would set up conventions for  using CNAMEs  to  validate host names against IP addresses.  This would look something like

  goodguy.host.com   CNAME  goodguy.host.com-63.245.209.11
    where
  goodguy.host.com-63.245.20.11 might resolve to  63.245.209.11
                                                                               63.245.209.12
                                                                               63.245.209.13
                                                                               63.245.209.14

A patch to browsers would check the hostname against the CNAME and if the IP address returned didn't match up to the IP address embedded in the CNAME record then the page would fail and might  provide some indication that it was under a rebinding attack.

The Stanford guys actually had a 70 line patch to Firefox that did this and we encouraged them to open a bug and attach the patch.

Dan should fill in corrections or details on my notes.
Comment 3 Jesse Ruderman 2007-07-26 00:47:44 PDT
Why is this bug report security-sensitive?  How is this different from bug 149943, which was WONTFIXed long ago?  What does that CNAME hack accomplish that checking the host header doesn't?  What are the "problems" in Flash and LiveConnect -- are they issues where the host header can be spoofed or are they being scared into using DNS pinning?
Comment 4 Adam Barth 2007-07-26 11:13:22 PDT
I'm one of the authors of the rebinding paper.  You can download it here:

http://crypto.stanford.edu/dns/

This bug is different from bug 149943 because Java applets, LiveConnect, and Flash allow socket-level access, meaning malicious web pages can forge whatever Host header they like.  For Host header checking to work, these plug-ins must default to denying socket access, which will break current applications.

Even if Flash patches their policy file processing to block these attacks and LiveConnect (or at least java.net.Socket and friends) is removed from Mozilla and Opera, users behind proxies will not be protected because Java applets loaded through a proxy are vulnerable to these attacks.

We have a proof-of-concept demonstration of all these attack vectors that we'd be happy to share with you.  (Fill out the form on our web site for a password.)
Comment 5 Jesse Ruderman 2007-08-06 15:00:25 PDT
The plugin issues have been discussed at Black Hat and DEF CON, so I'm making this bug report public.  IMO, those are plugin vulnerabilities; they're not following the web's security model (which is tied to hostnames in a specific way).
Comment 6 chris hofmann 2007-08-31 12:10:38 PDT
sounds like there are specific things like changing our default TTL, and disabling liveconnect or disabling/revising the abilty to open sockets from java via liveconnect that help to reduce some risks that might be specific to firefox users.   We should discuss more at a security roundtable next wed. at 1p pacific  - Mozilla Mt. View building K office for any and all that can make it. ( http://www.mozilla.org/contact/ )  I'll also set up a callin number for anyone interested in dailing in.

Adam, Do you know if the patch that was discussed in a previous meeting at Stanford is still working?  After more discussion it seems like the idea to recognize special CNAMEs seems less valuable, but we ought to kick that idea around a bit more to reach a conclusion.
Comment 7 Adam Barth 2007-08-31 16:39:10 PDT
We haven't tried to update the patch to the latest revision, but we'd be happy to do that if you'd like to include it.  The current version is available at:

http://crypto.stanford.edu/dns/prnetdb.c.patch

To clarify, is the security roundtable on Wednesday 9/5 or 9/12?
Comment 8 chris hofmann 2007-09-04 12:06:18 PDT
trying for the round table on DNS rebinding on 9/5
Comment 9 chris hofmann 2007-09-04 12:06:51 PDT
at 1pm pacific
Comment 10 Adam Barth 2007-09-05 00:04:54 PDT
Great.  I'll be there, and I believe Collin Jackson will be as well.
Comment 11 georgi - hopefully not receiving bugspam 2007-09-05 01:39:41 PDT
doubt there is a decent solution without the performance penalty of an additional dns query
Comment 12 Wan-Teh Chang 2007-09-05 11:42:19 PDT
Created attachment 279764 [details] [diff] [review]
Patch for Firefox 3 (NSPR 4.7) by Adam Barth

I applied the patch that Adam mentioned in comment 7 to the
Firefox/NSPR trunk.
Comment 13 Wan-Teh Chang 2007-09-05 11:59:11 PDT
Just to clarify my previous comment 12: I didn't check in Adam's patch.
I regenerated his patch against the current Firefox/NSPR trunk, with
RCS revision info, so that we can review his patch with Bugzilla's
diff viewer.
Comment 14 Adam Barth 2007-10-05 19:25:28 PDT
Sun looks to have patched the Java LiveConnect and Java applet with proxy vulnerabilities:

http://sunsolve.sun.com/search/document.do?assetkey=1-26-103078-1

LiveConnect now appears to deny socket connections unless
(1) the PTR record for the IP matches the host name OR
(2) the host name authorization records are found in reverse DNS.
Comment 15 Collin Jackson 2008-02-04 12:38:42 PST
The new issues reported in this bug are the plugin-related DNS rebinding vulnerabilities; for DNS rebinding using the browser's own DNS resolver, see bug 149943.

Adobe released a DNS rebinding fix for Flash Player on December 3, 2007:

http://www.adobe.com/devnet/flashplayer/articles/fplayer9_security.html#goal_dns

Now that the Java and Flash Player plug-ins are doing a better job of preventing Host header spoofing, servers can mitigate DNS rebinding attacks by checking Host headers. Firewalls can prevent circumvention by preventing external names from resolving to internal IP addresses:

http://code.google.com/p/google-dnswall/

Note You need to log in before you can comment on or make changes to this bug.