Oracle Security Alert for CVE-2010-4476 and problem reproduction using JRockit R27.5 ~ Java EE Support Patterns

This post is about informing you on a new critical Oracle security alert that was released by Oracle on February 8, 2011. We will also demonstrate how it can affect your Java EE environment using a negative test case againts one of our Internet facing Webologic Portal 10.0 application using JRockit R27.5 (JDK 1.5).

Security alert detail and patches

This Security Alert addresses security issue CVE-2010-4476 (Java Runtime Environment hangs when converting "2.2250738585072012e-308" to a binary floating-point number), which is a vulnerability in the Java Runtime Environment component of the Oracle Java SE and Java for Business products. This vulnerability allows unauthenticated network attacks (i.e. it may be exploited over a network without the need for a username and password). Successful attack of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete Denial of Service) of the Java Runtime Environment. Java based application and web servers are especially at risk from this vulnerability.

Problem reproduction and test case

Following the notification from Oracle, we decided to attempt to replicate the problem in a testing environment.

Environment specifications

· Java EE server: Weblogic Portal 10.0

· OS: Oracle (Sun) Solaris 9

· JDK: Oracle (BEA) R27.5.0-110-94909-1.5.0_14-20080204-1536-solaris-sparcv9

· Test type : Negative testing using a JSP page

A simple JSP page was created with the following HTML data capture code:

<%@ page language="java" %>

<%@ page import="java.io.*" %>

<%@ page import="java.util.*" %>

<html>

<head>

</style>

</head>

<body>

BFPN <input name="number" type="text" value="<%= request.getParameter("number") != null ? request.getParameter("number") : "" %>" />

</form>

String bfpn="2.22";

out.println("Default value: " + bfpn);

System.out.println("Default value: " + bfpn);

if (request.getParameter("number") != null && request.getParameter("number").length() != 0) {

ban = request.getParameter("number");

out.println("<br>Using value entered: " + bfpn);

System.out.println("<br>Using value entered: " + bfpn);

}else{

out.println("<br>Using default value: " + bfpn);

System.out.println("<br>Using default value: " + bfpn);

}

out.println("<br>Before the execution.<br>");

System.out.println("<br>Before the execution.<br>");

double d = Double.parseDouble(bfpn);

out.println("Result: " + d);

System.out.println("Result: " + d);

</body>

</html>

The problem was replicated easily, simulating an attack by injection using 2.2250738585072012e-308 as the binary floating point number. The JSP immediately ended up in a hang state, causing a 25% surge of our CPU utilization.

PRSTAT execution

The Solaris command prstat is extremely useful to pinpoint Java thread(s) using a lot of CPU. You can combine the output with a generated Thread Dump to quickly pinpoint the root cause and code contributing to high CPU utilization.

The following command did generate both a prstat snapshot along with a JVM Thread Dump:

user@hostname:/apps/tools/> prstat -L 0 1 | grep 11190;kill -3 11190

11190 user 2897M 2756M cpu3 1 0 0:13:30 24% java/23

11190 user 2897M 2756M sleep 59 0 0:02:23 0.3% java/7

11190 user 2897M 2756M sleep 58 0 0:02:17 0.3% java/5

11190 user 2897M 2756M sleep 57 0 0:02:14 0.2% java/6

11190 user 2897M 2756M sleep 53 0 0:02:17 0.2% java/4

The analysis did reveal the Thread #23 as the primary contributor of the CPU utilization increase.

Thread Dump analysis

We then analysed the Tread Dump generated from the JRockit VM and looked at Thread #23.

"[ACTIVE] ExecuteThread: '1' for queue: 'weblogic.kernel.Default (self-tuning)'" id=21 idx=0x5c tid=23 prio=5 alive, daemon

at sun/misc/FDBigInt.sub(FloatingDecimal.java:2691)[optimized]

at sun/misc/FloatingDecimal.doubleValue(FloatingDecimal.java:1547)

at java/lang/Double.parseDouble(Double.java:482)

at general/_resources/__tools/__test._jspService(__test.java:125)

at weblogic/servlet/jsp/JspBase.service(JspBase.java:34)[optimized]

at weblogic/servlet/internal/StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:226)[optimized]

at weblogic/servlet/internal/StubSecurityHelper.invokeServlet(StubSecurityHelper.java:124)[inlined]

at weblogic/servlet/internal/ServletStubImpl.execute(ServletStubImpl.java:283)[optimized]

at weblogic/servlet/internal/TailFilter.doFilter(TailFilter.java:26)[optimized]