[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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 <[email protected]>
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 <[email protected]>
Ed Felten <[email protected]>
Dan Wallach <[email protected]>
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.
[email protected] http://www.metrowerks.com/