----------------------------------------------------------------------------- SUN MICROSYSTEMS SECURITY BULLETIN: #00134, 29 March 1996 ----------------------------------------------------------------------------- BULLETIN TOPICS In this bulletin Sun announces the availability of version 1.0.1 of the Java Developer's Kit. This version contains fixes for two security-related bugs discovered last month in JDK v1.0. One bug relates to DNS, the "Domain Name Service" which resolves Internet addresses. The second problem, called the "classloader" bug, involves class file verification in the Java classloader. We also respond in this bulletin to a third vulnerability. This bug, which appears in the bytecode verifier, was disclosed to us just last Friday (and publicly disclosed this Monday, 25 March). We'll briefly discuss the problem technically and explain what we are doing to fix it. All three bugs have been the subject of both news reports and security bulletins from teams such as CERT. We have cross-referenced some of these reports in Section V. Although Sun is not aware of attacks to date based on any of these vulnerabilities, we recommend that developers obtain, install, and use the new JDK as soon as possible. In addition, source licensees should obtain the source-level fixes for the bytecode verifier bug as soon as those are available. Each weakness has been broadly publicized, and may be exploited in the future. I. Who is affected and what to do II. How to get the fixes III. Understanding the vulnerabilities IV. A note about unsupported software V. Acknowledgments and references APPENDICES A. How to obtain up-to-date information about Java B. How to report or inquire about other Sun security problems C. How to obtain Sun security bulletins or quick status updates ----------- Permission is granted for the redistribution of this Bulletin for the purpose of alerting Sun customers to problems, as long as the Bulletin is not edited and is attributed to Sun Microsystems. Any other use of this information without the express written consent of Sun Microsystems is prohibited. Sun Microsystems expressly disclaims all liability for any misuse of this information by any third party. ----------------------------------------------------------------------------- SUN MICROSYSTEMS SECURITY BULLETIN: #00134, 29 March 1996 ----------------------------------------------------------------------------- I. Who is affected and what to do The JDK itself is a development kit, and it can safely be used to develop applets and applications. A. Developers using version 1.0 of the JDK If you are using JDK v1.0 to develop your own browser (or other Java-based software which loads classes or opens network connections), you will need to rebuild your application, using v1.0.1, to ensure that your software is free of the first two vulnerabilities. The API is unchanged. The only Java-capable browser in general public release today is Netscape's Navigator 2.0. On 14 March 1996 Netscape released Navigator 2.01, which fixed the first two vulnerabilities described above. See "http://home.netscape.com" for details and a discussion of Netscape's plans for additional security enhancements. B. Users of previous appletviewer versions If you are using the appletviewer from v1.0 of the JDK, replace it with the one from the new 1.0.1 version of the JDK. (For downloading instructions, see Section II.) This closes the first two vulnerabilities. If you choose to use the JDK's appletviewer as a rudimentary browser, do not use it to browse applets from untrusted sources until you have installed the v1.0.2 browser. II. How to get the fixes A. Availability The new Java Developer's Kit was made available for the Solaris/SPARC and Win32 platforms on 15 March 1996. The bug fixes will also appear in the next Macintosh beta release, which will be ready soon. The full JDK v1.0.1 source release is now available from the usual sources. B. Downloading the new version To download version 1.0.1 of the Java Developer's Kit, point your browser to "http://java.sun.com/download.html", and follow the instructions there. III. Understanding the vulnerabilities A. The DNS-related bug, and how we fixed it This bug makes possible an attack based on a well-known DNS vulnerability. The Java Applet Security Manager enforces a policy concerning which hosts an applet is allowed to open a network connection to. It's supposed to allow connections only to the host from which the applet came. But the code in v1.0 implements this restriction by checking the host name, not the actual IP address, depending on DNS to return the correct number when asked to look up the name. This dependence means that if the DNS hostname lookup is subverted, the applet could be allowed to open a connection to an arbitrary host on the Internet. Such a connection could then be potentially misused in several ways--for example, to attack the newly-connected-to host. By initiating an attack in this way, from behind an enterprise firewall, an attacker might be able to gain access to previously inaccessible systems. In v1.0.1 of the JDK, we foreclosed such attacks by fixing the implementation of the security policy. The applet hostname is looked up only once via DNS; from then on, the applet is allowed to connect only to that single numerical IP address. B. The classloader bug, and how we fixed it This second bug involves a potential attack based on fooling the appletviewer (or a Java-capable browser) into loading a class file that it's not supposed to load. The attack would only work if a maliciously constructed class file, and a specially constructed library file, had previously been installed on the target system by another means. Loading applets over the net is handled by the classloader, which checks class files to ensure that they conform to the Java language constraints. One constraint is that any file used by the class will be inside the area set aside for that purpose. But the JDK v1.0 classloader, improperly, did not reject class files that had been tampered with to refer to a class name that begins with "/". In JDK v1.0.1, it does. Any class file that attempts to refer to absolute path names is rejected. Note that ordinary operation of the javac compiler will not create class files like this.They would need to be created by a malicious compiler, or by someone manually modifying a ".class" file. C. The bytecode verifier bug The bytecode verifier bug makes it possible for an applet to generate and execute raw machine code on the machine where the browser is running. This means that a maliciously written applet can perform any action that the legitimate user can perform: for example, an applet can read, delete, or change files that the user owns. Sun will supply source-level fixes to source licensees within the next few days. The fixes will also be included in the next JDK version, v1.0.2, which will be released within the next several weeks. IV. A note about unsupported software Sun made available last year a demonstration version of a browser called "HotJava". It is not a product, and is not a part of the Java Development Kit. Still, some customers have asked whether it, like other Java-enabled software, is vulnerable to these attacks. The HotJava (version alpha3) that Sun has distributed to date is proof-of-concept software only, and is not supported. HotJava (alpha3) uses a different security architecture than JDK 1.0 or JDK 1.0.1., and so may not be vulnerable to all of the attacks described in this bulletin. (Since it is unsupported, however, we have not tested it for these or any other reported security vulnerabilities.) In any event Sun does not recommend the use of this unsupported software as a primary browser. Later this year (as have already been announced) Sun will release a new version of HotJava, as part of an expanded Web application toolkit product. This new product, based on the JDK, will contain fixes for all of the security vulnerabilities discussed in this bulletin. V. Acknowledgments and references A. The DNS-related bug The DNS bug was first reported by Drew Dean, Ed Felten, and Dan Wallach at Princeton University. They have made additional information available at "http://www.cs.princeton.edu/~ddean/java". B. The classloader bug The classloader problem was made public by David Hopwood of Oxford University. C. The bytecode verifier bug The bytecode verifier bug was also first reported by Drew Dean, Ed Felten, and Dan Wallach of Princeton University. D. CERT, and other Incident Response teams The first formal advisory on one of these problems was CERT CA-96.05, dated 5 March 1996. CIAC Note 96-01, issued 18 March 1996, discusses these (and other) problems as well, as does NASIRC B-96-11-B, issued on 27 March, and CERT CA-96.07, from 29 March. Sun acknowledges with thanks both CERT Coordination Center (Carnegie Mellon University) and CIAC (the U.S. Department of Energy's Computer Incident Advisory Capability) for their assistance in the preparation of this bulletin. Sun, CERT, CIAC, and NASIRC are all members of FIRST, the Forum of Incident Response and Security Teams. For more information about FIRST, visit the FIRST web site at "http://www.first.org/". For information about the upcoming 8th FIRST Conference and Workshop (Santa Clara, CA, July 28-31, 1996) see "http://ciac.llnl.gov/firstconf". A. How to obtain up-to-date information about Java For information on how to download JDK v1.0.1, see: http://java.sun.com/download.html For information about what applets may and may not do (and an excellent discussion of applet security in general) consult: http://java.sun.com/sfaq/ For details on the lowest levels of the Java security mechanisms, see: http://java.sun.com/sfaq/verifier.html For a more detailed statement on the DNS spoofing attacks and Java, see: http://java.sun.com/sfaq/dns.html For announcements about "What's New" with Java, check: http://java.sun.com/new.html B. How to report or inquire about Sun security problems To make inquiries or comments about Java security, use the channels listed in Section A--or, if you are a Java licensee, use any normal channels of communication with Javasoft. If you discover a security problem with other Sun software, or wish to inquire about a possible problem, contact one or more of the following: - Your local Sun answer centers - Your representative computer security response team, such as CERT - This office. Address postal mail to: Mark Graff Sun Security Coordinator Sun Microsystems, Inc. M/S MPK17-103 2550 Garcia Avenue Mountain View, CA 94043-1100 Phone: 415-786-5274 Fax: 415-786-7994 E-mail: security-alert@Sun.COM We strongly recommend that you report such problems to your local Answer Center. In some cases they will accept a report of a security bug even if you do not have a support contract. An additional notification to the security-alert alias is suggested but should not be used as your primary vehicle for reporting a bug. C. How to obtain Sun security bulletins or quick status updates 1. Subscription information Sun Security Bulletins are available free of charge as part of our Customer Warning System. It is not necessary to have a Sun support contract in order to receive them. To receive information or to subscribe or unsubscribe from our mailing list, send mail to security-alert@sun.com with a subject line containing one of the following commands. Subject Information Returned/Action Taken ------- --------------------------------- HELP An explanation of how to get information LIST A list of current security topics QUERY [topic] The mail containing the question is relayed to a Security Coordinator for a response. REPORT [topic] The mail containing the text is treated as a security bug report and forwarded to a Security Coordinator for handling. Please note that this channel of communications does not supersede the use of Sun Solution Centers for this purpose. Note also that we do not recommend that detailed problem descriptions be sent in plain text. SEND topic Summary of the status of selected topic. (To retrieve a Sun Security Bulletin, supply the number of the bulletin, as in "SEND #103".) SUBSCRIBE Sender is added to the CWS (Customer Warning System) list. The subscribe feature requires that the sender include on the subject line the word "cws" and the reply email address. So the subject line might look like the following: SUBSCRIBE cws graff@sun.com UNSUBSCRIBE Sender is removed from the CWS list. Should your email not fit into one of the above subjects, a help message will be returned to you. Due to the volume of subscription requests we receive, we cannot guarantee to acknowledge requests. Please contact this office if you wish to verify that your subscription request was received, or if you would like your bulletin delivered via postal mail or fax. 2. Obtaining old bulletins Sun Security Bulletins are available via the security-alert alias and on SunSolve. Please try these sources first before contacting this office for old bulletins. ------------