sip@cs.princeton.edu

This page reports on security flaws in commercially available software. For more information about any of these items, contact Edward Felten.

October-November 2000:

We discovered how to defeat the four watermarking technologies put forth by the Secure Digital Music Initiative. Click here for more information.

October 1999:

Karsten Sohr at the University of Marburg has discovered another serious security flaw in Microsoft's Java Virtual Machine. A bug in Microsoft's bytecode verifier allows the construction of code sequences that illegally cast values of one Java type to values of another unrelated type, in violations of Java's typing rules, without detection by Microsoft's verifier. A malicious applet can exploit this flaw to breach the JVM's security, and can then proceed to do anything it wants to do on the victim's computer. For example, a malicious applet might exploit this flaw to read private data, modify or delete files, or eavesdrop on the user's activities.

Dirk Balfanz and Edward Felten of the Princeton Secure Internet Programming Lab have constructed a demonstration applet that exploits this flaw to delete a file.

As of October 11, 1999, all recent versions of Microsoft's JVM for Windows appear to be vulnerable, so users of recent versions of Internet Explorer are affected by this flaw. A malicious applet could also be embedded in an e-mail message read using Microsoft Outlook. (Eudora users are also affected, but only if they have changed Eudora's settings to turn on the "Allow executables in HTML content" feature.) Users of other JVMs, browsers, and e-mail readers are generally not affected. (Thanks to Reliable Software Technologies for their help in testing on various platforms.)

We have reported this flaw to Microsoft and they are working to address it.

August 1999:

We, in collaboration with Drew Dean at Xerox PARC and Dan Wallach at Rice University, have discovered a serious security flaw in the versions of Microsoft's Java Virtual Machine that are distributed with Internet Explorer 4 and Internet Explorer 5 for Microsoft Windows. The flaw allows the creation of a malicious applet that is attached to a HTML page, which could be delivered over the Web via Internet Explorer or by email via Outlook or other mail programs that use Microsoft's Java Virtual Machine. When the malicious applet is executed, it can read, modify, or destroy any data on the computer, insert a virus, insert software to spy on the user's future on-line activities, or take any other malicious action. The attack does not require the user to do anything beyond viewing the Web page or email message.

The flaw is a programming error (a race condition) in one of the security-critical parts of Microsoft's Java class libraries. A malicious applet can exploit this error to violate Java's security rules. The applet can then proceed to take control of the machine and perform any actions it likes. We have implemented and tested an applet that demonstrates this flaw by deleting a file on the victim's PC.

We are not releasing the demonstration applet or any further technical details about the flaw at this time.

After consultation with Princeton, Xerox PARC, and Rice, Microsoft has issued a security bulletin and a new version of their Virtual Machine that fixes this problem.

April 1999:

• Karsten Sohr at the University of Marburg in Germany has discovered a very serious security flaw in several current versions of the Java Virtual Machine, including Sun's JDK 1.1 and Java 2 (a.k.a. JDK 1.2), and Netscape's Navigator 4.x. (Microsoft's latest JVM is not vulnerable to this attack. We have not tested any other JVM implementations.) The flaw allows an attacker to create a booby-trapped Web page, so that when a victim views the page, the attacker seizes control of the victim's machine and can do whatever he wants, including reading and deleting files, and snooping on any data and activities on the victim's machine.

  The flaw is in an essential security component of the JVM. Under some circumstances the JVM fails to check all of the code that is loaded into the JVM. Exploiting the flaw allows the attacker to run code that breaks Java's type safety mechanisms. This code can set up a type confusion attack (see the book Securing Java by McGraw and Felten for details on type confusion attacks) which leads to a full-blown security breach.

  We have verified that the flaw exists and is serious. Attack code (in both applet and application form) has been developed in the lab to exploit the flaw. Sun and Netscape have been notified about the flaw and they are working on a fix.

July 1998:

• We found another Java security flaw that allows a malicious applet to disable all security controls in Netscape Navigator 4.0x. After disabling the security controls, the applet can do whatever it likes on the victim's machine, including arbitrarily reading, modifying, or deleting files. We have implemented a demonstration applet that deletes a file.

  This flaw, like several previous ones, is in the implementation of the "ClassLoader" mechanism that handles dynamic linking in Java. Despite changes in the ClassLoader implementation in JDK 1.1 and again in JDK 1.2 beta, ClassLoaders are still not safe; a malicious ClassLoader can still override the definition of built-in "system" types like java.lang.Class. Under some circumstances, this can lead to a subversion of Java's type system and thus a security breach.

  The flaw is not directly exploitable unless the attacker can use some other secondary flaw to gain a foothold. Netscape 4.0x has such a secondary flaw (a security manager bug found by Mark LaDue), so we were able to demonstrate how to subvert Netscape's security controls. We are not aware of any useable secondary flaws in Microsoft's and Sun's current Java implementations, so they appear not to be vulnerable to our attack at present.

  This flaw is fixed in Navigator 4.5. We have verified that our demonstration applet does not work on Navigator 4.5.

April 1997:

• We found a serious security flaw in version 1.1.1 of the Java Development Kit (JDK) and version 1.0 of the HotJava browser, both from Sun. These systems allow digitally signed applets. If an applet's signer is labelled as trusted by the local system, then the applet is not subject to the normal security restrictions. The flaw we found allows an applet to change the system's idea of who signed it. The applet can get a list of the all signers known to the local system, determine which if any of those signers is trusted, and then the applet can relabel itself so it appears to have been signed by a trusted signer. The result is that the applet can completely evade Java's security mechanisms.

  JavaSoft says that the flaw will be fixed in the next release (1.1.2) of the JDK. The Netscape and Microsoft browsers are not affected, since they do not currently support the JDK 1.1 code-signing API.

  More details are available.

December 1996:

• We announced the existence of the Web Spoofing attack, which allows an attacker to booby-trap a Web page so that after a victim visits the page, the attacker can observe and modify all further Web traffic between the victim and all Web servers on the net. For more details, see our technical report.

August 1996:

• We discovered a security flaw in Microsoft Internet Explorer 3.0. The flaw is serious, allowing an attacker to create a Web page that victimizes any Explorer user who visits the attacker's page. An attacker could exploit the flaw to execute any DOS command on the victim's machine; for example, the victim's files could be read, deleted, or modified, or a virus or backdoor entrance could be installed on the victim's machine. This flaw is fixed in Internet Explorer 3.01.

• We discovered two new security flaws, one affecting Netscape Navigator, and one affecting Microsoft Internet Explorer. Both bugs were serious, allowing a malicious applet to gain at least full read/write access to the victim's files. Browser versions affected are Netscape Navigator 3.0 beta 5 and earlier, and Microsoft Internet Explorer 3.0 beta 2 and earlier. These bugs were fixed in Navigator 3.0beta6 and Explorer 3.0.

June 1996:

• David Hopwood of Oxford University discovered a bug in Java security that affects Netscape Navigator 2.02 and Netscape Navigator 3.0beta4. In conjunction with some techniques from our March attack, Hopwood's attack can be used to execute arbitrary machine code. This problem was fixed in Navigator 3.0beta5 on all machines except PCs; the problem was fixed in Navigator 3.0beta6 on PCs.

May 1996:

• Because of a Java bug discovered by Tom Cargill, Netscape Navigator 2.02 and Microsoft Internet Explorer 3.0beta1 were vulnerable to a variant of our March 1996 attack, which is described below. This attack allowed an untrusted applet to execute arbitrary machine code. This bug was fixed in Navigator 3.0beta3 and Explorer 3.0beta2.

March 1996:

• We discovered a serious Java security flaw that allowed an untrusted applet to execute arbitrary machine code. We have a brief explanation for experts, and a slightly longer explanation for non-experts.
  Here is Sun's press release regarding this bug, as well as Netscape's press release.
  This problem affected Netscape Navigator 2.01 and was fixed in Navigator 2.02.

• Our paper analyzing the security of Java, Java Security: From HotJava to Netscape and Beyond, appeared in the 1996 IEEE Symposium on Security and Privacy.

February 1996:

• We discovered that Java trusted remote DNS servers, and so applets could make a network connection to machines other than that from which they were loaded.
  Here is Sun's response to our bug report, along with our reply. Netscape responded to our bug report by distributing a patch.
  This flaw affected Netscape Navigator 2.0 and was fixed in Navigator 2.01.

November 1995:

• We discovered many problems in Sun's HotJava Web browser, version 1.0alpha3. Our original paper (describing bugs in HotJava 1.0 alpha 3) is available as Princeton CS Tech Report 501-95 (Compressed Postscript, 65Kbytes).
  Here is Sun's response to our original paper.