The ghost of a Spring Framework bug haunts old code
There are reports of the discovery of a remote code execution flaw in the Spring Framework, but many are not mentioning that the flaw in question was fixed over a year ago and that what has been found is actually a new way to exploit that old flaw. In 2011, a "variable" severity flaw, identified as CVE-2011-2730, was discovered by two researchers in versions 3.0.0 to 3.0.5, 2.5.0 to 2.5.6SEC02 and 2.5.0 to 2.5.7SR01. The flaw involved Expression Language (EL) and its use in JSP; EL expressions were evaluated by default and in some circumstances were evaluated twice, which could lead to information disclosure to an attacker if there was a location in an application where an unfiltered parameter was placed in a tag that would be evaluated. A paper covered the details.
The flaw's variable severity was due to the need for the application developers using Spring to write code that did allow unfiltered parameters through. The SpringSource developers created a fix, disabling EL support through an attribute and setting that as the default in future Spring versions, 3.1 and beyond. The mitigating fix was also added to Spring 3.0.6 and 2.5.6SEC03, but it needs the
springJspExpressionSupport attribute to be set to false in the web.xml file.
At the end of 2012, Dan Amodio at Aspect Security decided to look into the EL bug and see what else it could be used for. After finding that it could set session variables, and then failing to exploit it further, Amodio hit upon a plan which made the injected code download byte code from another site and execute it. He gives further details in his paper. Amodio informed the Spring developers at the start of December who modified the advisory, raising its severity to critical.
The reason that the bug is being reported as a new flaw is because the flaw was used to publicise the fact that developers are still downloading old versions of the library by Sonatype, makers of tools to manage component lifecycles. Sonatype, who worked with Aspect Security producing a report on vulnerable libraries in the Maven Central Repository last year, says that over the last twelve months, 22,000 organisations have downloaded the vulnerable versions of the Spring libraries 1.3 million times.
Maven, as an automated build system, does not know whether it is downloading a flawed library and, because of a philosophy of not breaking builds, no files are removed from the repository. With no update notification mechanism, systems like Maven can allow developers to keep using a library and allow the ghost of flaws to haunt their code. In the case of the Spring flaw, the ghost got a bit scarier and should serve to remind developers who use any libraries, proprietary or open source, to ensure they monitor advisories and updates from their software suppliers.