Java Developers Kit, Version 1.0.2
A bug in the implementation of the classloader could be exploited by an applet to create a class loader. Given the ability to create a class loader, an applet could potentially subvert the applet security sandbox in a number of ways. The researchers at Princeton demonstrated a way for an applet to use the rogue class loader to subvert the type system, generate machine code, jump to the newly generated code, and execute the newly generated code.
This classloader bug was published on the internet on March 22, 1996, by Ed Felten, Drew Dean, and Dan Wallach.
In a network where hosts inside the firewall cannot get IP information about hosts outside the firewall, applets will by default be unable to initiate network connections to outside hosts. This includes retrieving files (animator), querying its server for information (stock tickers) and retrieving additional class files (sort demo). This is also the default policy in Netscape Navigator 2.01 and 2.02.
If you are running a browser behind a firewall and you can't run applets, there are three possible workarounds you can try. JavaSoft is actively working on a better, long-term solution to the problem of providing secure DNS name resolution.
codebase
parameter of the applet HTML tag. For example, if the Java
.class file for the Animator applet resides on a computer with the
IP address 123.123.123.123, then an HTML tag like this should enable
you to access the applet:
<applet code=Animator codebase="123.123.123.123" height=10
width=10> </applet>
trustProxy, when set to
true, enables applets to connect to their host of origin even when the
numerical IP address of the host cannot be determined. This approach
should only be taken if there is reason to believe that the proxy
server always maps a given hostname to the same IP address, or if
the risk of this attack is acceptable to your network administrator.
Netscape Navigator does not read the ~/.hotjava/properties file, so
setting the trustProxy switch will not affect the
behavior of NN2.01 or NN2.0.2.
Refer to the Security FAQ for more details on the DNS-related attacks, fixes, and workarounds.
See also http://home.netscape.com/newsref/std/java_security.html for more information about the security features of Netscape Navigator.
Changed AppletViewer's HttpClient to use IP addresses instead of hostnames, in all cases. Previously, if an IP address could not be obtained (because DNS name resolution for computers beyond a firewall was not available to computers behind a firewall), then HttpClient used the URL of the applet when establishing network connection.
This change to HttpClient prevents a potential security attack in AppletViewer. The attack relies on a computer on the Internet having the exact same name as a computer behind your firewall. For example, an applet on the computer named "xyz.com" could potentially connect to a computer behind your firewall that is also named "xyz.com."
Implemented security check for applets in InetAddress.getLocalHost(). Applets were previously able to report the hostname and IP address of the client machine. This violates current firewall security procedures.
getLocalHost() is now treated as an attempt to connect to the local machine and accordingly it has a security check. If this succeeds, it works as before. If this fails, the method returns a host with name/address "localhost/127.0.0.1", a generic handle.
For this release we are providing a new interim version of the API documentation in HTML. This version has been revised and updated by the JavaSoft engineers and thus represents the most current documentation. We are planning eventually to provide this updated version in the javadoc format.
Windows 3.1 Users:For your convenience in evaluating the Java API, we have provided 8.3-length filenames in this new interim set of documentation (except for the package called sun.tools.debug). This means the files are fully functional in Windows 3.1.
Java Developers Kit