Closed Bug 389625 Opened 18 years ago Closed 17 years ago

DNS rebinding vulnerabilities in plug-ins

Categories

(Core :: Networking, defect, P2)

Product:
Core
Component:
Networking
Platform:
x86
Windows XP
Type:
defect

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: chofmann, Unassigned)

References

(
URL
)

Details

(Whiteboard: [sg:want])

Attachments

(1 file)

Patch for Firefox 3 (NSPR 4.7) by Adam Barth
5.87 KB, patch
Details | Diff | Splinter Review
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.
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.
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?
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.)
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
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.
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?
trying for the round table on DNS rebinding on 9/5
at 1pm pacific
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
I applied the patch that Adam mentioned in comment 7 to the Firefox/NSPR trunk.
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.
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]
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2
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/
URL: http://www.acm.org/sigs/sigsac/ccs/CC... → http://crypto.stanford.edu/dns/
Status: NEW → RESOLVED
Closed: 17 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.

Attachment

General

Creator:
Created:
Updated:
Size: