| |
| History |
|
| People |
|
| Partners |
|
| Research |
|
| Publications |
|
| FAQ |
|
| Links |
|
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
sendmail bug.
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 Netscape. 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 a Cypherpunks posting on 27 January 1996, independently postulated the DNS attack on Java. |
|
Department of Computer Science Contact: sip@cs.princeton.edu |