[629] in linux-security and linux-alert archive
[linux-security] Java security bug (applets can load native methods) (fwd)
daemon@ATHENA.MIT.EDU (Jeff Uphoff)
Wed Mar 6 13:03:57 1996
Date: Wed, 6 Mar 1996 11:43:20 -0500
From: Jeff Uphoff <juphoff@tarsier.cv.nrao.edu>
To: linux-security@tarsier.cv.nrao.edu
This specifically mentions Java-based exploits that have been tested
successfully under Linux. Put a condom on your browsers there folks....
:)~
--Up: "Just say no" to Netscape 2.0 and Java, at least for now....
P.S. This one is kinda' nasty--apparently it can take advantage of
permissions settings/problems in your ~ftp/incoming area as an exploit
path.
[Again, forwarded to my by Ruth Milner at NRAO.]
------- start of forwarded message (RFC 934 encapsulation) -------
Date: Sat, 2 Mar 1996 23:51:49 +0000 (GMT)
From: David Hopwood <david.hopwood@lady-margaret-hall.oxford.ac.uk>
Subject: Java security bug (applets can load native methods)
There is a serious security bug in the class loading code for the Java
development kit and Netscape (all Java-enabled versions). If an attacker can
arrange for two files (a "Loader" class, and a dynamic library) to be
installed in any readable directory on the client machine, he/she can bypass
all of Java's security restrictions. For example, the applet can read,
write and execute files on the client, with the same permissions as the
user of the browser.
The only way to avoid this bug at the moment is to disable Java. In Netscape
this can be done by selecting 'Disable Java' in the 'Security preferences...'
section of the 'Options' menu.
This bug affects all Java implementations based on Sun's source code. It is
not related to JavaScript.
Further details will be posted when Sun and Netscape have released patches.
David Hopwood david.hopwood@lmh.ox.ac.uk
- ------------------
Date: Mon, 4 Mar 1996 18:08:58 +0000 (GMT)
From: David Hopwood <david.hopwood@lady-margaret-hall.oxford.ac.uk>
Subject: Java security bug (applets can load native methods)
Unfortunately my news server has been off-line for the past few days.
However, I'll try to address some of the questions that were raised on
strong-java@entmp.org and in private mail about the recently-discovered bug
in Java's class loading code. The same questions have probably been asked on
RISKS and/or comp.lang.java as well.
Apparently I wasn't clear enough in stating that this bug allows classfiles
to be loaded from _any_ directory on the client machine, not simply those on
the CLASSPATH or LD_LIBRARY_PATH. This includes, for example, /tmp,
~ftp/incoming, or an attacker's home directory if he/she has an account on
the same system.
The attack requires two support files on the client's system: a classfile
and a dynamic library. Both files must be readable by the browser, and the
dynamic library must be executable (this is always true for systems that
have no file permissions). The path to the classfile from the client's root
directory must be known by the attacker in advance.
Code demonstrating the bug has been written and tested on Linux and Digital
Unix (OSF/1). It should be portable to all POSIX systems, and with a little
work, to any system that supports Java. The demonstration is very easy to
extend - hiding it within any applet would require adding only two extra
lines of code. Changing the C code to execute any command would be a
single-line change. For that reason, the code will not be described in
detail or released publically until patches are available for both Netscape
2.0 and the Java Development Kit.
David Hopwood david.hopwood@lmh.ox.ac.uk
------- end -------
