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
Sun has a remedy for the vulnerability and it will be included with the following Update releases for Linux:
Windows Production and Solaris Reference Releases
Solaris Production Releases
Linux Production Release
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.
Sun and its partners take all security matters very seriously. A plan is in place to make remedies available quickly for all affected products.
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.
Netscape users should go to Netscape's web site for more information on the affected products.
All versions of:
There are several solutions available to protect against the Brown Orifice exploit.
For Java developers:
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 Solaris Production Updates
|Windows/Solaris Reference Version||Status|
|JDK/JRE 1.1.8_005/Java Plug-in 1.1.3_003||POSTED|
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.
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.
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.
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.
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 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.
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.
Please report anything else you find here.
Steve Gibbons also independently suggested this attack scenario: see http://www.aztech.net/~steve/java/
See Also: Security and the Java Platform