Technical information about unpatched MS Java vulnerabilities

These are some technical details about the security vulnerabilities I've
found in Microsoft's Java implementatation. They were reported to the
vendor mostly during August 2002. Microsoft no longer responds to my
inqueries and doesn't seem to react about these severe vulnerabilities
which affect most Internet Explorer users. For this reason I've decided
to publish this information and hope it encourages the vendor to correct
the issues and release patches. This also allows other voluntary security
researchers to investigate the issues and possibly propose fixes or
workarounds.

My original report can be read here:

http://online.securityfocus.com/archive/1/290966

There were more than 10 vulnerabilities found in the Microsoft's Java
implementation. The vendor has published a bulletin and patch
addressing four of them (without mentioning the source of the information
though). The rest is listed here. Technical details of the four already
patched vulnerabilities were published in my previous message to Bugtraq.

This list contains a brief explanation and enough information for system
administrators, security professionals, and IE users to confirm the
existance of the flaws and determine if their software is vulnerable.
This requires some knowledge about Java; no exploit code is disclosed
here. The impact of some of these issues isn't known as they would
require more investigation and co-operation with the vendor. Regardless
of attempts, such co-operation with Microsoft hasn't been established
because they haven't replied my e-mails after we first warned the public
about the existance of the vulnerabilities in September. Before that,
they indicated that patches for many of these vulnerabilities were
being worked on, but it seems that releasing the patches was postponed or
cancelled for some reason.

These issues were also reported to Sun Microsystems; their Java
implementation appears to be unaffected.

1) URL parsing error
Impact: impersonating a web site, cookie theft

Java code parses URLs wrong if they contain a colon used to
indicate the port number. E.g. directing the user to the URL
http://www.evilsite.com:[email protected]/bankapplet.html causes
the browser to load the web page from www.bank.com, but due to
the error, the Java engine loads the applet code from a wrong
site, www.evilsite.com. This can be exploited at least to steal
cookies related to www.bank.com if the applet tag on www.bank.com
containts the MAYSCRIPT keyword (via netscape.javascript.*). The
attack requires that a Java applet exists on a web page on
www.bank.com.

2) Stack overflow in class loader
Impact: most likely only DoS

An overflow happens when a class with a long name is attempted to
load. This can happen with e.g. Class.forName() or
ClassLoader.loadClass(). This results in the browser crashing. It looks
unlikely that this could be exploited to run a shellcode.

3) File path discovery
Impact: finding out the current directory and username

Due to insufficient security checks any Java applet may find out
the current directory of the Internet Explorer process by doing
new File(".").getAbsolutePath(). This usually gives the desktop
path which includes the username on multi-user operating systems.
All local file access is supposed to be denied from untrusted
applets. The information retrieved in this way may be used in
conjunction with other vulnerabilities.

4) INativeServices memory access
Impact: reading memory space, may lead to delivery and execution of any code

Any applet may get an instance of com.ms.awt.peer.INativeServices
by calling SystemX.getNativeServices(). Its methods may be invoked
indirectly via the java.lang.reflect.* methods. The methods of
INativeServices take memory addresses etc. as parameters without
checking them. It's easy to crash the browser by passing bogus
parameters. It's also possible to read the process's memory
space via the method pGetFontEnumeratedFamily() and retrieve sensitive
information such as cookies and addresses of visited websites. In
particular, this can be used to find out the exact path to IE's cache
directories. This allows certain codebase related attacks, for instance
starting another applet having a file: codebase (see vuln. 6) which can
then browse the hard disks and shares and read any file. This could be
used for instance to read cookies, passwords, and other sensitive
information, or perhaps to launch other codebase attacks to run
arbitrary code.

5) INativeServices clipboard access
Impact: any applet can get or set the contents of clipboard

The methods ClipBoardGetText() and ClipBoardSetText() of the
class INativeServices can be used to access and modify clipboard
contents. The methods are accessible by any applet. The clipboard
may obviously contain very sensitive information. The methods have
to be called indirectly via the package java.lang.reflect.*.

6) file:// codebase when using shares
Impact: any applet may get global file read access

The codebase in the applet tag can be set to "file://%00" which
causes the applet to gain read access to all local files and
network shares. The applet may also list directory contents. This
requires that the applet is loaded from a publicly readable network
share. The consequences are the same as described for vulnerability 4).

7) StandardSecurityManager restriction bypassing
Impact: bypassing package access restrictions

The class com.ms.security.StandardSecurityManager can be extended by
any applet. The protected static fields containing package access
restrictions (deniedDefinitionPackages, deniedAccessPackages) can be
altered or emptied. Thus, any applet can bypass these restrictions. They
originate from the registry and aren't used by default, so this flaw doesn't
probably pose a big risk on default systems.

8) com.ms.vm.loader.CabCracker
Impact: An applet may load any local .cab archive

The method load() of the CabCracker class is used to load archives
from hard disk. The method does security checks and asks confirmation
from the user, and then calls load0() if the tests are successfully
passed. However the load0() method is declared public, so any applet
can call it directly and so skip the security checks. This would
require some more investigation (ie. what's possible with these cab
archives; Microsoft hasn't commented this in any way). In any case,
an untrusted applet isn't supposed to be able to access the local
filesystem in this way.

9) Problems with HTML object passed to Java applets via JavaScript
Impact: unknown

Javascript code can pass references of HTML objects to an applet. The applet
may invoke methods of some proprietary MS interfaces on them. Some of these
crash the browser due to illegal memory accesses. This may be a similar case
as INativeServices/JdbcOdbc.

10) HTML <applet> tag may be used to bypass Java class restrictions
Impact: unknown

An applet tag can be used to instantiate objects whose constructors are
private. Instantion of them shouldn't be possible. E.g.
<applet code=java.lang.Class> instantiates a Class object. Some of its
native methods crash the browser when called on this new instance, because
they presume the object can't be instantiated this way. As usual, IE
crashing means it might be possible to trick it into modifying memory in
arbitrary addresses and compromise the system.

The only known workaround for these issues is to disable Java support in
Internet Options -> Security -> Internet -> Custom level -> Microsoft VM /
Java permissions / Disable Java or use an alternative web browser and
mail client.

Jouko Pynn&#246;nen
[email protected]