[linux-security] Java security bug (applets can load native methods) (fwd)
It turns out that Java is even less secure than I had feared.
Unsuspecting users can breach their firewalls. So I thought I'd take
this opportunity to magnify my warning of a week ago: Don't use
Netscape/Java without setting up a separate unpriveledged account AND
Don't use Netscape/Java within a firewall environment.
Note: I'm NOT a security expert. I just see the inherent risks of
running code on MY system without MY permission :)
This just came through on the Linux-security list:
'Jeff Uphoff wrote:'
>From owner-linux-security@tarsier.cv.nrao.edu Wed Mar 6 12:49:24 1996
>Date: Wed, 6 Mar 1996 11:43:20 -0500
>Message-Id: <199603061643.LAA28104@tarsier.cv.nrao.edu>
>From: Jeff Uphoff <juphoff@tarsier.cv.nrao.edu>
>To: linux-security@tarsier.cv.nrao.edu
>Subject: [linux-security] Java security bug (applets can load native methods) (fwd)
>X-Palindrome: Anne, I vote more cars race Rome to Vienna.
>X-Mailer: VM 5.95 (beta); GNU Emacs 19.29.1
>X-Attribution: Up
>Sender: owner-linux-security@tarsier.cv.nrao.edu
>Precedence: list
>
>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 -------
--
Christopher J. Fearnley | UNIX SIG Leader at PACS
cjf@netaxs.com | (Philadelphia Area Computer Society)
http://www.netaxs.com/~cjf | Design Science Revolutionary
ftp://ftp.netaxs.com/people/cjf | Explorer in Universe
"Dare to be Naive" -- Bucky Fuller | Linux Advocate
Reply to: