Technical information about the vulnerabilities fixed by MS-02-52

These are some technical details about some of the Java vulnerabilities
we reported to Microsoft in August. These issues are corrected by the
patch MS-02-52 which Microsoft released September 18. The patch and
Microsoft's bulletin are available at

http://www.microsoft.com/technet/security/bulletin/MS02-052.asp

The patch doesn't fix all of the vulnerabilities we reported, so enabling
Java support in the Internet Zone even after applying the patch gives the
possibility for a malicious Java Applet to gain control over the system.

Our original report and information regarding the remaining Java
vulnerabilities can be read at

http://www.solutions.fi/index.cgi/?lang=eng

The vulnerabilities corrected by the patch are listed here, numbered from
1) to 4).

1) The constructor of class com.ms.jdbc.odbc.JdbcOdbc can be used to load
any DLL from the local filesystem. The constructor takes a String
parameter which is used to form a name of a JDBC-ODBC driver DLL to load.
The DLL name is formed by concatenating the string "MSJDBC10" to the
parameter. However, if the constructor's parameter string ends with a
null byte, the rest of the string is ignored, so the DLL name and path
can be freely chosen by a malicious applet. For instance to load the DLL
"C:\mydll.dll" the applet can do

new com.ms.jdbc.odbc.JdbcOdbc("C:\\mydll\000");

Loading an arbitrary DLL equals to running any code on the program,
because the initialization code of the DLL may contain any code; it could
read or write to files, download programs from internet and run them,
install a backdoor or a keyboard logger, etc.

In order to the attack to work, the attacker has to upload a malicious
DLL to the client's system and know it's exact location there. This can
be done by using some of the other, yet unpatched vulnerabilities in the
Microsoft's Java implementation.

MS02-52 corrected this flaw by hardcoding the DLL name "MSJDBC10" in the
Java code. The parameter given to the constructor is now ignored. This was
reported to Microsoft on 14 Aug 2002.

2) Methods of some classes of the pacakge com.ms.osp are accessible by any
Applet. Some of them may be used to compromise the client system.

MS02-52 corrected this flaw by restricting access to the package.
Invoking the methods now generates an IllegalAccessException. This flaw
was reported to Microsoft on 10 Aug 2002.

3) The class com.ms.jdbc.odbc.JdbcOdbc contains some methods which are
declared "protected native" and which take ODBC handles as parameter. Due
to the visibility declaration, any Applet may declare a new class which
is inherited from the JdbcOdbc class and gain access to these protected
native methods. It can then call the machine language code in these
methods and pass them carefully chosen parameters to cause the native
code to modify or read memory in arbitrary memory addresses. This may
allow the applet to be able to read the process's memory space in ways it
shouldn't be able to, or to direct the program execution to malicious
"shellcode". This hasn't been confirmed with an exploit yet, but similar,
yet unpatched vulnerabilities in some other Java classes allow execution
of arbitrary code. If the methods are invoked with random parameters,
Internet Explorer crashes when it tries to access or modify memory in
illegal addresses.

MS02-52 corrects this vulnerability by restricting the access to this
class for trusted Applets only. This was reported to Microsoft on 29 Aug
2002.

4) The class com.ms.jdbc.odbc.JdbcOdbcDriver has an error in a security
check, which allows any Applet to access ODBC data sources of the
client's system. The method connect() of the class is used to connect to
a data source. Before establishing the connection it performs a security
check to see if the caller is trusted. Only a trusted caller is supposed
to be able to connect to the local datasources, ie. databases, because
it's obviously a big problem if an applet originating from a random web
page may access the databases which are configured on your system.

The check is done in the method trusted() which is called from the method
acceptsURL() which is called from the connect() method. The trustedness
of the code is checked by checking if the caller has file write
permission. Untrusted applets don't have file permissions so if the
permission exists, then the caller is supposed to be trusted and
permitted to connect to ODBC data sources. When an ordinary untrusted
applet does the connect() call, the trusted() method check fails and it
prints a SecurityException on the Java console. If ODBC tracing is
enabled, it also logs that security check of JDBC-ODBC bridge failed. The
error happens after this: even after setting a boolean flag to false,
it's again set to value true in the end of the method trusted(). In other
words the method always returns true, and thinks every applet is trusted
at that point. Regardless of the error message, the applet can connect to
databases configured on the local system (Control Panel -> ODBC data
sources) and access the data in them. The attacker has to know the data
source name the applet connects to. The data sources may also require
additional authentication.

The flawed code also exists in Sun's code, but isn't exploitable because
Sun's Java Plug-in doesn't allow untrusted applets to access the class at
all. In order to access the JDBC-ODBC classes in the Sun's
implementation, the Applet needs additional privileges granted by the
user, in which case the error in the security check doesn't have any
impact.

Microsoft's security bulletin doesn't mention anything about this rather
serious vulnerability, but the patch corrects this by restricting the
access to the package com.ms.jdbc.odbc, ie. changing the restrictions to
what they are in Sun's implementation. This bug was reported to Microsoft
on 29 Aug 2002.

–
Jouko Pynnonen Online Solutions Ltd Secure your Linux -
[email protected] http://www.solutions.fi http://www.secmod.com