COMMAND

    JDK 1.1.1 & HotJava 1.0

SYSTEMS AFFECTED

    Systems running JDK 1.1.1 & HotJava 1.0

PROBLEM

    This info is based on announce at:

        http://www.cs.princeton.edu/sip/News.html

    It was found a serious security flaw in version 1.1.1 of the  Java
    Development  Kit  (JDK)  and  version  1.0 of the HotJava browser,
    both from Sun.  These systems allow digitally signed applets.   If
    an applet's  signer is  labelled as  trusted by  the local system,
    then  the   applet  is   not  subject   to  the   normal  security
    restrictions.   The  flaw  found  allows  an  applet to change the
    system's idea of who signed it.  The applet can get a list of  the
    all signers known to the  local system, determine which if  any of
    those signers is trusted, and  then the applet can relabel  itself
    so it appears to have been signed by a trusted signer.  The result
    is  that  the   applet  can  completely   evade  Java's   security
    mechanisms.

    The attack works in two stages. First, the attack applet  acquires
    the ability to change the system's idea of who signed it. Then  it
    gets a list of all signers  known to the local system, and  "tries
    on" the these  identities one by  one until it  finds one that  is
    trusted.   Having done  this, the  applet is  free of any security
    restrictions.

    How the  attacker changes  its identity?   The attacker  calls the
    getSigners() method of the java.lang.Class class. This returns  an
    array of  signers who  have signed  the class.  The JDK 1.1.1 code
    mistakenly returns a  reference to its  own internal array.  Since
    Java arrays can  be modified, the  attack applet can  then replace
    any element  of the  array, thereby  changing Java's  idea of  who
    signed it.

    How the attacker finds a  trusted identity to assume?   The method
    getSystemScope() of the class java.security.IdentityScope  returns
    an IdentityScope object (call  it s). Calling s.identities()  gets
    an enumeration of all identities known to the local system.

    The attack applet can try each of these identities one at a  time.
    After changing to  a new identity,  the applet tries  a privileged
    operation,  i.e.  writing  a  file.  If  this  causes  a  security
    exception,  the  current  identity  is  not trusted, so the applet
    goes on to the next identity. If the operation succeeds, then  the
    applet knows it has acquired trusted status, and it is free to  do
    whatever it wants.

    Credit for this goes to Princeton University.

SOLUTION

    JavaSoft says  that the  flaw will  be fixed  in the  next release
    (1.1.2) of the JDK.   The Netscape and Microsoft browsers  are not
    affected,  since  they  do  not  currently  support  the  JDK  1.1
    code-signing API.