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: Fri Nov 08 2002 - 07:00:01 CST

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

    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
      www.bank.com/bankapplet.html">http://www.evilsite.com:80www.bank.com/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önen
      joukosolutions.fi