From: jouko at solutions.fi (Jouko Pynnonen)
Subject: Technical information about unpatched MS Java vulnerabilities


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
  http://www.evilsite.com:80@....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
  jouko@...utions.fi

Powered by blists - more mailing lists