Home page logo

bugtraq logo Bugtraq mailing list archives

Security Holes Found in URLConnection of MRJ and IE of Mac OS (was Re: Reappearance of an old IE security bug)
From: takagi () ETL GO JP (TAKAGI, Hiromitsu)
Date: Sat, 10 Jun 2000 07:09:21 +0900

On Sat, 13 May 2000 08:38:06 +0900
"TAKAGI, Hiromitsu" <takagi () ETL GO JP> wrote:
On Sun, 16 Apr 2000 17:09:04 -0600
Ben Mesander <bam () DIMENSIONAL COM> wrote:
I have found a way to have a Java applet open a connection to an arbitrary
host and violate the Java security model in Internet Explorer 5. This is a
bug I first discovered in 1997, and Microsoft fixed it then. It seems to
have reappeared in the latest IE 5.

You mentioned that it is a getImage bug. But I suspected that it might
be a java.net.URLConnection bug because getImage seems to be implemented
with URLConnection. I confirmed this with the following applet.
In addition to above, I accidentally found that URLConnection is still
vulnerable without http-redirection technique.

I wrote a detailed description of the vulnerabilities.
http://java-house.etl.go.jp/ml/archive/j-h-b/033471.html (English)
http://java-house.etl.go.jp/ml/archive/j-h-b/033152.html (Japanese)

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;

In the ZDNet news story:
 | Kwong said a malicious Web developer would need to know details of
 | the exact path within the intranet from that specific user's
 | computer. Users behind a firewall or on a network that employs
 | intelligent authentication are safe from the glitch, he said.

This is NOT true!

It is true that a page cannot be accessed unless URL of an
intraserver is known. However, it is also true that URLs of
intraservers can be easily known to malicious web site operators.
I 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)


Hiromitsu Takagi

Here is a excerpt from the note.

Warning: Security Holes Found in URLConnection of MRJ and IE of Mac OS


1. Nature of Defect


2. Possible Damage

Contents of web pages that cannot be accessed from the outside are
leaked to the outside. For more details, read [JavaHouse-Brewers:33470]
(http://java-house.etl.go.jp/ml/archive/j-h-b/033470.html), which
describes what danger do security holes that can be access any host as
in the recent case have.

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. This reason can be
found in [JavaHouse-Brewers:33470].

3. Software Containing Problem and Software Version

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.

4. Workaround

(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:

   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.

5. Method for Checking If Defect Really Exists

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


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 with origin from 
  Security Exception: socket.connect: java-house.etl.go.jp->
will be displayed.

6. Problem Seriousness

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

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.

7. Does this problem show intrinsic weakness of Java?

No. 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

Java does not have structural weakness that tends to make implementation
of it erroneous. Both of the two security holes are quite sloppy.

The Security Hole (A) with Microsoft VM is caused because a recheck of
the accessing party was neglected when the server to be connected
requested reconnection to other site by the HTTP-redirect function in
URLConnection. This problem was found once in August 1997.

Windows IE 4.0 fixed this problem. The Mac OS version of Microsoft VM
had been left as it was and this was careless.

The security hole (B) in MRJ is more careless. Connection with any host
can be established by merely using URLConnection by the ordinary method
without using the HTTP-redirection technique. (For this reason, the
result is that it is entirely unsafe in (A) also if it is unsafe in (B).)

In MRJ 2.0/2.1.x, this phenomenon is not a delicate one that manifests
depending on the combination with the browser. It manifests even in the
Apple Applet Runner. It is very surprising that Apple has shipped
software without verifying such fundamental parts.

8. On Disclosure of This Document

I reported the problem of Security Hole (A) to the security contact
window at Microsoft in the United States and requested them to notify
the danger to the users by a bulletin. Microsoft acknowledged that the
problem existed, but said that Microsoft would not notify the problem in
its Microsoft Security Bulletin. The reason for this was that "We no
longer support Microsoft VM; instead, we have collaborated with Apple on
their Java runtime and recommend that customers use it instead of
Microsoft VM".

Microsoft said that this would be explained in the Knowledge Base page.
Those who do not know the existence of this security hole are the ones
who really need to have the information. Who would notice an addition to
the Knowledge Base page??

It appears that Microsoft has no interest in actively letting its users
know about the danger. I have, therefore, decided to notify our readers
through this document.

I tried to report Security Hole (B) to Apple Computer in the United
States. I failed to locate a contact window dedicated to security
matters and sent a question "With whom I should inquire?" A mechanical
response came back, "You need to be a member of Apple Developer
Connection to report a bug." I then reported to Apple Computer in Japan
and received the following reply:

| This problem has already been confirmed and we are rushing adjustment
| about our countermeasure. We recognize the comment made by Mr. Takagi
| as useful information. The problem has occurred with specified
| versions of some of the browsers. We are coordinating the matter with
| the application vendor and are studying to deal with the problem in
| subsequent versions.
| We are in close contact with the application vendor regarding the
| security problem of MRJ 2.2 + IE 5.0 and are working to solve the
| problem.

It appears that Apple Computer in Japan is recognizing the matter to be
a matter merely related to MRJ 2.2 + IE 5.0. I pointed out that this was
not a problem confined to specified versions, by showing the results of
the study mentioned above. The person who dealt with me only repeated
the same answer, probably because he was not technically knowledgeable,
was not interested in hearing seriously my explanation, or was not
willing to take responsibility for past versions which were shipped.

As the situation stands, it is totally impossible to expect that a
precise explanation will be given to the users. Under the circumstance,
I have decided to inform you about this problem.

The next subject is pros and cons in disclosing details of these
security holes.  Generally speaking, disclosing details of security
holes may provide malicious persons a means for illegal actions and that
details must not be disclosed.  This is one opinion.

However, 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.

9. Brief History and Acknowledgment

I read a report in BugTraq of April 15 by Mr. Ben Mesander in which he
pointed out, "An old security hole discovered in 1997 is found with Mac
OS IE 5 again."
http://www.securityfocus.com/templates/archive.pike?list=1&date=2000-04-15&msg=l03130301b51ff7d482a8 () [10 0 0 3]

The members on the Java House mailing list were contacted to make an
inquiry whether or not this was true. The research showed that the same
problem would generate not only with IE 5.0, but also with IE 4.5 and IE
4.0 if Microsoft VM was selected.

I assumed that this problem was caused by a URLConnection bug, rather
than by a getImage but, and verified it by creating a test applet. It
was found that the problem would be generated no matter which browser
was combined if MRJ 2.1.x was used, and that it was an MRJ bug.

Furthermore, I accidentally found that the MRJ problem would occur even
if the http-redirection technique was not used. I found out that the
this phenomenon was caused by a bug which was different from the bug
pointed out by Mr. Ben Mesander. I reported the whole developments in
BugTraq of May 13.
391C95DE2DA.5E3BTAKAGI () java-house etl go 
jp">http://www.securityfocus.com/templates/archive.pike?list=1&date=2000-05-8&msg=391C95DE2DA.5E3BTAKAGI () java-house 
etl go jp</A>

Finally, I thank Nogami-san, Orihara-san and Nishikubo-san for their
cooperation in verifying whether or not problems occurred in the various

Hiromitsu Takagi
Electrotechnical Laboratory

(Translated from the original Japanese article [JavaHouse-Brewers:33152]

  By Date           By Thread  

Current thread:
  • Security Holes Found in URLConnection of MRJ and IE of Mac OS (was Re: Reappearance of an old IE security bug) TAKAGI, Hiromitsu (Jun 09)
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]