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@www.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@solutions.fi
