Killing Off the Competition (Ch. 4, Sec. 7) [Securing Java]

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

Section 7 -- Killing Off the Competition

The Business Assassin applet discussed earlier combines two dirty tricks. The first trick is to spawn a monitoring thread to watch for applets from another site. The second trick is to kill the threads of any incoming applets. According to the rules, an applet should not be allowed to kill the threads of other applets. Unfortunately, what should not be allowed to happen and what actually can happen are not always the same. Implementation bugs in the security check for thread access for all JDKs through 1.1.5 allow downloaded applets to access threads outside their own thread group. Killing a thread is easy. Here is a code fragment that does it:

private static void ThreadMurder(Thread t){
   t.stop();
}

You may wonder why the t.stop() method is inside the ThreadMurder() method. This code will kill any thread t. It would be wise for the thread calling ThreadMurder() not to kill itself. A test inside ThreadMurder() is an obvious way to protect the calling thread. All that is needed is a simple name check. If the thread turns out to be checking itself, a decision is made to do nothing.

To make an applet that kills all threads not belonging to itself requires a bit more work. For clarity, let's call this applet AssassinApplet. A recursive approach to AssassinApplet is probably best. The basic outline is:

Starting with the current thread group, ascend to the root thread group.
From the root, recursively descend through all threads and thread groups below.
Kill each thread encountered (but not self).

This approach is both very nasty and very effective.

If coded as just shown, an AssassinApplet would be able to kill all other applets running when it starts (a nice way to shut the NoisyApplet up!). It would also kill all applets that it comes across after that. Since it is possible within our framework for the applet to name who should not be killed, the AssassinApplet could run in tandem with other chosen applets. In fact, using the AssassinApplet at all times is a half-baked alternative to turning Java off! Just run the AssassinApplet once at the beginning of a session and after that, all applets encountered from then on are guaranteed to be killed soon after arrival.

The good news is that we can defeat the ThreadMurder attack shown here using the try/finally approach discussed earlier. The bad news is any hostile applet can, too.

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