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. http://www.hungry.com/~ben/msie_bug/
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. http://java-house.etl.go.jp/~takagi/java/test/urlconnection-http-redirect/Test.html
:
In addition to above, I accidentally found that URLConnection is still vulnerable without http-redirection technique. http://java-house.etl.go.jp/~takagi/java/test/urlconnection-direct/Test.html
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; http://www.zdnet.com/zdnn/stories/news/0,4586,2571633,00.html 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) Regards, -- Hiromitsu Takagi http://www.etl.go.jp/~takagi/ ----------------------------- Here is a excerpt from the note. http://java-house.etl.go.jp/ml/archive/j-h-b/033471.html ====================================================================== Warning: Security Holes Found in URLConnection of MRJ and IE of Mac OS ====================================================================== <snip> 1. Nature of Defect =================== <snip> 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: 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. 5. Method for Checking If Defect Really Exists ============================================== 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. 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 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. 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 implementation. 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. http://news.cnet.com/news/0-1003-200-321221.html http://news.cnet.com/news/0-1005-200-321259.html 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 versions. -- Hiromitsu Takagi Electrotechnical Laboratory http://www.etl.go.jp/~takagi/ (Translated from the original Japanese article [JavaHouse-Brewers:33152] http://java-house.etl.go.jp/ml/archive/j-h-b/033152.html) ========================================================================
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)