From: lady0065@sable.ox.ac.uk (David Hopwood)
Newsgroups: comp.lang.java
Subject: Re: Java security bug (applets can load native methods)
Date: 5 Mar 1996 15:01:59 GMT
Organization: Oxford University, England
Message-ID: <4hhl17$bsm@news.ox.ac.uk>

In article <313B7C12.2338@taligent.com>,
Nick Lerissa  <nick_lerissa@taligent.com> wrote:
>David Hopwood wrote:
>> 
>> 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. [...]
>
>Yeah, of this is the case, however how exactly can the attacker arrange to
>get the files on the client machine in the first place.

There are several ways:

1) if the target and attacker are on the same (multi-user) machine, copy the
   files to /tmp, or reference them from the attacker's home directory.
2) if the target and attacker share a network drive or nfs partition, copy the
   files to that partition.
3) if the target machine runs an ftp filesystem, such as the Alex filesystem,
   the files can be put on any ftp server.
4) if the target user has read access to ~ftp/incoming (as root does, for
   example), upload the files there.
5) otherwise, pick any user on the system to be attacked, and convince him/
   her to download the files. This is much lower-risk than most social
   engineering attacks, because the target and the user being 'engineered'
   can be different people, and so no-one is likely to make any connection.
   Also the target can be root, say, while the person being engineered is
   Joe Clueless Newbie.

>It would seem to
>me that a user should not download an executable or dynamic library unless
>(s)he knows that the file is coming from a "save" place.

Even if they don't execute it or put it in an unsafe directory? Both files
can have (almost) any filename - they don't need to have the standard
extensions - so the user doesn't have to know that it is a dynamic library,
even if he/she knows that the files are there at all.

>By the way if you
>change Netscape so that the Java environment cannot execute code in dynamic
>libraries, you'd better also not allow Netscape plugins also.

There is no need to do that - just to enforce the documented restrictions
correctly (i.e. classes can only be loaded from the CLASSPATH).

David Hopwood
david.hopwood@lmh.ox.ac.uk