Big Java security hole
Forwarded to me by a fellow webmaster; I don't know the original source. -Paul Date: Sun, 18 Feb 1996 23:57:02 -0500 From: Drew Dean <ddean@CS.Princeton.EDU> Subject: Java security problems 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. Note that we've only had success in exploiting the first flaw on an SGI. Windows 95 and DEC Alpha versions of Netscape have other bugs in their socket implementations that make it harder (although not necessarily impossible) to exploit the problem. This is the second time that unrelated implementation bugs have prevented us from demonstrating security problems in Java. http://www.cs.princeton.edu/~ddean/java will contain more information soon, including a revised version of our paper, to appear in the 1996 IEEE Symposium on Security and Privacy. Drew Dean <ddean@cs.princeton.edu> Ed Felten <felten@cs.princeton.edu> Dan Wallach <dwallach@cs.princeton.edu> Department of Computer Science, Princeton University For more information, please contact Ed Felten, 609-258-5906, FAX 609-258-1771. _______________________________________________________ Travis Weller WebMaster, Metrowerks, Inc. tcweller@metrowerks.com http://www.metrowerks.com/
Perry E. Metzger quotes:
A second, also serious, bug exists in javap, the bytecode disassembler.
I haven't figured out how this is anything more than a simple bug, unless one presumes you could concoct a trojan horse in the form of a "really cool applet that ya just gotta disassemble dudez". [Maybe that really is it.] ______c_____________________________________________________________________ Mike M Nally * Tiv^H^H^H IBM * Austin TX * I want more, I want more, m5@tivoli.com * m101@io.com * I want more, I want more ... <URL:http://www.io.com/~m101> *_______________________________
Well, folks, I told you so. Sorry to be nasty about it.
Date: Sun, 18 Feb 1996 23:57:02 -0500 From: Drew Dean <ddean@CS.Princeton.EDU> Subject: Java security problems
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. [...] 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. [...]
participants (3)
-
m5@dev.tivoli.com -
Perry E. Metzger -
Robichaux, Paul E