Chronology of security-related bugs and issues

Print-friendly Version

Chronology of security-related bugs and issues, 11/19/02
For issues after 11/19/02, please see Sun Alert Notifications

See Also: Security and the Java Platform

November 19, 2002 - CERT has reported a bug in the zlib compression library (see www.cert.org/advisories/CA-2002-07.html). Sun's implementations of the Java Runtime Environment include zlib and are affected. This bug may allow malicious code to corrupt memory and possibly crash the Java Runtime Environment.

See Sun Security Bulletin #00220

March 19, 2002 - A vulnerability in the Java Runtime Environment Bytecode Verifier may be exploited by an untrusted applet to escalate privileges.

See Sun Security Bulletin #00218

March 19, 2002 - A Java Web Start application may gain access to restricted resources.

See Sun Security Bulletin #00217

March 6, 2002 - A vulnerability in the Java Runtime Environment may allow an untrusted applet to monitor requests to and responses from an HTTP proxy server when a persistent connection is used between a client and an HTTP proxy server.

See Sun Security Bulletin #00216

January 25, 2002 - The Java Runtime Environment may be vulnerable to a denial-of-service attack where a remote client may cause a Java server process to exit.

The following releases for the Linux platform are affected:

• SDK and JRE 1.3.1_002 or earlier running the Classic VM


• SDK and JRE 1.3.0_005 or earlier running the Classic VM


• SDK and JRE 1.2.2_010 or earlier running the Classic VM

All other SDK, JDK, and JRE releases are not affected.

Sun has a remedy for the vulnerability and it will be included with the following Update releases for Linux:

SDK and JRE 1.3.1_03 (estimated to be available end of March 2002)

SDK and JRE 1.2.2_012 (estimated to be available end of April 2002)

The above releases will be available at:

• http://java.sun.com/j2se/1.3
• http://java.sun.com/j2se/1.2

Sun recommends that sites using the 1.3 release with the Classic VM switch to the HotSpot Server VM or upgrade to the latest 1.3.1 Update release or the upcoming 1.4 release when they are available.

Sun also recommends that sites using the 1.2 release with the Classic VM upgrade to the 1.3.1 release and use the HotSpot Server VM or upgrade to the latest Update release or the upcoming 1.4 release when they are available.

Sun acknowledges, with thanks, Volano LLC for bringing this issue to our attention.

October 25, 2001 - A vulnerability in the Java Runtime Environment may allow an untrusted applet to access the system clipboard.

See Sun Security Bulletin #00208

February 23, 2001 - Java Runtime Environment unauthorized command execution

See Sun Security Bulletin #00201

November 29, 2000 — Potential Security Issue in Class Loading

Given its position as a leader in enterprise and network computing, Sun takes extreme precautions with regard to security and treats all security matters with the utmost importance. Through its own research and rigorous testing, Sun has discovered a potential security issue in the Java Runtime Environment that affects both Java Development Kit (JDK) 1.1.x and Java 2 Standard Edition SDK v 1.2.x releases. The issue poses a possible security risk by allowing an untrusted class to call into a disallowed class under certain circumstances. To the best of Sun`s knowledge, there are no known attacks reported based on this vulnerability.

The following update releases are available as a remedy for this issue.

Windows Production and Solaris Reference Releases

JDK/JRE 1.2.2_006 JDK/JRE 1.1.8_005

Solaris Production Releases

JDK/JRE 1.2.2_06 JDK/JRE 1.1.8_12

Linux Production Release

JDK/JRE 1.2.2_006

The vulnerability was fixed in Java 2 Standard Edition SDK v 1.3.0.

The HotSpot 1.0 and 1.0.1 virtual machines are affected with this vulnerability. HotSpot 2.0 is not affected by this vulnerability. HotSpot 1.0 and 1.0.1 virtual machines should no longer be used. Users that cannot move to Java 2 Standard Edition SDK v 1.3 should revert to the default virtual machine in JDK/JRE 1.2.2_006 (Windows or Solaris reference). Those users wishing to take advantage of the performance of HotSpot 2.0 should migrate to Java 2 Standard Edition SDK v 1.3.0.

This issue may or may not affect other vendors' Java implementations which are derived from Sun`s JDK source base. Sun has notified and made the remedy available to its Java Licensees. To the best of Sun's knowledge, Netscape Navigator and Microsoft Internet Explorer are not exposed to this vulnerability.

August 10, 2000 — Brown Orifice Exploit

In certain versions of Netscape Navigator and Communicator, there is a security vulnerability. Mr. Brumleve also discovered a less severe vulnerability in the implementations of older versions of Sun's Java Development Kit (JDK) and Java Plug-in.

Sun and its partners take all security matters very seriously. A plan is in place to make remedies available quickly for all affected products.

Security vulnerability description

The Netscape bug, dubbed "Brown Orifice", is believed to be present in version 4.x of Netscape Navigator and could allow a malicious, unsigned Java applet to read and dispense files from a user's computer as if that user's computer were a web server. Please contact Netscape for details on this bug.

In Sun's JDK 1.1.x implementation, an implementation bug allows an untrusted applet to accept connections from hosts other than the host t hat the applet came from. While this should not be allowed, this bug by itself does not allow the applet to violate other Java sandbox re strictions.

Users of the following products and platforms are at risk:

Netscape

Netscape users should go to Netscape's web site for more information on the affected products.

Java Development Kit (JDK) and Plug-ins

All versions of:

• JDK 1.1.x
• Java Plug-in 1.1.x
• Java Runtime Environment (JRE) 1.1.x

Users of the following products and platforms are NOT at risk:

• All versions of Microsoft Internet Explorer
• All versions of Java 2 Platform, Standard Edition 1.2 or greater and corresponding Java Plug-ins

Interim remedies

There are several solutions available to protect against the Brown Orifice exploit.

For Java developers:

• Migrate Java products to Java 2 Standard Edition 1.2 or greater
• Modify applets to utilize the Java 2 Runtime Environment with the corresponding version of the Java Plug-in

Corrected products

Sun and Netscape have worked together to make fix available for Navigator and Communicator. Netscape 4.75 is now available: http://home.netscape.com/computing/download/index.html.

Please note that the dates below are our target dates for the releases and these dates may be subject to change. Please check back as this page will continue to be updated.

The current schedule is as follows:

JDK 1.1.x Reference Updates

Windows/Solaris Reference Version	Status
JDK/JRE 1.1.8_005/Java Plug-in 1.1.3_003	POSTED

JDK 1.1.x Solaris Production Updates

Solaris Production	Status
JDK 1.1.8_12	POSTED

February 2, 2000 - Applet Deployment Enhancement

JAR files containing support classes for applets can now be placed in the Java Plug-in software's lib/applet/ directory. This reduces startup time for large applets by allowing applet classes to be pre-loaded from the local file system by the applet class-loader, providing the same protections as if they had been downloaded over the network.

Classes installed in the application class path of the Java 2 Platform are subject to the security policy and generally are not trusted by the default policy file and the application class loader/launcher. This enhancement provides similar support specifically for applet deployment via the Java Plug-in software on both 1.1.x versions of the Java platform and on Java 2 Platforms.

Classes installed in the class path of 1.1.x versions of the Java platform are treated as if they were system code, i.e. they are fully trusted and have access to the underlying system resources. Vulnerabilities in such locally installed classes could be exploited by a downloaded applet. However, storing classes locally can be desirable to meet objectives such as improving the performance of applets. This applet deployment enhancement delivers the benefits of locally installed applet classes while minimizing the risks.

If your applet deployment strategy includes installing support classes locally, install them in the lib/applet/ library and use the Java Plug-in product.

This applet deployment enhancement is available via the Java Plug-in product on the Java Software web site. All Java Plug-in product versions currently available there (versions 1.1.1, 1.1.2, 1.1.3, 1.2.1, 1.2.2) contain this enhancement. The soon-to-be-released version 1.3 of the Java Plug-in product will also contain this enhancement. In addition, the enhancement is included as part of the Java Plug-in product version 1.1.2 for the Solaris operating environment, available from the Sun web site.

April 14, 1999 - Unverified classes can be constructed

Recently, Paul Haahr at Jive Technologies notified us of a bug that allows unverified classes to be constructed. This bug affects JDK 1.1.x software only. The fix for this bug is included in JDK 1.1.8, published on April 12, 1999. The JDK 1.1.6_006 and JDK 1.1.7_003 software were released in April 1999, and they contain fixes for this bug, as well as Sohr's March 26 bug.

March 26, 1999 - Unverified Code

A newly discovered implementation bug in the JDK software poses a potential security risk by allowing an untrusted applet to execute unverified code under certain circumstances. This bug was discovered by Karsten Sohr of the University of Marburg in Germany. He reported it to the Princeton Secure Internet Programming Lab, headed by Prof. Ed Felten, who reported it to us on March 11, 1999. It is an implementation bug and not a flaw in the Java security model or architecture. This bug affects both JDK 1.1.x and Java 2, as well as Netscape Navigator 4.x and other licensee products using Sun's JDK source base.

Sun takes every security-related implementation flaw in the Java platform code very seriously and we thank the Princeton team for their contribution to the Java platform. We look forward to a continuing collaboration with them.

July 22, 1998 - Princeton Classloader Attack

This situation doesn't apply to applications based on the standard JDK software.

For the record, for the Java 2 SDK, v1.2, we added a check to make sure that for each class c,

	FindClassFromClass("java/lang/Throwable", c) ==
                     [the system java.lang.Throwable class]

The fix is done in 1.2. There is no way for applets to create class loaders in the JDK 1.1 software, so there is no immediate security problem for applications built on standard JDK 1.1 software.

June 26, 1998 - RSA PKCS1 risk in SSL

RSA Data Security Inc. announced a possible protocol security risk involving servers using SSL (Secure Socket Layer) encryption. For more details, see http://java.sun.com/security/sslrisk.html.

June 23, 1997 - UW Team Alerts JavaSoft about verifier implementation bug

A team of scientists including Emin Gun Sirer, Sean McDirmid, and Prof. Brian Bershad at the University of Washington's Department of Computer Science and Engineering, has been developing a verification technology for Java bytecodes as part of the Kimera Java Security Project. The team recently informed JavaSoft that they discovered an implementation bug in the JavaSoft JDK 1.1.2 verifier. For more details, see http://java.sun.com/security/23jun97.html

University of Washington Verification System (May 16, 1997)

A team of researchers at the University of Washington independently developed a Java verification system that led to the discovery of a bug in the JDK 1.1.1 verifier. There are no known security attacks based on exploiting the bug, but JavaSoft has issued a fix to licensees. The fix will be available publically in the JDK 1.1.2 release, due out by the end of May, 1997.

Due to the large number of media inquires, additional details about the University of Washington verifier project are posted at http://java.sun.com/security/UWdetails.html. (May 21, 1997)

JDK 1.1.1 Signing Flaw, (April 29, 1997)

The Secure Internet Programming team at Princeton University notified JavaSoft of a flaw in the way the Java runtime manages identities of signers. JavaSoft is testing the fix and plans to ship it to licensees within 48 hours. Full details here.

Privacy hole, related to IP addresses, fixed in May 1996 JDK 1.0.2 (March 17, 1997)

Recently we've been getting lots of inquires about an alleged privacy attack on the Java sandbox. The privacy attack is that an applet calls getLocalHost() to find out the IP address of the computer that it's running on. This is not a big deal on the open internet, since IP addresses are clearly well-known and publicized in the internet routing tables. But if the computer running the applet resides inside a firewall, the IP address should remain hidden from the visiting applet. This is exactly what was implemented at JavaSoft about a year go, in time for the May 1996 JDK 1.0.2 release. An applet that calls getLocalHost() will get the loopback host ("localhost/127.0.0.1") as an answer. This is a generic handle to the local computer, which does not reveal any private information that should remain private.

Fix Delivered for Virtual Machine bug (March 5, 1997)

As part of our ongoing internal security audit at JavaSoft, our engineering team came across a bug in the implementation of the verifier in the Java Virtual Machine.

Within 24 hours, we investigated the bug and evaluated a fix. We tested the fix and created a patch for our licensees. As we always do, we notified our licensees and shipped the patch immediately. We encourage each of our licensees to include the patch in their products as soon as possible.

We are aware of no actual attacks involving this bug. It is important to note that a program written in the Java language and compiled by a standard compiler cannot access or exploit this bug. This depends on someone hand-crafting "evil byte code" and trying to slip it by the verifier. The theoretical attack is complex and extremely difficult to exploit.

Update on Java Security and ActiveX (February 25, 1997)

We've received lots of inquiries on the recently publicized Chaos Computer Club's theoretical hack into Microsoft's ActiveX. This well-established hacker organization, headquartered in Hamburg, demonstrated on German television how its members could use an ActiveX control to theoretically electronically transfer funds from an individual's bank account without using a personal identification number or a transaction number.

Executable code on the Internet is a complex security issue. That's why Java was designed from the ground up for complex networked environments, and our basic architecture takes into account using executable code from unknown sources. Check out the rest of this document, Frequently Asked Questions--Java Security, for a full description of the Java applet security model.

In brief, all Java applets run in a protected space that prohibits access to local disk. Encryption and certification can be used in conjunction with applets to add extra levels of security in trusted or controlled environments--like corporate intranets. JavaSoft has included digital signature capability in the Java Development Kit, JDK 1.1, which shipped February 18, 1997.

ActiveX uses a different model. Because it allows arbitrary binary code to be executed, a malicious ActiveX component can be written to remove or alter files on the user's local disk or to make connections to other computers without the knowledge or approval of the user. There is also the risk that a well-behaved ActiveX component could have a virus attached to it. Unfortunately, viruses can be encrypted just as easily as ordinary code.

In some cases, digital signing is adequate. In cases where stronger protection is required, Java allows the alternative of running untrusted code securely, which is extremely important for the Internet.

The most complete security solution for complex networks like the Internet requires not a single security solution, but many. Unlike ActiveX, Java was designed from the ground up for secure network computing. Security is fundamental to Java, not bolted on.

Web Spoofing (December, 1996)

The Secure Internet Programming team at Princeton University published a technical report describing an Internet security attack they name web spoofing. In this scenario, an attacker

• creates a shadow copy of a web page
• funnels all access to the web page through the attacker's machine
• tricks the unwary consumer into revealing sensitive or private data, such as PIN numbers, credit card numbers or bank account numbers

Web spoofing requires that the attacker be able to interpose his machine between the server and client, in a man-in-the-middle attack.

Web spoofing does not require and does not exploit Java technologies.

If consumers are using a browser that does not have JavaScript (LiveScript) enabled, they will be able to tell that they are being spoofed when they notice either of these visual cues in the browser status line:

• When a connection is made, the status line shows which host the browser is connecting.
• When you hold the mouse over a link, the address you will be taken to when you click on the link is displayed in the status line.

If consumers use a browser with JavaScript (LiveScript) enabled, then even these rudimentary and subtle alerts can be hidden by a malicious script. Recall that such scripts are not written in Java, and are not subject to the Java security model. In that case, consumers would have no way of noticing the spoofing. For this reason, people concerned about web spoofing attacks might consider disabling scripting languages.

Note that in any case, some novice internet consumers will not be sensitive to visual cues, even if they aren't obliterated by scripting languages. However, it is often the case on the internet that web spoofing attacks are noticed quickly and given wide publicity. Given the nature of the web and how quickly email bounces around the net, there is strong likelihood that a spoofed web site will be found out quickly and publicized widely.

JDK 1.1 beta (December 13, 1996)

JDK 1.1 Beta 2 fixes the implementation inconsistency in the javakey security tool that caused jar files to be signed with invalid signatures. In JDK 1.1 Beta 1, signature checking always failed, and so all applets ran as untrusted, with minimal permissions enabled. This made the code signing feature unusable, but was not a security hole.

Please report anything else you find to http://java.sun.com/products/jdk/1.1/bugreport.html.

Illegal type cast attack (June 2, 1996)

David Hopwood, a researcher in the UK, has uncovered a way to manipulate the way objects are assigned and the way they collaborate, in order to undermine the Java type system. Hopwood contacted JavaSoft directly regarding the bug, and we have had a team working on a fix from the time that we were notified. We are also applying Hopwood's model to conduct a security review, to determine if there are other bugs that may apply. Fixed in JDK 1.1; fixes propagated to all Java licensees by mid-June 1996

New twist on previous classloader attack (May 18, 1996)

The May 18 edition of the New York Times reported that Ed Felten, Drew Dean and Dan Wallach of Princeton University's Safe Internet have found a new way to get past system restrictions on creating a classloader. This attack builds on work done by Tom Cargill. The applet sandbox security model states that applets are not allowed to create and use classloaders to define classes. Once an applet has its own classloader, it can use it to define and execute classes that would otherwise be barred from execution. Fixed in JDK 1.0.2, and in Netscape Navigator 3.0b4.

Hostile Applets (April, 1996)

A number of hostile web pages, that host malicious or rude resource-consuming applets, are popping up on the web. These sites demonstrate problems related to denial of service attacks. We are investigating ways to better monitor and control resource consumption of applets. Here are more details.

URL name resolution attack (April, 1996)

For a specific firewall-protected network configuration, an applet downloaded from a client inside the firewall would be able to connect to a single specific host behind the firewall. (It requires an unusual network configuration, but here are the details.) Fixed in JDK 1.0.2 and in Netscape Navigator 2.02.

Verifier implementation bug (Mar, 1996)

Researchers at Princeton found an implementation bug in the Java bytecode verifier. The verifier is a part of Java's runtime system which checks that applets downloaded over the Internet adhere to Java's language safery rules. Here's our response. Fixed in JDK 1.0.2 and in Netscape Navigator 2.02.

Class loader implementation bug (Mar, 1996)

David Hopwood at Oxford University found a bug in the class loader that could be exploited to load illegal byte code, which could then be used to load a class referenced by an absolute path name. Fixed in Netscape Navigator 2.01 and in JDK 1.0.1.

DNS attack (Feb, 1996)

Drew Dean, Ed Felten and Dan Wallach from Princeton described an attack on the applet security model, based on exploiting how the applet security manager uses DNS for name/IP address resolution. Sun's response to this security bug was posted to comp.lang.java on Feb 21. Fixed in Netscape Navigator 2.01 and in JDK 1.0.1.

Steve Gibbons also independently suggested this attack scenario: see http://www.aztech.net/~steve/java/

JavaScript (Feb, 1996)

JavaScript is a scripting language used with Netscape Navigator 2.0. There have been reports of privacy problems with JavaScript, and Netscape is committed to addressing those concerns. JavaScript cannot be used to invoke Java applets. The privacy problems reported with JavaScript are not present in Java applets.

See Also: Security and the Java Platform