Another way to exploit local classes in Java
Andre L. Dos Santos (andre@CS.UCSB.EDU)
Wed, 08 Oct 1997 16:34:20 -0700
The attack described here is of interest because it uses the
CLASSPATH feature, which has been known to allow security breaches.
However, it uses it in a different way. The result is that the security
enhancements that have been introduced by Netscape to fix the previously
known vulnerability using this feature are ineffective in stopping this
attack.
The danger of setting the CLASSPATH environment variable to a path
where malicious classes are located is well known. Because of this
Netscape began restricting what a class loaded from the local disk can do
starting with Navigator 2.x. In Navigator 3.x Netscape took it one step
further with its setScopePermission model, and Communicator 4.x has signed
applets, where a capability based model is enforced. Microsoft has not
enhanced the model suggested by Javasoft.
The security model implemented by Netscape and Microsoft considers
any local class as a "system" class. Therefore, when a class is needed the
browser searches the local disk before requesting a class from the net.
Thus, if the user has classes in his/her local disk that have the same
name as classes that are used by a site, these classes will be used instead
of the ones from the network. Because of this it is possible to implement an
attack on a user interacting with a target site, where classes on the local
disk implement the functionality desired by the attacker. Our attack is able
to proceed because the classes that are used in our attack do not need to
request or require special privileges. The attack uses only the privileges
granted to classes loaded using the classloader.
In order to understand the risks of this flaw we have implemented a
demo of the attack on the Reliable Software Group site. This demo has as a
target the site of a bank that uses Java for login. The results of this
demo is that although the bank site uses SSL, a user is able to verify
that he/she is interacting with the desired site, when being attacked. So
there is no indication of an attack, and the user can verify the bank's
certificate. However, in the demo, instead of the browser sending the
login information to the bank server, it sends it to our server, in plain
text.
As is the case with most of the previously reported CLASSPATH attacks,
for our attack it is necessary for the user to load classes on the CLASSPATH.
One can not stress enough that there is a lot of trust involved with
downloading files onto your computer and pre-loading classes onto your
classpath. Therefore, if the user is following the procedure of installing
only files that he/she can be 100% sure will not do any harm, then this
CLASSPATH attack will not work. We believe, however, that it is likely that
one could trick a user into loading .zip files. One such file could have
the classes necessary for the attack in addition to a set of useful and
harmless classes.
We have notified Netscape and Microsoft about our attack.
Microsoft answered that this is the way that Java is supposed to work.
Netscape said that this problem can be partially solved using the function
matchPrincipal from their enhanced model. They also added that they are
working on improvements for this model and will consider a total solution
to the problem.
Andre Santos
Reliable Software Group
UCSB