Java Implementations Can Allow Connections to an Arbitrary Host
Last revised: September 24, 1997
Updated copyright statement
A complete revision history is at the end of this file.
The CERT Coordination Center has received reports of a vulnerability in implementations of the Java Applet Security Manager. This vulnerability is present in the Netscape Navigator 2.0 Java implementation and in Release 1.0 of the Java Developer's Kit from Sun Microsystems, Inc. These implementations do not correctly implement the policy that an applet may connect only to the host from which the applet was loaded.
The CERT Coordination Center recommends installing patches from the vendors, and using the workaround described in Section III until patches can be installed.
We will update this advisory as we receive additional information. Please check advisory files regularly for updates that relate to your site.
As a clarification to our readers, this problem is different from the problem described in advisory CA-96.05.
I. DescriptionThere is a serious security problem with the Netscape Navigator 2.0 Java implementation. The vulnerability is also present in the Java Developer's Kit 1.0 from Sun Microsystems, Inc. The restriction allowing an applet to connect only to the host from which it was loaded is not properly enforced. This vulnerability, combined with the subversion of the DNS system, allows an applet to open a connection to an arbitrary host on the Internet.
In these Java implementations, the Applet Security Manager allows an applet to connect to any of the IP addresses associated with the name of the computer from which it came. This is a weaker policy than the stated policy and leads to the vulnerability described herein.
II. ImpactJava applets can connect to arbitrary hosts on the Internet, including those presumed to be previously inaccessible, such as hosts behind a firewall. Bugs in any TCP/IP-based network service can then be exploited. In addition, services previously thought to be secure by virtue of their location behind a firewall can be attacked.
III. SolutionTo fix this problem, the Applet Security Manager must be more strict in deciding which hosts an applet is allowed to connect to. The Java system needs to take note of the actual IP address that the applet truly came from (getting that numerical address from the applet's packets as the applet is being loaded), and thereafter allow the applet to connect only to that same numerical address.
We urge you to obtain vendor patches as they become available. Until you can install the patches that implement the more strict applet connection restrictions, you should apply the workarounds described in each section below.
A. Netscape usersFor Netscape Navigator 2.0, use the following URL to learn more about the problem and how to download and install a patch:
Until you install the patch, disable Java using the "Security Preferences" dialog box.
B. Sun usersA patch for Sun's HotJava will be available soon.
Until you can install the patch, disable applet downloading by selecting "Options" then "Security...". In the "Enter desired security mode" menu, select the "No access" option.
In addition, select the "Apply security mode to applet loading" to disable applet loading entirely, regardless of the source of the applet.
C. Both Netscape and Sun usersIf you operate an HTTP proxy server, you could also disable applets by refusing to fetch Java ".class" files.
The CERT Coordination Center thanks Drew Dean, Ed Felton, and Dan Wallach of Princeton University for providing information for this advisory. We thank Netscape Communications Corporation, especially Jeff Truehaft, and Sun Microsystems, Inc., especially Marianne Mueller, for their response to this problem.
Copyright 1996 Carnegie Mellon University.