COMMAND

    java

SYSTEMS AFFECTED

    Systems using today's master browsers

PROBLEM

    Andre L. Dos Santos found following. 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 Andre and his  team
    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  this 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.   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.

SOLUTION

    Netscape  and  Microsoft  have  been  notifies  about this type of
    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.