COMMAND
Lotus Notes
SYSTEMS AFFECTED
Lotus Notes Client R5
PROBLEM
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.