Skip navigation

MS Java VM Exposes Files

 
MS Java VM Exposes Files
Reported Feburary 2, 2000 by
Tada, Amemiya, Takagi,
Midorikawa, Tabata, and Yagi
VERSIONS AFFECTED
  • Internet Explorer 4.x and 5.x on Windows platforms, as well as any other application that uses Microsoft"s Java VM, including Outlook mail clients. 

DESCRIPTION

According to the report we found posted at this message board, Microsoft"s Java implementation has a security problem. The report states,

Translator"s note:

We announce another security hole of Microsoft Virtual Machine (Microsoft VM) for Java, including the latest version. This is the
translation version of the warning note (written in Japanese) by Dr.
Hiromitsu Takagi posted at the Java House Mailing List, a Japanese Java
user discussion site (http://java-house.etl.go.jp/ml/ . Japanese fonts
required to display).  The finding is summarized after numerical tests
and discussion among the members.  Mr. Kensuke Tada originated the
discussion.  The translation is made available by Dr. Tomohira Tabata
([email protected]) for his friends and others who may be benefit from
the information.   Please note that Dr. Tomohira Tabata has no
responsibility on mistranslation on this document.

The finding is:

This security vulnerability allows a Java applet to read out any files
on certain directories.  A simple code attacks the security hole.  Since
a beginning Java programmer can exercise one, all users should be
noted.  Its vulnerability is quite dangerous and immediate de-activation
of IE Java function provided by Microsoft is highly recommended;
possibly changing to Netscape Navigator, Communicator or Sun Java
Plug-in by the time Microsoft providing a "fix".

The body of the warning note by Dr. Hiromitsu Takagi:
--------------------------------------------------------------
Warning: Yet Another Security Hole of `Microsoft VM for Java"
--------------------------------------------------------------

This is a warning for all users of Microsoft Internet Explorer version 4
and 5 (IE4, IE5) for Microsoft Windows95/98/NT.

This security hole is closely related to the environment setting of
CLASSPATH for Java users and especially for the Java Developer; the note
is posted.

Vulnerability
-------------

This security vulnerability allows a Java applet to read any "known
files", which are common to most configuration.  A hosted web site is
able to retrieve file information through the applet code automatically
without being noticed when IE users access the site.  "Known files",
that is, files maintained by Windows system like the registry file,
specific files which popular applications hold, and files with common
names which users occasionally choose, such as memo.txt or password.txt,
on common folders at Desktop.  Any binary files could be read out as
well as text files.

This does not allow any change or deletion of local files. We still
believe this vulnerability is quite dangerous. For example, once files
like the registry file are revealed, it will give chances of further
attacks using the stolen information.


Detail description
------------------

The readable directories and their sub directories could be limited,
depending on PC"s system configuration, only for the "Current Working
Directory" when the VM is invoked. The "Current Working Directory"
varies by the version of IE or VM. The following is the tested result.

   C:\, with IE4, which means all files on default directory of C: drive
will be read,
   Except of Windows NT that is home directory of each user profile set.

   C:\Windows\desktop, with IE5 and 5.01, which means only files under
the desktop will be read.

We suspect this variation comes from the version of Microsoft VM for
Java, not the version of IE.

Unfortunately as a much serious case, if you set the environment
variable CLASSPATH at C:\AUTOEXEC.BAT, the files and directories under
the directories set in CLASSPATH are all readable.

Java programmers should be aware of the fact, who might set CLASSPATH
for their applications.


How to be attacked
------------------

You may get attacked indeed just accessing a web site if it contains a
Java applet with simple but malicious codes.

When accessing the web site, the applet is downloaded and invoked on
your computer, and then sends files on your computer to outside through
this security hole behind your back.

The magic code is:

  InputStream is = ClassLoader.getSystemResourceAsStream(filename);

This single line makes an applet read local files on IE users"
computers. The applet might send the files to any web server through
network connection or forward the files to anywhere by attaching them to
an email.

There would be already such an applet made by a malicious programmer,
and placed on a web page in secret.


Demonstration of attacking the security hole
--------------------------------------------

You can try a demonstration applet on the following URL, (don"t worry,
it just reads you back your e.g. autoexec.bat file under your command
and promise no file to be stolen from your system.  Even, it gives you
the sample code.)

http://java-house.etl.go.jp/~takagi/java/test/microsoft_insecurity/Test.html

Put a file you try to read onto Desktop for IE5 users or C:\ for IE4
users. Input a name of the file in text field at the top, and click the
right button. If you see the content displayed, you do confirm how your
computer is vulnerable. You may try files under sub directories. You
will see the content with specifying the file name with the directory
name.

When you receive the message "NullPointerException", the applet failed
to read or find the specified file.  However, this might means only that
the applet searched the different directories from you expected. You
need to try the applet again with putting the file on possible
directories, such as your home directory and so on, and you might find
the security hole when you see any successful read.


Work-around
-----------

Stop Microsoft"s Java function until a patch provided.

Instruction for IE4 users:

Follow "View" menu, "Internet Options...", "Security" tab, "Custom (for
expert users)", and "Setting..." button, and select "Disable Java" with
"Java permissions" at "Java" category.

Instruction for IE5 users:

Follow "Tools" menu, "Internet Options", "Security" tab, and "Custom
Level" button, and select "Disable Java" with "Java permissions" at
"Microsoft VM" category.

Alternative for utilizing Java:

- Use Netscape Navigator or Communicator instead of IE.
- Use Sun Java Plug-in for IE. See
http://java.sun.com/products/plugin/index.html


List of vulnerable applications with version numbers known and tested by
the members
------------------------------------------------------------------------------------

Microsoft (R) VM for Java, 5.0 Release 5.0.0.3234 (the latest version,
as of Jan 28, 2000) and earlier

Note that no similar vulnerabilities are currently reported with
Netscape Navigator, HotJava, or appletviewer with Sun JDK. Java VMs of
Sun and Netscape have protections to avoid these malicious accesses.


Is this mean, "Java is unsecured"?
-----------------------------------

No. This is a simple mis-implementation (a bug) of Microsoft Java VM. It
does NOT mean Java has a structural defect on vulnerability.
Prohibition of reading local files is fundamental function of Java,
which should be implemented with full of care. The VMs of Sun JDK or
Netscape is protected by SecurityManager to avoid such accesses.


Motivation of this note
-----------------------

We are aware that full disclosure of security holes informs destructive
people about methods for illegal activities as well as constructive
people informed. After fighting this dilemma, we believe the benefit of
users, such as awareness of existing danger and preventing possible
damages, is more important with this case, because

- Required technique to attack this security hole is so easy that any
Java programmers with fundamental knowledge on Java could implement
malicious applets. This is a totally different situation in the cases of
recent security holes of IE, found on August 1999 and on October 1999

- This issue is already known by thousands of members of our mailing
list. Even if we hid the code, anyone could suspect implementation of
attacking this hole.

- We already reported this issue to Microsoft Corp. in Japan, and asked
them to provide a patch immediately, and to announce it on media such as
newspaper so that all of Windows users could update their application.

The following is the Microsoft"s response;

-- Due to development issue, we can not guarantee to fix it as highest
priority.
-- Fixing may take time like a month or more.
-- We will warn users of this issue via our web site.


From this answer, we could not be convinced if users get secured soon.
In addition, they mentioned they could not prohibit us from announcing
this issue to Java communities. (Translator"s note: Dr. Takagi gave
Microsoft Corp. in Japan a call on Jan 28, 2000)

Acknowledgement
---------------

This security hole is happened to be found when we discussed programming
method to read files on Jar archives. As a start point, Mr. Tada
reported his applet read files on Desktop unexpectedly. Following the
report, Mr. Amemiya indicated it was a security hole. I, Dr. Takagi,
reported readable directories were not limited within Desktop at a
different circumstance. Mr. Midorikawa, Dr. Tabata, and Mr. Yagi
double-checked these issues, which reveals this vulnerability affects
most typical situation. Mr. Tada and I reported this issue to Microsoft
Corp. in Japan

VENDOR RESPONSE

See notes in red above.

CREDITS
Discovered by
Tada, Amemiya, Takagi, Midorikawa, Tabata, and Yagi
Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish