Opening Untrusted Windows (Ch. 4, Sec. 4) [Securing Java]

Malicious Applets: Avoiding a Common Nuisance
CHAPTER SECTIONS: 1 / 2 / 3 / 4 / 5 / 6 / 7 / 8 / 9

Section 4 -- Opening Untrusted Windows

A more serious denial-of-service attack than browser-killers involves opening large numbers of very large windows. There are a couple of reasons why this kind of attack should be considered more severe. The side effects of this attack tend to freeze access to the keyboard and mouse while the applet runs. This makes the applet harder to control. Also, the way these windows are created and mapped makes it possible to pop up untrusted Java applet windows without the mandatory warning they are supposedly required to display.

A denial-of-service applet based on this idea would be very similar to the ones we discussed on page 128, with the addition of the window-popping code shown here:

// In the code below, littleWindow is of type Frame
// Adapted from an idea by Mark LaDue
try {
// create a window
littleWindow = new bigFrame("Whocares"); 
// make it very big
littleWindow.resize(1000000, 1000000);  
// position it to cover everything
littleWindow.move(-1000, -1000);    
// finally, open the window
littleWindow.show();       
}
catch (OutOfMemoryError o) {
repaint();
}
class bigFrame extends Frame {    // constructor method
  Label 1;
  bigFrame(String title)  {
   super(title);
   setLayout(new GridLayout(1, 1)); 
   Canvas whiteCanvas = new Canvas();
   whiteCanvas.setBackground(Color.white);
   add(whiteCanvas);
  }
}

This code opens a very large (1-million x 1-million pixel) white window without the supposedly mandatory untrusted Java applet window message. Put this code in a loop so many windows pile on top of each other, and voilá, an applet that consumes major resources in an interesting new way.

The act of generating many windows all at the same time causes many window events to fill the window manager's event queue. This effectively disables the mouse and keyboard, since they talk to the machine through window events themselves. The console of the workstation displaying these very large windows freezes up. There are two things users can do when an attack like this is leveled against them: Go to another machine on the same network to kill the offending browser processes, or reboot (usually with the three-fingered salute).

The ability to open a window without the mandatory untrusted window banner is interesting in its own right. Using variants of such code, it is possible to spoof Web site password panels. This leads to interesting social engineering attacks, wherein an unsuspecting user is asked to provide his or her password due to a spurious security alert event. Many users fall for such schemes. After collecting login and password information, a malicious applet can mail off the information to a collection site for later use by a cracker.

Spoofing Web site password panels is an interesting illustration of how an attacker can whip up a serious attack out of a set of holes that each look fairly innocuous. An adversary could create an applet that appears to stop when the user leaves its page, but really keeps a thread lurking in the browser. That thread could use monitoring techniques to determine when the user has visited a particular target site. It could then display a spoof of the target site's log-in panel. The user would probably be fooled, since the bogus log-in panel would appear at the "right" time.

Applets that use a social engineering attack to collect possibly sensitive information can be found at the DigiCrime Web site. Surf there at your own risk.

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