Visit our newest sister site!
Hundreds of free aircraft flight manuals
Civilian • Historical • Military • Declassified • FREE!


TUCoPS :: IBM(multi) :: notes15.htm

Lotus Notes - attackers can discover existence of certain filenames



Vulnerability

    Lotus Notes

Affected

    Lotus Notes Client R5

Description

    Hiromitsu Takagi found following.   The security hole that  allows
    a file existence attack found with Java VM embedded in Lotus Notes
    Client R5, which was reported in [j-h-b:32085] at the end of March
    2000 is  summarized below,  including how  the vendor  is reacting
    to it.

    The Lotus Notes Client  R5 can use its  own Web browser to  access
    WWW.  The browser embeds Java VM unique to it and this VM is  used
    in the Java applet display.  Java VM embeds a feature called  "ECL
    (Execution Control List),"  which is unique  to Lotus.   Through a
    hole of this ECL feature, a  problem exists in that a third  party
    can detect whether  or not a  file of a  specified pathname exists
    in the local file system.

    If this is abused, for example, the following private  information
    is known to third parties:

        - Whether or  not a specified  site is visited.   This can  be
          discriminated  by  whether  or  not  a  cookie  of this site
          exists.  (In case Internet Explorer is also used)
        - Whether  or  not  a  specified  Web page is registered  with
          "Favorites."  (This  can  be  discriminated  by  finding out
          whether or not a short-cut file with the title of this  page
          as its file name exists in the \WINDOWS\Favorites\  folder.)
          (In case Internet Explorer is also used)
        - Whether  or not  a specified  file has  been used  recently.
          (This can be discriminated by  finding out whether or not  a
          short-cut file with the same name as its file name exists in
          the \WINDOWS\Recent\ folder.)
        - Whether or not a specified application is installed.   (This
          can be discriminated by finding out files which always exist
          when such applications are installed.)

    A demonstration applet has been created to verify the existence of
    this hole:

        http://java-house.etl.go.jp/~takagi/java/security/lotus-notes-existence-attack/Test.html

    This  demonstration  decides  whether  or  not the following files
    exist:

        \AUTOEXEC.BAT
        \Program Files\Internet Explorer\IEXPLORE.EXE
        \Program Files\Microsoft Office\Office\WINWORD.EXE
        \Program Files\Microsoft Office\Office\POWERPNT.EXE
        \Program Files\Adobe\Photoshop 5.5\Photoshp.exe
        \Program Files\Netscape\Communicator\Program\netscape.exe
       ...\Cookies\administrator@playboy.txt
       ...\Cookies\administrator@playboy[1].txt
       ...\Cookies\administrator@playboy[2].txt
       ...\Cookies\anyuser@playboy.txt
       ...\Cookies\anyuser@playboy[1].txt
       ...\Cookies\anyuser@playboy[2].txt

    Pressing the Search button, inspection starts with the file  names
    provided and a warning  dialog "Execution Security Alert"  appears
    in case a file to be inspected exists in the local disk.  Pressing
    "Abort" or "Execute  Once" button will  let the Java  program know
    the existence of  this file and  the file name  is displayed in  a
    "List of files confirmed to be existing" in a text area under.

    Fig. 1 Warning dialog showing a  local file is tried to be  looked
    up:

        http://java-house.etl.go.jp/~takagi/java/security/lotus-notes-existence-attack/fig-1-en.gif

    Fig. 2 List of files whose existence is detected by  demonstration
    applet

        http://java-house.etl.go.jp/~takagi/java/security/lotus-notes-existence-attack/fig-2.gif

    The  standard  Java  security  model  up  to JDK 1.1 prohibits all
    accesses to  local files  and has  lacked a  flexibility.  The ECL
    feature of Lotus  provides a flexibility  to meet this  situation.
    This feature expands Java's security model and does not  prohibits
    all.  It  allows the user  to select execution  or cancellation by
    popping up a dialog to confirm execution when hazardous  operation
    is about to be executed.

    When     the     getSystemResource(String)     method     of   the
    java.lang.ClassLoader  class  is  called,  a  dialog to confirm it
    appears  only  when  a  file  of  the  pathname  specified by this
    argument exists.

    The getSystemResoruce method returns "null" regardless of  whether
    "Abort" or "Execute" is selected and execution is continued as  if
    nothing has happened.  However, the time required to execute  this
    method is clearly longer than that when a dialog is not popped up.
    This  is  because  more  than  several  hundred  milliseconds  are
    required for  a man  to finish  pressing a  button.  Therefore, by
    examining the  time difference  before executing  this method  and
    after executing it, showing of this dialog can be detected.  As  a
    result, a malicious applet program can know that a file exists.

    Sun's manual  for JDK  clearly describes  that such  circumstances
    must not be caused by behaviors of getSystemResource:

        http://java.sun.com/products/jdk/1.2/docs/guide/resources/resources.html

    The ECL feature  of Lotus Notes  lacked this consideration,  which
    led this hole to be created.

    First, Mr. Yasuyuki Endo reported that a dubious behavior with the
    getSystemResource method existed in Java VM of Lotus Notes Client.
    Since then,  Mr. Endo  and Mr.  Takagi discussed  and examined the
    delay  time  of  method  execution.   The  result  was that in all
    instances decisions whether  or not a  file existed could  be made
    by examining  the delay  time of  method execution.   Mr.  Hiroshi
    Hisamatsu  and  Mr.  Ryuichiro  Isobe  extended his cooperation in
    confirming this phenomenon in an English version of Notes Client.

Solution

    On May  3 2000,  Mr. Yasuyuki  Endo submitted  the first report to
    Lotus Japan [j-h-b:33007].   Lotus replied to  Mr. Endo "You  must
    report  via  its  support  service  after  concluding  a   support
    agreement  by  paying  a  fee."   Subsequently,  on May 24, Takagi
    contacted Lotus Japan again by phone.  On May 26, Takagi  conveyed
    the fact to  a Lotus Japan  engineer by phone.   On May 30,  Lotus
    Japan  replied  in  a  letter  to  the  effect  that  "Lotus Japan
    acknowledges this  phenomenon and  is studying  the phenomenon and
    is investigating it" [j-h-b:33526]. Since then, no reply had  been
    received.  On June 16, Takagi inquired again "What has  happened?"
    Lotus  Japan's  answer  was  "We are investigating" [j-h-b:34085].
    On August 1 and 20 and October 26, similar inquiries were sent  by
    Takagi to  Lotus Japan.   On each  occasion, Lotus  Japan  replied
    "The matter is investigated by Lotus Headquarters in the U.  S."

    More  than  half  year  has  passed  after the first report and no
    improvement in the situation has  been made.  It has  been decided
    to publicize this fact.


TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2014 AOH