We have discovered a serious security problem with Netscape
Navigator's 2.0 Java implementation. (The problem is also present in
the 1.0 release of the Java Development Kit from Sun.) An applet is
normally allowed to connect only to the host from which it was loaded.
However, this restriction is not properly enforced. A malicious
applet can open a connection to an arbitrary host on the Internet. At
this point, bugs in any TCP/IP-based network service can be exploited.
We have implemented (as a proof of concept) an exploitation of an old
If the user viewing the applet is behind a firewall, this attack can
be used against any other machine behind the same firewall. The
firewall will fail to defend against attacks on internal networks,
because the attack originates behind the firewall.
The immediate fix for this problem is to disable Java from Netscape's
"Security Preferences" dialog. An HTTP proxy server could also
disable Java applets by refusing to fetch Java ".class" files. We've
sent a more detailed description of this bug to CERT, Sun, and
A second, also serious, bug exists in javap, the bytecode
disassembler. An overly long method name can overflow a stack
allocated buffer, potentially causing arbitrary native code to be
executed. The problem is an unchecked sprintf() call, just like the
syslog(3) problem last year. Many such bugs were in the alpha 3
release's runtime, but were carefully fixed in the beta release. The
disassembler bug apparently slipped through. This attack only works
on users who disassemble applets. The fix is to not run javap until
Sun releases a patch.
A more detailed DNS attack
scenario is available.
Steve Gibbons, in
posting on 27 January 1996,
independently postulated the DNS attack on Java.