Security Advisory: Urgent I/O Condition

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.

Overview

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.

Description

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:

Client.java
a Java client that simulates the attack.
Server.java
a Java echo server.

See the Client and Server program documentation for details on the command options.

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:

run.sh
the server startup script.

The two machines are connected by a 100-Mbps switched Ethernet network. The TowerJ project file is available below:

Project.tj
the TowerJ project file.

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.

Impact

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.

Solution

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.

Products affected

The following Java virtual machines are vulnerable to the attack in my tests.

Red Hat Linux 7.1 (Linux 2.4.9, Glibc 2.2.4)

Appeal JRockit Virtual Machine 3.0.0 (build 3.0.0-dax.appeal.se-20011120-1610)
A fix is available in the December 17, 2001, update of JRockit version 3.0.2 or later.
Blackdown Classic VM 1.3.1 (build Blackdown-1.3.1-FCS, green threads, nojit)
A fix is available in the January 16, 2002, update of Blackdown J2SE version 1.3.1-02a-FCS or later.
Sun Classic VM 1.3.1 (build 1.3.1-b24, green threads, nojit)
A fix will be available with release 1.3.1_03 at the end of March 2002. Sun recommends that sites using Sun's version 1.3.1 Classic VM either switch to the HotSpot VM, wait for the fix in release 1.3.1_03, or switch to version 1.4 when it's available. Our testing here at Volano indicates that those using Sun's version 1.3.1 Classic VM should be able to switch to the Blackdown Classic VM version 1.3.1-02a-FCS as a solution. The Blackdown Classic VM is based on the same code as Sun's but contains other important fixes not found in Sun's implementation.

There may be other Java platforms which are vulnerable to the attack.

Products unaffected

The following Java virtual machines are not vulnerable to the attack in my tests.

Red Hat Linux 7.1 (Linux 2.4.9, Glibc 2.2.4)

Tower TowerJ Compiler (version 3.8.1.0 (Tower JRE 1.3.1) x86-linux)
Available as a solution to the vulnerability and supports thousands of simultaneous connections, but experiences an intermittent 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.
Appeal JRockit Virtual Machine (build 3.0.2-dax.appeal.se-20011217-1738)
Available as a solution to the vulnerability and supports thousands of simultaneous connections.
Blackdown Classic VM (build Blackdown-1.3.1-02a-FCS, green threads, nojit)
Available as a solution to the vulnerability and supports thousands of simultaneous connections.
Blackdown Java HotSpot(TM) Server VM (build Blackdown-1.3.1-FCS, mixed mode)
May not be appropriate as a solution to the vulnerability since it supports only a few hundred simultaneous connections.
Sun Java HotSpot(TM) Server VM (build 1.3.1-b24, mixed mode)
May not be appropriate as a solution to the vulnerability since it supports only a few hundred simultaneous connections.
IBM Classic VM (build 1.3.0, J2RE 1.3.0 IBM build cx130-20010925 (JIT enabled: jitc))
May not be appropriate as a solution to the vulnerability since it supports only a few hundred simultaneous connections.

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.

History

November 28, 2001
Attack first reported to Volano Software.
December 4, 2001
Volano reproduced the problem with client and server test programs which simulate the attack.
December 7, 2001
Provided a TowerJ executable for the customer as the only viable alternative to the vulnerable Blackdown version 1.3.1 Classic VM (green threads, nojit).
December 13, 2001
Customer went live with the TowerJ executable, which seems to have worked as a solution against the attacks.
December 15, 2001
Released to the vendors (Sun Security Coordination Team, The Blackdown Project, and Appeal Virtual Machines) and to the CERT® Coordination Center.
December 16, 2001
CERT assigned reference number VU#998279.
December 17, 2001
Appeal Virtual Machines reproduced the problem and fixed it. The fix will be made available on their Web site as JRockit version 3.0.2 starting tomorrow.
December 18, 2001
Sun Microsystems reproduced the problem.
December 20, 2001
Verified the fix in JRockit version 3.0.2 (build 3.0.2-dax.appeal.se-20011217-1738) available from the Appeal Web site.
December 25, 2001
The Blackdown Team reproduced the problem and hope to have a fix available soon after the holidays.
January 7, 2001
Sun Microsystems confirmed that the Java 2 version 1.2.2 and 1.3.1 Classic VMs on Linux are both vulnerable. They have a fix for the problem and are working on plans to make it available.
January 11, 2002
Received a fix from Blackdown as Java version 1.3.1-02a-FCS.
January 13, 2002
Verified that the fix from Blackdown solves the problem in my tests.
January 16, 2002
Blackdown posted the fix for Intel processors as version 1.3.1-02a-FCS, available for download from ftp://ftp.tux.org:/java/JDK-1.3.1/i386/FCS-02a.
January 19, 2002
Sun Microsystems says their fix for the problem will be included in the Java 1.2.2_012 release available at the end of April 2002 and the Java 1.3.1_03 release available at the end of March 2002.
January 21, 2002
Proposed publication date from CERT.
January 23, 2002
Proposed publication from Sun Microsystems.
January 25, 2002
Released to the public.

This site contains articles by John Neffenger about the Java™ platform, the VOLANO® chat server benchmark (VolanoMark), and the business of developing and publishing software. More…

John Neffenger <john@status6.com>
More…

A PROJECT OF STATUS:6®