From: jouko at solutions.fi (Jouko Pynnonen)
Subject: 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 -
jouko@...utions.fi      http://www.solutions.fi    http://www.secmod.com

Powered by blists - more mailing lists