Vulnerability
IE
Affected
Internet Explorer
Description
Hiromitu Takagi found following. To get ready for this advisory
refresh your memory with following:
ie10.htm
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.
TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2024 AOH
