||Home : Advisories : Security Hole in ECL Feature of Java VM Embedded in Lotus Notes Client R5|
||Security Hole in ECL Feature of Java VM Embedded in Lotus Notes Client R5
||23rd November 2000
Security Hole in ECL Feature of Java VM Embedded in Lotus Notes Client R5
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
(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.)
Reaction of Lotus:
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.
Verification of Hole:
A demonstration applet has been created to verify the existence of
This demonstration decides whether or not the following files exist:
\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
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. (See Fig. 1.)
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. (See
Fig. 1 Warning dialog showing a local file is tried to be looked up
Fig. 2 List of files whose existence is detected by demonstration applet
Reasons for Defect:
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.
| If security considerations do not allow a resource to be visible
| in some security context, the getResource() method will fail
| (will return null) as if the resource was not present at all,
| this addresses existence attacks.
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 I 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.