Vulnerability

    java (java implementation-related security hole)

Affected

    Netscape Navigator 4.x

Description

    Princeton's Safe Internet Programming Team recently announced  the
    discovery of a  serious Java security  hole that can  be leveraged
    into an  attack applet.   This Java  security flaw  that allows  a
    malicious  applet  to  disable  all  security controls in Netscape
    Navigator 4.0x.  After disabling the security controls, the applet
    can  do  whatever  it  likes  on  the  victim's machine, including
    arbitrarily reading, modifying, or deleting files.

    This flaw, like several previous ones, is in the implementation of
    the "ClassLoader" mechanism that handles dynamic linking in  Java.
    Despite changes in the  ClassLoader implementation in JDK  1.1 and
    again in JDK 1.2 beta, ClassLoaders are still not safe; a malicous
    ClassLoader can still override the definition of built-in "system"
    types like  java.lang.Class.   Under some  circumstances, this can
    lead to  a subversion  of Java's  type system  and thus a security
    breach.

    The  problem  with  ClassLoader  is  it  when  a  program  extends
    ClassLoader,  it  has  no  built  in  protection for the core Java
    classes.   The  Java  team  assumes  that  when  you make your own
    ClassLoader, you will add  checks to see if  a class is in  java.*
    and load the local copy using findSystemClass().  This also  means
    that you can replace the core Java classes by putting your own  in
    the  classpath  before  the  actual  ones,  so if your application
    allows you to specify the classpath, you can do whatever you want.
    Real problem  is somewhat  worse than  the above  description; you
    don't need any control over the CLASSPATH to implement the attack.
    There are  three bugs  in Netscape  4.0x: (1)  Applets can  create
    subclasses  of  netscape.applet.AppletClassLoader  --  Mark  LaDue
    posted this one back around April, but it didn't directly lead  to
    an attack.   (2) The  system classes  aren't looked  for  _first_;
    therefore,  they  can  be  replaced.   (3)  We  found a new bug in
    Sun-derived JVM's (including Netscape's) where replacing a  system
    class  leads  to  a  type  safety  failure.  Combining these three
    problems allows you to cast ints to Objects and vice versa.   This
    is sufficient to defeat all the security mechanisms in the JVM.

    The flaw is not directly  exploitable unless the attacker can  use
    some other secondary flaw to  gain a foothold.  Netscape  4.0x has
    such  a  secondary  flaw  (a  security  manager  bug found by Mark
    LaDue).   There were  no tests  due to  usable secondary  flaws in
    Microsoft's and Sun's current Java implementations, so they appear
    not to be vulnerable to this attack at present.

Solution

    It will be corrected.