This sounds like a bug (or differing security model) in Java rather than a problem in Firefox. I've been suspicious of Java's port promiscuity for years. Btw, I get the impression that lots of Java applets in the wild take advantage of being able to connect to other ports, so it might be hard for the Java people to change its security model.
Adi: have you contacted Sun about this problem also? Gerv
(In reply to comment #2) > Adi: have you contacted Sun about this problem also? > > Gerv > Yes we have (Have not heard back yet). I believe that they might say there is no use for socket objects when restricted to the web-server port. Anyway, the impact of this vulnerability is the same impact as DNS Pinning, which is a different attack that overcomes same domain policy. The DNS Pinning attack is already known to the public, and our new attack does not pose a threat that didn't exist before. We plan to disclose our attack next week and feel comfortable with the browsers fixing it in a future date.
The LiveConnect aspect of this doesn't make it much different than what could be done with a Java applet, though it does mean you can do this with one file rather than having to get two saved locally (the html page and the applet). This also assumes the local web server was hacked to include this mal-script, and if that was possible what kind of access does the attacker have? There seems very little Firefox can actually do to fix this since the port promiscuity problem is with Java (and now, Flash 9). We could remove LiveConnect (there's been talk of doing so for non-security reasons) but that doesn't really solve the problem. "next week" was a month ago but I don't see any advisories on www.watchfire.com newer than June 2007, and no whitepapers newer than 2006. Was this actually disclosed? I think we should unhide this bug and warn people against using Java, but I think we need to mark this bug INVALID since it's the explicit design of Java that's the issue here.
Whiteboard: [sg:nse] Java security policy
I'm unhiding the bug, this is by now fairly well known including mention at a couple of high-profile DNS-Rebinding Attack talks at BlackHat this summer.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: [sg:nse] Java security policy → [sg:investigate] Java security policy
Component: Security → Plug-ins
Product: Firefox → Core
QA Contact: firefox → plugins
--> Core::Java LiveConnect, even transferring nomination to blocking 1.9?
Component: Plug-ins → Java: Live Connect
QA Contact: plugins → live-connect
It doesn't make much sense to disable this in liveconnect if you can simply do the same thing in an applet. So I'd say this has to be fixed in the Java implementation. I agree it's bad though, but in order to fix it properly we need to get Sun on it.
Flags: blocking1.9? → blocking1.9-
Assignee: nobody → dveditz
Flags: blocking18.104.22.168? → blocking22.214.171.124+
Moving this out to the next release.
Moving this out again.
Assignee: dveditz → nobody
Johnny: is this something we could fix/change for Firefox 3.1? blocking socket connections full-stop is likely to break things. Kenneth: could Java make a distinction between applet socket connections and LiveConnect-opened sockets, and apply a stricter "same-origin" rule to socket connections that aren't made by an actual applet? I don't think there's any way for the browser to make that kind of distinction, the best we could do is block access to those packages and that breaks the whole feature.
We'll work on this. I've filed a bug to track this issue on our side -- however it isn't public so the bug ID won't help much (contact me via email if you would like it).
Component: Java: Live Connect → Java: Live Connect
Product: Core → Core Graveyard
Firefox code moved from custom Liveconnect code to the NPAPI/NPRuntime bridge a while back. Mass-closing the bugs in the liveconnect component which are likely invalid. If you believe that this bug is still relevant to modern versions of Firefox, please reopen it and move it the "Core" product, component "Plug-Ins".
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.