# Re: JSECURITY Issue: FAQ

Marianne Mueller (Marianne.Mueller@Eng)
Wed, 9 Sep 1998 11:58:12 -0700 (PDT)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Amitabh: "JDK1.2beta4 vs. JDK1.2beta3"
- Previous message: Bruce A. Wittmeier: "Using Javakey"
- Maybe in reply to: Jan Luehe: "JSECURITY Issue: FAQ"

--Pod_of_Seals_115_000
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: t2IF0JwD2+r23dIk+52FUw==

The URL

http://java.sun.com/sfaq/chronology.html
works OK. Attached it the HTML page in case you have trouble
connecting.

cheerios,
mrm

--Pod_of_Seals_115_000
Content-Type: TEXT/html; name="chronology.html"; charset=us-ascii; x-unix-mode=0444
Content-Description: chronology.html
Content-MD5: LrH+XLSM4PhT5oIiKRC2dA==

Title

Java Security
Security Top | Security FAQ | Security Q&A Archive
  Chronology of security-related bugs, 07/22/98 If you would like to send a description of a possible bug to the security team, send email to java-security-bugs@puffin.eng.sun.com. July 22, 1998 - Princeton Classloader Attack This situation doesn't apply to applications based on the standard JDK. For the record, for JDK 1.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 JDK 1.1, so there is no immediate security problem for applications built on standard JDK 1.1. 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(tm) 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 Java 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 Top Security FAQ Security Q&A Archive This page last modified 07/22/98

--Pod_of_Seals_115_000--

- Next message: Amitabh: "JDK1.2beta4 vs. JDK1.2beta3"
- Previous message: Bruce A. Wittmeier: "Using Javakey"
- Maybe in reply to: Jan Luehe: "JSECURITY Issue: FAQ"