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

2.10.2011

Oracle Security Alert for CVE-2010-4476 and problem reproduction using JRockit R27.5

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>
    <title>Test Page</title>
    </style>
  </head>
  <body>
  <form name="test">
    BFPN <input name="number" type="text" value="<%= request.getParameter("number") != null ? request.getParameter("number") : "" %>" />
    <input type="submit" value="Query" />
  </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]
    at weblogic/servlet/internal/FilterChainImpl.doFilter(FilterChainImpl.java:42)[optimized]
    at org/apache/beehive/controls/runtime/servlet/ControlFilter.doFilter(ControlFilter.java:96)
    at weblogic/servlet/internal/FilterChainImpl.doFilter(FilterChainImpl.java:42)[optimized]
    at xyz/xyz/web/filters/urlrewrite/RuleChain.handleRewrite(RuleChain.java:176)
    at xyz/xyz/web/filters/urlrewrite/RuleChain.doRules(RuleChain.java:145)
    at xyz/xyz/web/filters/urlrewrite/UrlRewriter.processRequest(UrlRewriter.java:92)
    at xyz/xyz/evolution/presentation/navigation/urlmapping/BellUrlRewriteFilter.doFilter(BellUrlRewriteFilter.java:131)
    at weblogic/servlet/internal/FilterChainImpl.doFilter(FilterChainImpl.java:42)[optimized]
    at xyz/xyz/portal/content/PortletContentsTrackerFilter.doFilter(PortletContentsTrackerFilter.java:189)
    at weblogic/servlet/internal/FilterChainImpl.doFilter(FilterChainImpl.java:42)[optimized]
    at org/apache/beehive/netui/pageflow/PageFlowPageFilter.continueChainNoWrapper(PageFlowPageFilter.java:454)[inlined]
    at org/apache/beehive/netui/pageflow/PageFlowPageFilter.runPage(PageFlowPageFilter.java:431)[inlined]
    at org/apache/beehive/netui/pageflow/PageFlowPageFilter.doFilter(PageFlowPageFilter.java:283)[optimized]
    at weblogic/servlet/internal/FilterChainImpl.doFilter(FilterChainImpl.java:42)[optimized]
    at com/bea/p13n/servlets/PortalServletFilter.doFilter(PortalServletFilter.java:315)[optimized]
    at weblogic/servlet/internal/FilterChainImpl.doFilter(FilterChainImpl.java:42)[inlined]
    at weblogic/servlet/internal/WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3393)[optimized
    at weblogic/security/acl/internal/AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)[optimized]
    at weblogic/security/service/SecurityManager.runAs(Lweblogic/security/acl/internal/AuthenticatedSubject;Lweblogic/security/acl/internal/AuthenticatedSubject;Ljava/security/PrivilegedAction;)Ljava/lang/Object;(Unknown Source)[inlined]
    at weblogic/servlet/internal/WebAppServletContext.securedExecute(WebAppServletContext.java:2140)[inlined]
    at weblogic/servlet/internal/WebAppServletContext.execute(WebAppServletContext.java:2046)[optimized]
    at weblogic/servlet/internal/ServletRequestImpl.run(ServletRequestImpl.java:1366)[optimized]
    at weblogic/work/ExecuteThread.execute(ExecuteThread.java:200)[optimized]
    at weblogic/work/ExecuteThread.run(ExecuteThread.java:172)
    at jrockit/vm/RNI.c2java(JJJJJ)V(Native Method)
    -- end of trace 

The Thread snapshot clearly confirmed the problem replication e.g. Thread #23 is currently involved in an infinite loop within the following Sun classes:

    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)

Conclusion

The problem replication exercise did clearly demonstrate the risk of this Java defect as it could be exploited by hackers in an attempt to generate DoS (Denial of Service) type of attack in an attempt to inject such complex binary floating point value within any Java EE applications exposed over the Internet that may be exposing such binary floating point from a GUI / HTML page.

Our team is currently planning to conduct a full assessment, prioritize and proceed with installation of the available Oracle patch across our affected client Java EE environments.

You can find more detail about the affected Java SDK versions along with available patches below:

0 comments:

Post a Comment