Related Links

Top 5 Stories


Remote code vulnerability in Spring Framework for Java

17 January 2013

Spring Framework, an open-source Java development framework developed by SpringSource and used by software developers to produce business-critical applications, includes a vulnerability that could lead to remote code execution.

The flaw has been called ‘remote code with Expression Language injection’ and was originally discovered 20 months ago. At the time, VMWare (which acquired SpringSource in 2009) produced a fix for the latest version of the Spring Framework. But now new research by Aspect Security’s Dan Amodio has discovered additional issues that elevate the severity of the vulnerability. If exploited, an attacker could execute code remotely and the enterprise would lose control of any business system built on vulnerable versions of Spring.

“It’s difficult to quantify the depth and breadth of this problem,” said Amodio, “since not every application is vulnerable; but any organization using Spring 3.0.5 or earlier is still at risk as these versions do not support disabling the double EL resolution. The vulnerability leads to remote code execution, which can be devastating to an entire infrastructure. Many organizations are still using outdated components, which don't provide added protections by disabling this functionality.  Even more alarming is that these flawed components are still being used to build applications which can present long-term security risks if gone unmanaged.”

Using data from Sonatype, which operates the Central Repository for open source components, Aspect Security estimates that more than 1.3 million instances of the vulnerable Spring Framework have been downloaded by more than 22,000 organizations worldwide. It is actually just one instance of a wider problem. Last year Aspect and Sonatype partnered to produce a report that estimated 29.8 million (or 26%) library downloads included a known vulnerability, while the vast majority of library flaws remain undiscovered. “Typical Java applications,” said the report, “are likely to include at least one vulnerable library.”

To avoid third-party attacks using the Spring vulnerability, Aspect recommends that developers update their libraries and opt out of enabling double EL resolution. “To avoid similar security instances in the future,” it suggests, “organizations should consider Component Lifecycle Management (CLM) products that ensure the integrity of component-based software by analyzing usage, enforcing policy during development and delivering fixes for flawed components.” 

In an unrelated item on the SpringSource blog yesterday, Juergen Hoeller announced that the current 3.2 version of Spring would be the last in the 3.x line, and that work on Spring Framework 4.0 has commenced. “We intend,” he said, “to have yet another one-year iteration and reach 4.0 GA by the end of 2013.”

This article is featured in:
Application Security  •  Internet and Network Security  •  IT Forensics



phumphreyVMW says:

19 March 2013
The discovery by Aspect Security was found in January 2013, but the fix that SpringSource published was made available back in 2011 when this was first discovered. Dan Amodio of Aspect Security informed SpringSource about the possibility of remote code execution.

SpringSource updated our security report 12-06-2012 with Aspect Security’s finding – but the fix/mitigation listed in the original advisory is still applicable:

This vulnerability only affects Spring Framework versions: • 3.0.0 to 3.0.5 -- upgrading to 3.0.6 here would solve a customer’s issue.
• 2.5.0 to 2.5.6.SEC02 (community releases) -- upgrading to 2.5.6.SEC03 here would solve a customer’s issue.
• 2.5.0 to 2.5.7.SR01 (subscription customers) -- upgrading to 2.5.7.SR02 here would solve a customer’s issue.

This has been fixed in all versions going forward – the current release of SpringFramework is 3.2, released in Dec 2012.

-Pieter (SpringSource)

Note: The majority of comments posted are created by members of the public. The views expressed are theirs and unless specifically stated are not those Elsevier Ltd. We are not responsible for any content posted by members of the public or content of any third party sites that are accessible through this site. Any links to third party websites from this website do not amount to any endorsement of that site by the Elsevier Ltd and any use of that site by you is at your own risk. For further information, please refer to our Terms & Conditions.

Comment on this article

You must be registered and logged in to leave a comment about this article.

We use cookies to operate this website and to improve its usability. Full details of what cookies are, why we use them and how you can manage them can be found by reading our Privacy & Cookies page. Please note that by using this site you are consenting to the use of cookies. ×