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