[prev in list] [next in list] [prev in thread] [next in thread] 

List:       best-of-security
Subject:    BoS: Java security bug (applets can load native methods)
From:       Julian Assange <proff () suburbia ! net>
Date:       1996-03-05 5:31:24
[Download RAW message or body]


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

[prev in list] [next in list] [prev in thread] [next in thread]