Windows thread overrun from a Java Applet

Whether you found this page by searching Yahoo, reading a newsgroup, received an e-mail, or any other way, you obviously came here for one of two reasons 1) you want to see what the talk is about, or 2) some "friend" of yours wanted you to get nailed by the problem.

The second reason is why I created this page. I've added this as a layer of indirection, and as a way to add information as more becomes available. In the interest of security, I will periodically be changing the name of the applet and the page it's on, so that not too many people have problems from direct links

Background

I found this flaw as a part of some research I did beginning summer 1998, and ending December of the same. I have personally reported this security flaw on two occasions, and I am certain that the overseeing professor (B Clifford Neuman, ISI) reported it himself. I have held off on creating a public spectacle of this flaw for several months in an effort to give Sun and/or Microsoft an opportunity to correct the issue.

How It Works

It's rather simple, the applet simply creates more and more threads until the kernel panics. Probably the worst part is that the download is only 941 bytes, smaller than a normal picture. Basically that means that even running on a 28.8 modem the download is less than 1/3 of a second, and by the time most people would consider that there is a problem the applet is running. There is also an equivalent standard executable version, but I'm not going to discuss it here.

Isn't this just a DoS (Denial of Service) attack?

The debate rages on, there are some very valid points on both sides of the argument, but in the end, it doesn't really matter, this entire class of problems can be solved (more information)

The Fix

It should be rather simple for either Microsoft or Sun to fix it. The fix would consist simply of adding threadsafe thread counting to the thread spawning code, as well as the thread termination code. It would be most logical for Microsoft to fix the code because a standard executable that does the same thing.

Why I'm Bringing The Issue Up At All

Knowledge of the applet has been spreading slowly and may soon become an issue, so I'm attempting to get real information available before a problem occurs.

Known Results

 Windows 95

Ie3.x: No data

Ie4 (no alterations): crash

Ie4 (jdk 1.2): crash

Ie4 (jdk 1.21): crash

Ie5 (no alterations): crash

Ie5 (jdk 1.21): crash

Appletviewer (1.1.8, 1.2, 1.21): crash (very fast to very slow)

Netscape Communicator 4.x (no alterations): crash, there has been one report of the browser crashing without the computer crashing

 Windows 98

Ie3.x: No data

Ie4 (no alterations): crash

Ie4 (jdk 1.2): crash

Ie4 (jdk 1.21): crash

Ie5 (no alterations): crash

Ie5 (jdk 1.21): crash

Appletviewer (1.1.8, 1.2, 1.21): crash (very fast to very slow)

Netscape Communicator 4.x (no alterations): crash, there has been one report of the browser crashing without the computer crashing

 Windows NT: System performance degrades significantly but does not stop, but the browser hangs eventually (and attempting to start a new process can cause a crash), system eventually becomes usable again

 OS2 Warp: System performance degrades significantly but does not stop, but the browser hangs eventually (and attempting to start a new process can cause a crash), system eventually becomes usable again

 UNIX (Solaris, Tru64, Linux (Alpha)): System remains usable, the browser hangs eventually

 Macintosh: System remains usable, the browser hangs or crashs

Please email me with any new results (or even if you want to confirm the posted results)

The Source

I've received numerous complaints about my releasing the source code. I'm taking this time to explain the reasoning behind it. The HTTP protocol is publicly available as an RFC, which makes it easy enough for any would-be hacker to grab the applet without too much difficulty (but no one has complained about me making this applet available publicly). Therefore releasing the source code serves only to make it possible for security measures to be developed quickly, and efficiently, as well as developing protection against the entire class of attacks instead of just searching for this applet.

The Page

BEWARE!!!! CLICKING HERE IS NOT RECOMMENDED.

The Source

Questions

Please feel free to email me at ashwood@usc.edu if you have any questions regarding this applet.

Reporting abuse

If you have run across a page that you believe has this applet (or one similar) running on it, please e-mail me at ashwood@usc.edu ASAP. I will gladly maintain the list of sites.

I am not the first to find this problem

I have not yet had the opportunity to verify it, but I have been informed that in the book titled "Tricks of the Java Programming Gurus" published in 1996.