Last updated on January 25, 2002. A complete history can be found at the end of this page. Special thanks to Juergen Kreileder from the Blackdown Java-Linux Team and Joakim Dahlstedt from Appeal Virtual Machines for making their fixes available so quickly.
Some Java virtual machine implementations are vulnerable to a denial of service attack in which remote clients can kill a Java server process by sending it urgent data. This vulnerability will be documented by the CERT Coordination Center as Vulnerability Note VU#998279.
A remote attacker can bring down or hang a Java process running on a vulnerable Java virtual machine by sending it urgent data on a network connection. The following client and server programs can be used to simulate the attack:
Note: Since Java does not support urgent data until version 1.4, you need to compile and execute the client side with Java version 1.4 or later. The server side requires only Java version 1.0.2 or later to compile and run. I have no reason to believe the actual attack program is written in Java. In fact, the actual attack program seems to be more effective than the simulation programs I have written.
I ran the client side of the test on a 500-MHz Intel Pentium III machine running Microsoft Windows 2000 Service Pack 2 with Java 2 SDK, Standard Edition, version 1.4 Beta 3:
java version "1.4.0-beta3" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-beta3-b84) Java HotSpot(TM) Client VM (build 1.4.0-beta3-b84, mixed mode)
I ran the server side of the test on a 200-MHz Intel Pentium Pro machine running an up-to-date version of Red Hat Linux 7.1 with Linux kernel version 2.4.9 and Glibc version 2.2.4. I used the following shell script to start the server side with various Java virtual machines:
The two machines are connected by a 100-Mbps switched Ethernet network. The TowerJ project file is available below:
I ran the following command on the server side after removing the comment character ("#") for the Java platform to be tested:
./run.sh
I ran the following command on the client side, where ppro is the host name of the machine running the server side:
c:\j2sdk1.4.0-beta3\bin\java Client -h ppro -c 100000
See the file output.txt for a log of the output from the tests.
When the Java virtual machine survives the attack, you should see messages like the following on the server side after all 100,000 messages and urgent data bytes are sent:
Creating server socket on port 8000 ... Accepting connections ... Connection is from 192.168.0.1 (dev.sf.volano.net). Echoing messages from client ... Connection closed by client.
When the Java virtual machine fails to survive the attack, you should see messages like the following on the server side before all 100,000 messages and urgent data bytes are sent:
Creating server socket on port 8000 ...
Accepting connections ...
Connection is from 192.168.0.1 (dev.sf.volano.net).
Echoing messages from client ...
./run.sh: line 4: 3747 Urgent I/O condition
/usr/java/jdk1.3.1/bin/java -classic -showversion Server
With this simulation, sometimes the Java server process terminates immediately, after just a few messages from the client, while other times it takes as many as 60,000 messages from the client before the server side is killed.
The Java server process terminates with exit value 151 after receiving a SIGURG signal with value 23.
(The process exit value is the signal value plus 128.)
The message "Urgent I/O condition" may be printed to the console when the process terminates, especially when running the process in the foreground.
In the case of Appeal JRockit, the server side hangs with no CPU usage instead of terminating execution.
Since the Java version 1.3 server application is never aware of the urgent data, the only solution is to switch to a Java virtual machine implementation which is not vulnerable to the attack or apply the available fixes to those which are vulnerable.
The following Java virtual machines are vulnerable to the attack in my tests.
There may be other Java platforms which are vulnerable to the attack.
The following Java virtual machines are not vulnerable to the attack in my tests.
SIGSEGV segmentation violation (signal value 11) about once every two or three days.
Tower has reproduced the segmentation violation and has core files from the customer to use in debugging.
There may be other Java platforms which are not vulnerable to the attack. See Figure 2 in the Volano Report for the network connection capacity of these Java platforms.
ftp://ftp.tux.org:/java/JDK-1.3.1/i386/FCS-02a.