[ 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 in ECL Feature of Java VM Embedded in Lotus Notes Client R5

Title: Security Hole in ECL Feature of Java VM Embedded in Lotus Notes Client R5
Released by: Hiromitsu Takagi
Date: 23rd November 2000
Printable version: Click here
=========================================================================

Security Hole in ECL Feature of Java VM Embedded in Lotus Notes Client R5

http://java-house.etl.go.jp/ml/archive/j-h-b/038904.html

=========================================================================



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.





Problem:

--------



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





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 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.  (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. 2.)



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





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.

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



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





Acknowledgment:

---------------



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.



--

Hiromitsu Takagi

Electrotechnical Laboratory

http://www.etl.go.jp/~takagi/








(C) 1999-2000 All rights reserved.