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.
|