Closed Bug 385180 Opened 17 years ago Closed 13 years ago

problematic nature of the fact that Firefox allows cross-port communication using the Java Socket class supported by LiveConnect

Categories

(Core Graveyard :: Java: Live Connect, defect)

Product:
Core Graveyard
Component:
Java: Live Connect
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE

People

(Reporter: asharabani, Unassigned)

Details

(Keywords: arch, Whiteboard: [sg:investigate] Java security policy) 

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4

Firefox allows cross-ports communication using the Java Socket class. It is possible to initialize and use the Java Socket class via JavaScript thanks to the fact Firefox supports LiveConnect [1].

While this behavior doesn't seem to have a significant security impact in Internet web environment, it endangers the desktop web environment - the localhost domain / 127.0.0.1 IP address. 

Cross-ports communication in localhost/127.0.0.1 is problematic. It can allow a malicious attacker to break the important distinction between different applications and their resources.
Once gaining control over one web-application listening to localhost network interface, an attacker might be able to leverage his/her attack by accessing and even altering content of other applications installed on the attacked system.

One of the vital responsibilities of a web browser is to make sure data leakage is prevented.

Nowdays computers contain many applications/services that run local servers - both web and non-web.

Applications that run a local web server:
•	Google Desktop
•	SharpReader - popular RSS reader
•	Security Scanners
•	Visual Studio
•	More…

Services that run a local server:
•	Windows Services (RPC, SMB, etc.)
•	Anti-viruses
•	FTP
•	Mail Servers
•	Etc.

One web server shouldn’t be able to gather inforation from another one.
In addition, access of JavaScript code to local non-servers is very dangerous and should be blocked. A malicious attacker could exploit such access into sensitive information leakage and even system control. 


Reproducible: Always

Steps to Reproduce:
The following code snippet generates cross-ports communication between 2 non-related servers on locahost.

http://127.0.0.1:A_PORT/mal_script.htm:

<html>
	<body>
	<script>
	var sock = new java.net.Socket("127.0.0.1", ___SOME_PORT___);
	var write = new java.io.DataOutputStream(new java.io.BufferedOutputStream(sock.getOutputStream()));
	var reader = new java.io.BufferedReader(new java.io.InputStreamReader(sock.getInputStream()));
	// Send data to the server.
	write.writeBytes(___DATA_TO_SEND___);
	write.flush();
	
	// Read the server’s response....

	// Close connection.
	write.close();
	reader.close();
	sock.close();
	</script>
	</body>
</html>





Actual Results:  
The fact cross-ports communication is allowed in localhost/127.0.0.1 is problematic. It can allow a malicious attacker to break the important distinction between different applications and their resources.

An attack scenario that can take advantage of this behavior:
Let Application A be an application running a local web server listening on port A.
Let Application B be an application running a local server listening on port B.
The servers that listen on ports A and B are bound to localhost for security reasons, disallowing communication from outside the local computer.

Let’s assume Application A is susceptible to XSS [2].
Let’s assume Application B manages sensitive information (Accounting application, SMB service, RPC service, etc.).

1.	Attacker exploits the XSS vulnerability in Application A.
2.	Attacker injects a malicious cross-ports communication script, issuing requests and reading the relevant responses from port B (see “Technical Details” section).
3.	Sensitive information from Application B is hijacked.

 
Although Application B is bullet-proof security-wise by itself and might even be protected by a corporate firewall, its security and resources can still be compromised by taking advantage the promiscious nature of the Java Socket object in localhost/127.0.0.1.



Watchfire develops Web Application Security testing products and has a resident security research team that continually explores where prevalent web applications and servers may be vulnerable.

As per our vulnerability disclosure policy, we are contacting you regarding a discovery made by our research team that shows the problematic nature of the fact that Firefox allows cross-port communication using the Java Socket class supported by LiveConnect.

The person that should be credited for this research is Yair Amit.

After the issue is accepted by Mozilla we would like to post the advisory. You should note that while the advisory is mainly technical information, we would be sure to emphasize that Mozilla was responsive to vulnerabilities and is committed to the security and protection of their end users.

Please let us know who we should follow-up with details of the security issue.

Kind Regards,

-Adi Sharabani
Manager, Security and Research
Watchfire Corporation
+972-9-958-6077 Ext. 231
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.
Group: security
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: arch
Whiteboard: [sg:nse] Java security policy → [sg:investigate] Java security policy
(In reply to comment #4)
> 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.
Hello Daniel,

Thank you for your remarks.

I would like to clarify the attack flow and by that answer your questions.
In order for the attack to take place, there is no need for an attacker to hack the local web server of the victim.
All an attacker has to do is to exploit an XSS on a local web server.

XSS vulnerabilities are very common in all kinds of web-applications. Our research has shown that many nowadays local web-applications are susceptible to XSS as well.
During our research, we have found various examples for XSS vulnerable local web-applications. The most notable public example is the attack against Google Desktop that was described in Watchfire's whitepaper "Overtaking Google Desktop". Please refer to http://download.watchfire.com/whitepapers/Overtaking-Google-Desktop.pdf for more information.

Once the attacker exploits the XSS vulnerability, he/she is able to insert a malicious JavaScript code. This code can create a Java Socket using LiveConnect and then connect and communicate with any service listening to a port (including non-HTTP based services) on the victim's computer (SMB, Local Web Proxy's, FTP, Mail, etc...). 
The impact of such attack is information theft from the victim's computer (and in some cases from the whole intranet) and even remote command execution.
The reason this attack works is that everything "fits". By using LiveConnect, it is possible to dynamically create a Java Applet under the same domain (localhost) of the vulnerable web-application.

I would like to emphasize that this attack is different than Anti DNS Pinning. Anti DNS Pinning exploits an implementation flaw in order to circumvent the same-origin policy embedded into browsers and their plug-ins (Flash / Java Applets etc.) and access various domains and ports.
The attack described above starts and ends in the same domain and therefore is not limited in anyway by the browser / same origin policy mechanism.

We believe that by disallowing cross-ports access using the Java Socket in localhost, this attack can be mitigated and therefore we recommend to consider changing the implementation of LiveConnect to reflect this change.

Watchfire hasn't published any details regarding the attack so far due to our responsible disclosure policy.
Our policy is to refrain from publishing attacks before a patch is available.

Best Regards,
	Yair Amit
	Security Team
	Watchfire, an IBM company
Flags: wanted1.8.1.x+
Flags: blocking1.8.1.11?
Flags: blocking-firefox3?
--> Core::Plugins
Component: Security → Plug-ins
Flags: blocking-firefox3?
Product: Firefox → Core
QA Contact: firefox → plugins
--> Core::Java LiveConnect, even

transferring nomination to blocking 1.9?
Component: Plug-ins → Java: Live Connect
Flags: blocking1.9?
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: blocking1.8.1.12? → blocking1.8.1.12+
Moving this out to the next release.
Flags: blocking1.8.1.13+
Flags: blocking1.8.1.12-
Flags: blocking1.8.1.12+
Moving this out again.
Flags: blocking1.8.1.14+
Flags: blocking1.8.1.13-
Flags: blocking1.8.1.13+
Assignee: dveditz → nobody
Flags: wanted1.9.0.x?
Flags: blocking1.8.1.16?
Flags: blocking1.8.1.15+
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.
Flags: wanted1.9.1?
Flags: blocking1.9.1?
Flags: blocking1.8.1.17?
In the new NPRuntime Java Plug-In we already model incoming calls from JavaScript as though they were coming from an unsigned applet whose codebase is equivalent to the document base. This means that unless the document came from localhost the JavaScript code will not be allowed to open a socket to connect to localhost.

I've asked other members of the plug-in team to look at this issue. I recall we fixed something in this area recently.

The attack scenario assumes the document did, in fact, come from localhost (perhaps an XSS flaw or SQL injection against a local service).

It's much easier to inject JavaScript than to inject a Java Applet, there's a good case to be made that LiveConnect calls ought to be treated differently than an actual applet. To be honest I wouldn't mind if you killed LiveConnect direct sockets (and a few other things) entirely, but at the very least could Java honor the browser's "same-origin" policy (scheme+host+port) for code that's coming from the LiveConnect pseudo-applet? I guess "scheme" is irrelevant to sockets, but host+port could be done.
Flags: wanted1.9.0.x?
Flags: blocking1.9.1?
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).
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
Closed: 13 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.