Surprise: Microsoft's Java Implementation Is Full of Security Holes

Jouko Pynnönen of Online Solutions in Finland discovered a series of severe security vulnerabilities in Microsoft's Java implementation. Some of the vulnerabilities let attackers run arbitrary code through Microsoft Internet Explorer (IE) and Outlook Express. According to a message posted to the NTBugTraq mailing list on September 9, Pynnönen discovered and reported to Microsoft as many as 10 such vulnerabilities during July and August.

Pynnönen said, "Some of these [vulnerabilities] allow file access on  [users' systems], some allow access to other resources, and some allow delivery and execution of arbitrary program code on the victim system. These attacks can be carried out when a Web page or mail message containing a hostile [Java] applet is viewed with Internet Explorer or Outlook. In this case the applet [can] upload any program code and start it. The code can [perform] any operations the user can [perform, such as] read or modify files, install or remove programs, etc."

The vulnerabilities are, for the most part, related to code contained in native Java classes--called methods--but some of the vulnerabilities are related to logic errors. Typically, methods are marked as public, protected, or private. Some of the vulnerabilities stem from the security context of various methods, where various methods are improperly exposed.

Pynnönen also said, "An Applet can't contain native methods for [what should be] obvious reasons, but many of the core Java classes contain them. For instance, all file operations are eventually [performed] by native methods. They are used to [perform] operations that aren't possible or practical to do in pure Java.  They may [also] be used

for speed-critical parts of the code. Native methods aren't bound by the Java security policies and can access the processor, operating system, memory, and file system. Security-wise, native methods are a weak link. Unlike ordinary Java code, they can contain traditional programming flaws [such as] buffer overflows. If an untrusted Java applet can invoke a native method [that contains] a security flaw, it may be able to escape its [security] sandbox and compromise the system."

Pynnönen said that according to his research, most of the vulnerabilities aren't found in Sun Microsystems' Java code, but instead stem from modifications that Microsoft made to the code. He tested Sun's Java plug-in for the vulnerabilities and found that none of them exist in the plug-in.

To date, Microsoft hasn't issued a patch to correct the problems, but users can protect themselves against exploits by disabling Java within IE until a patch is available. Another alternative for users who still want to use the functionality Java affords is to download Sun's Java Virtual Machine (VM) and use it instead. The VM works with Windows XP, Windows 2000, Windows NT, and Windows 9x.

In June, Microsoft said that because of a legal settlement with Sun, after January 1, 2004, the company can no longer make modifications to Sun's Java code, including security fixes. Microsoft said that due to the settlement, the company would not include Java with Windows after that date.