OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
From: Jouko Pynnonen (jouko_at_solutions.fi)
Date: Mon Sep 23 2002 - 06:39:22 CDT

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    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 -
    joukosolutions.fi      http://www.solutions.fi    http://www.secmod.com