The default bug view has changed. See this FAQ.

DNS rebinding vulnerabilities in plug-ins

RESOLVED FIXED

Status

()

Core
Networking
P2
normal
RESOLVED FIXED
10 years ago
9 years ago

People

(Reporter: chris hofmann, Unassigned)

Tracking

unspecified
x86
Windows XP
Points:
---
Bug Flags:
blocking1.9 +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:want], URL)

Attachments

(1 attachment)

(Reporter)

Description

10 years ago
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.
(Reporter)

Comment 1

10 years ago
additional info at
http://blogs.msdn.com/dross/archive/2007/07/09/notes-on-dns-pinning.aspx
http://christ1an.blogspot.com/2007/07/dns-pinning-explained.html
http://www.darkreading.com/document.asp?doc_id=129431&f_src=darkreading_informationweek
(Reporter)

Comment 2

10 years ago
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

10 years ago
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

10 years ago
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

10 years ago
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).
Group: security
(Reporter)

Comment 6

10 years ago
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

10 years ago
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?
(Reporter)

Comment 8

10 years ago
trying for the round table on DNS rebinding on 9/5
(Reporter)

Comment 9

10 years ago
at 1pm pacific

Comment 10

10 years ago
Great.  I'll be there, and I believe Collin Jackson will be as well.
doubt there is a decent solution without the performance penalty of an additional dns query

Comment 12

10 years ago
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

10 years ago
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

10 years ago
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.
Flags: blocking1.9?
Whiteboard: [sg:want]

Updated

10 years ago
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2

Comment 15

9 years ago
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/
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Summary: DNS rebinding vulnerability → DNS rebinding vulnerabilities in plug-ins
You need to log in before you can comment on or make changes to this bug.