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 - joukoat_private http://www.solutions.fi http://www.secmod.com _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
This archive was generated by hypermail 2b30 : Mon Sep 23 2002 - 05:06:14 PDT