COMMAND

    IE

SYSTEMS AFFECTED

    Internet Explorer

PROBLEM

    Hiromitu Takagi found following.   To get ready for this  advisory
    refresh your memory with following:

        http://oliver.efri.hr/~crv/security/bugs/NT/ie10.html

    The point is that there are three separate bugs:

      1. The bug in Apple  MRJ 2.1/2.0 which allows direct  connection
         to any hosts. The http-redirection technique is not required.
         Apple Computer has not yet publicized this.
      2. The bug in Microsoft VM for Mac OS which allows access to any
         hosts  by   being  used   with  http-redirection   technique.
         Microsoft has not yet publicized this.
      3. The bug in IE 5  of Mac OS which allows direct  connection to
         any hosts  even if  the fixed  version of  MRJ (MRJ  2.2) was
         used.  This has been publicized in the ZDNet news on May 17.

    Takagi wrote a note which  describes what danger do this  security
    hole:

        http://java-house.etl.go.jp/ml/archive/j-h-b/033470.html (English)
        http://java-house.etl.go.jp/ml/archive/j-h-b/033024.html (Japanese)

    If a  document of  a vendor  notifying a  security hole  notifies:
    "malicious user would need to know the exact location and name  of
    the  file  that  he  wanted  to  read"  do  not  be  deceived  and
    underestimate the problem.

    The IE  of the  Mac OS  version requires  to use  Microsoft VM for
    Java, which is VM made by  Microsoft, or MRJ, which is VM  made by
    Apple, as Java VM.  In IE 3.0, however,  only Microsoft VM can  be
    used and  only MRJ  can be  used in  IE 5.0.  IE 4.0 and 4.5 allow
    selection of  either one  by "Preferences"  in the  menu.  The Web
    browser  iCab  made  in  Germany  uses  MRJ  as  Java VM.  The web
    browser HotJava 3.0 made by Java of Sun also uses MRJ as Java VM.

    The problem  found recently  is that  the foregoing  damage may be
    inflicted regardless of  which one is  used because the  Microsoft
    VM and MRJ both have separate security holes.  Let us assume  that
    these two  security holes  are (A)  and (B).   Results of  a study
    whether  or  not  combinations  of  individual VMs and web browser
    versions can be damaged by (A) and (B) are shown below:

                                                 (A)       (B)
    Mac OS + MRJ 2.2 + IE 5                      Unsafe    Unsafe
    Mac OS + MRJ 2.2 + IE 4.5                    Safe      Safe
    Mac OS + MRJ 2.2 + IE 4.01                   Safe      Safe
    Mac OS + MRJ 2.2 + iCab pre2.0               Safe      Safe
    Mac OS + MRJ 2.2 + Hotjava 3.0               Safe      Safe
    Mac OS + MRJ 2.2 + Apple Applet Runner       Safe      Safe
    Mac OS + MRJ 2.1.4 + IE 5                    Unsafe    Unsafe
    Mac OS + MRJ 2.1.4 + IE 4.5                  Unsafe    Unsafe
    Mac OS + MRJ 2.1.1 + IE 4.01                 Unsafe    Unsafe
    Mac OS + MRJ 2.1.4 + iCab pre2.0             Unsafe    Unsafe
    Mac OS + MRJ 2.1.4 + Hotjava 3.0             Safe      Safe
    Mac OS + MRJ 2.1.4 + Apple Applet Runner     Unsafe    Unsafe
    Mac OS + MRJ 2.1.1 + IE 5                    Unsafe    Unsafe
    Mac OS + MRJ 2.1.1 + IE 4.5                  Unsafe    Unsafe
    Mac OS + MRJ 2.1.1 + IE 4.01                 Unsafe    Unsafe
    Mac OS + MRJ 2.1.1 + iCab pre2.0             Unsafe    Unsafe
    Mac OS + MRJ 2.1.1 + Hotjava 3.0             Safe      Safe
    Mac OS + MRJ 2.1.1 + Apple Applet Runner     Unsafe    Unsafe
    Mac OS + MRJ 2.0 + IE 4.5                    Unsafe    Unsafe
    Mac OS + MRJ 2.0 + Apple Applet Runner       Unsafe    Unsafe
    Mac OS + Microsoft VM for Java + IE 4.5      Unsafe    Safe
    Mac OS + Microsoft VM for Java + IE 4.01     Unsafe    Safe

    If  MRJ  or  IE  is  not  upgraded after purchasing Macintosh, the
    versions  of  MRJ  and  IE  preinstalled  before shipment have the
    following  combinations  depending  on  the  Mac OS version.  Note
    that all the versions are unsafe except the latest Mac OS 9(b).

                                                 (A)       (B)
    Mac OS 8.0    IE 3.0    Microsoft VM         Unsafe    Safe
    Mac OS 8.1    IE 3.0    Microsoft VM         Unsafe    Safe
    Mac OS 8.5    IE 4.01   Microsoft VM         Unsafe    Safe
    Mac OS 8.6    IE 4.5    MRJ 2.1.1            Unsafe    Unsafe
    Mac OS 9(a)   IE 4.5    MRJ 2.1.4            Unsafe    Unsafe
    Mac OS 9(b)   IE 4.5    MRJ 2.2              Safe      Safe

    HotJava 3.0 uses MRJ, but seems to be using MRJ purely as  virtual
    machine.   Instead  of  using  an  MRJ  security  manager, it uses
    HotJava's  own,  thereby  escaping  from  impacts  of  the  recent
    problem.  iCab  seems to be  depending Java execution  entirely on
    MRJ and is similarly unsafe  as in Apple Applet Runner.  This does
    not mean that iCab  has a problem, but  rather the MRJ problem  is
    also affecting iCab.

    Test applets for two security holes, (A) and (B) mentioned  above,
    are available:

        (A) http://java-house.etl.go.jp/~takagi/java/test/urlconnection-http-redirect/Test.html
        (B) http://java-house.etl.go.jp/~takagi/java/test/urlconnection-direct/Test.html

    Input the  URL of  the web  page desired  to read  in the top text
    field and press the right button.   A security hole exists if  the
    content of the desired page  is displayed in the bottom  text area
    (If an HTML page, the HTML source will be displayed).

    For example, specify a page which is supposed accessible only from
    the  inside.   A  malicious  applet  would  transfer the read data
    somewhere.   Rest assured  that this  test applet  only reads  and
    displays  data  in  the  text  area.   It  does  not transfer data
    anywhere.   If the  browser and  VM are  secure, a  one-line error
    message such as

        com.apple.mrj.JManager.JMAppletSecurityExc: security.Couldn't connect to 207.46.130.14 with origin from java-house.etl.go.jp

    or

        Security Exception: socket.connect: java-house.etl.go.jp->207.46.130.45

    will be displayed.

    Unlike security holes of JavaScript found in the past, stolen data
    is not confined to text files  or HTML files.  Data of  any format
    is also stolen.  Users will not notice even though applets,  which
    appear  to  be  performing  useful  functions,  are simultaneously
    executing malicious  processing in  the background.   Most of  the
    users do not know even if they are inflicted with damage.

    The security hole  (A) is already  found in the  past, such as  in
    Windows-version IE (already fixed in the Windows version).   There
    may  be  quite  a  few  applets  which  abuse it.  For the reasons
    outlined above, the seriousness of the recent problem seems to  be
    relatively large.

    This is merely a programming error (bug) which was made when Apple
    and  Microsoft  implemented  Java  VM  or  browser.   It  does not
    represent design weakness of Java.   Disabling access to any  host
    is a basic function  of Java and this  is the part which  requires
    most  careful  implementation.   Java  does  not  have  structural
    weakness that tends to  make implementation of it  erroneous. Both
    of the two security holes are quite sloppy.

    In the present case, Security Hole (A) has already been  uncovered
    and is known in the public  domain and there is no reason  to hide
    it at this  moment.  Security  Hole (B) is  a very straightforward
    hole that problems occur just by using normal API as it is and  it
    could not be hidden.

SOLUTION

    (a) Stop Java function
    ======================
    For IE:

        Select "Preferences" in the "Edit" menu, select "Java" in "Web
        Browser" and check off the check box "Enable Java".

    For iCab:

        Select   "Preferences"    in   the    "Edit"   menu,    select
        "Settings/Security"  in  "Java"  and  check  off the check box
        "Execute Java applets".

    (b) Use a safe browser
    ======================
        Netscape and HotJava seem to be safe against this problem.

    (c) Use a safe version
    ======================
    Microsoft has terminated development  and support of Microsoft  VM
    for Mac OS. Do not use it.  Therefore,

        - Do not use IE 3.0.
        - When using IE 4.0/4.5, use MRJ.
          Select "Preferences"  in the  "Edit" menu,  select "Java" in
          "Web Browser" and  select "Apple MRJ"  in the popup  menu of
          Java VM.

    MRJ 2.0 and 2.1 are wholly unsafe.  Install MRJ 2.2.  MRJ 2.2 can
    be obtained from the following page:

        http://www.apple.com/java/

    However, even MRJ  2.2 is unsafe  if it is  combined with IE  5.0.
    Use IE 4.5  or iCab.   Do not use  IE 5.0.   It has been  reported
    that MRJ  2.2 has  been safe  when combined  with IE  4.5 or iCab.
    The reason why MRJ 2.2 presents problems when it is combined  with
    IE 5.0 is not known.