
Major flaw in Java-based Spring Framework allows remote-code execution - rgarcia
http://www.networkworld.com/news/2013/011713-java-spring-framework-265923.html
======
bhauer
Not sure about the veracity of this, but:

<https://twitter.com/AlBaker_Dev/status/292415396684918784>

"That was fixed in 2011, Spring 3.0.6 and 2.5.6SEC03, enjoy!"

~~~
moondowner
It's valid. Here's more info:
<http://support.springsource.com/security/cve-2011-2730>

And here's an overview for all Spring modules:
<http://support.springsource.com/security/springsource-all>

------
manishsharan
This is needless scaremongering ! If you write a web application that blindly
executes/evals the contents of a request parameter or submitted form data, you
need to have to have your head examined and not blame the underlying framework
for security vulnerability. These security experts wrote a JSP page with a
intentionally flawed code that passes an incoming request parameter to an
expression evaluation engine: <spring:message text=""
code="${param['message']}"> </spring:message>. what did you expect will
happen?

No framework is invulnerable against idiot programmers.

~~~
andrewcooke
you have misunderstood. the problem (afaict - see link below) is that spring
may be evaluating where the programmer intended only to display. see my
comment at <http://news.ycombinator.com/item?id=5083163>

the programmer is _not_ evaluating unvalidated text. the programmer is only
_displaying_ it. the bug in spring is causing the _unexpected, additional
evaluation_.

see, for example, section 3 of
[https://docs.google.com/document/d/1dc1xxO8UMFaGLOwgkykYdghG...](https://docs.google.com/document/d/1dc1xxO8UMFaGLOwgkykYdghGWm_2Gn0iCrxFsympqcE/edit?hl=en_US&pli=1)

~~~
manishsharan
No I am not mistaken. I have been using this taglib and EL when renedering
JSPs. This is how most people use this EL
[http://stackoverflow.com/questions/10981559/how-to-change-
va...](http://stackoverflow.com/questions/10981559/how-to-change-value-of-
code-in-springmessage-code)

[http://www.coderanch.com/t/489232/Spring/spring-message-
tag-...](http://www.coderanch.com/t/489232/Spring/spring-message-tag-labels-
java) See that ? Nobody is using request parameters because that would be
fucking stupid. This is a an Expression Evaluation Engine --- it evaluates
expressions. Every programmer who uses this knows this.

Please stop spreading the FUD!

------
mh8h
The technical details can be found here:
[https://www.aspectsecurity.com/uploads/downloads/2012/12/Rem...](https://www.aspectsecurity.com/uploads/downloads/2012/12/Remote-
Code-with-Expression-Language-Injection.pdf)

~~~
brown9-2
So these guys have issued a new report for an issue first announced/reported
in 2011?

I'm missing what new discovery they've made, beyond the misleading count of
how many people have downloaded the jars from a maven repository.

~~~
matdrewin
Yeah, I guess they are just re-interating that a lot of people are still on
3.0.5 and they might want to look at upgrading.

Here's the original article:

[http://www.mindedsecurity.com/fileshare/ExpressionLanguageIn...](http://www.mindedsecurity.com/fileshare/ExpressionLanguageInjection.pdf)

------
andrewcooke
a rough idea of what is happening here - this is something like sql injection,
but for jsp pages. if you use un-sanitized data in a jsp page, evaluated via
spring's expression language, then you may execute code, provided by users, on
the server.

(expression language can be used elsewhere, but it's not so common and much
less likely to received user-supplied parameters)

also, this article [http://www.h-online.com/open/news/item/The-ghost-of-a-
Spring...](http://www.h-online.com/open/news/item/The-ghost-of-a-Spring-
Framework-bug-haunts-old-code-1786850.html) is much clearer about affected
versions (3.0.5 and below are bad; 3.0.6 can be fixed via config; 3.1 is ok)

~~~
andrewcooke
i'm worried the above may have confused and incorrectly reassured people,
given the other comments here.

this does not require _explicit_ evaluation. it can occur when you were only
trying to _display_ the data.

it is a serious bug, not a stupid programming mistake.

------
mappu
I administer some servers running a third-party java application under tomcat.
How can i tell whether it uses Spring or a vulnerable template?

~~~
andrewcooke
something like

    
    
        find apache-tomcat-7.0.23/ -name "spring*.jar"
    

should show things like:

    
    
        apache-tomcat-7.0.23/webapps/bss/WEB-INF/lib/spring-beans-3.1.1.RELEASE.jar
        apache-tomcat-7.0.23/webapps/bss/WEB-INF/lib/spring-core-3.1.1.RELEASE.jar
        apache-tomcat-7.0.23/webapps/bss/WEB-INF/lib/spring-expression-3.1.1.RELEASE.jar
    

and you need to worry if those version numbers are 3.0.6 or lower. you only
really need to worry about the expression language, which is the last one, but
i cannot promise it is named the same in other versions.

also, this assumes that the project was built with maven or otherwise uses
standard jar names. if the jar was hand-rolled and named then it could look
like anything... (in which case applicationContext.xml, as suggested
elsewhere, at least warns you it's spring).

~~~
manishsharan
Are you deliberately spamming this board with FUD ?

spring-beans and spring-core are the fundamental building blocks of most Java
EE applications and using them in no way causes the aforementioned
vulnerability.

The only case that causes this vulnerability is when a JSP page contains this
code : <spring:message text="" code="${param['message']}"></spring:message>
Any admin can run fgrep or equivalent on all jsps to see if they contain this
text <spring:message text="" code="${param

~~~
Anderkent
param is not really part of the bug - if I understand correctly, any argument
passed to the these tags will be evaluated twice. So you have to check for
message/theme/bind/nestedpath/transform tags and ensure no user-influenced
data is fed to it.

And if you use a templating engine that uses these tags you'd have to trace
whether they are invoked anywhere... So it's not as simple as a grep at all.

------
nnq
...how is this different for complaining that "SQL is unsafe because of
injection possibilities"?

...do real world Spring web apps _really_ use unsanitized user input with
"expression language" queries? (or am I totally missing the point? - not a
Spring guy, I admit, but it all reads weird to me)

~~~
andrewcooke
the point is that spring's el was evaluating things _TWICE_.

if i give my name as "$account.increment" then the worst you would expect to
happen is that when my name is displayed it appears as "$account.increment".
right?

in steps:

    
    
      the jsp page contains <cout value="$user">
    
      el looks at $user and finds the text "$account.increment" and *displays* that.
    

this is completely ok and does not require input sanitization. the code does
not appear unsafe.

but no - there is the possibility that instead of simply displaying the value,
spring will (may - i don't understand exactly when this is triggered)
_evaluate_ it. in steps:

    
    
      the jsp page contains <cout value="$user">
    
      el looks at $user and finds the text "$account.increment".
    
      el *evaluates* $account.increment and increments the account.  PLOP!
    
      el displays the result of evaluating the account.
    

again: this occurs when the programmer was only intending to _display_ the
value. because spring (by mistake) has a _second_ round of evaluation (first
is $user to contents; second is contents to incrementing account), text that
should simply be _displayed_ can be _evaluated_.

see, for example
[https://docs.google.com/document/d/1dc1xxO8UMFaGLOwgkykYdghG...](https://docs.google.com/document/d/1dc1xxO8UMFaGLOwgkykYdghGWm_2Gn0iCrxFsympqcE/edit?hl=en_US&pli=1)

~~~
andrewcooke
an update (edit window is past). it's more complex than i explained above.
only a restricted number of tags (spring ones) are affected and you have to be
doing fairly stupid things (using user parameters in strange ways). the normal
use case of displaying a value is _not_ a risk. sorry.

------
based2
[https://github.com/based2/checker-maven-
plugin/blob/master/s...](https://github.com/based2/checker-maven-
plugin/blob/master/src/main/resources/java_cve.json)

------
iuguy
I get quite upset when I see companies scaremonger for PR rather than try to
help those who are actually doing things.

It seems to follow a particular pattern. Find a bug or bug class in $product.
Then start screaming from the rooftops about how the sky is falling without
telling people how to stop it or what the problem is. Finally release limited
fix info via a mailing list or conference. In the end, everyone loses.

------
robomartin
Is there an up-to-date document of Java security issues somewhere, preferably
with explanations?

I don't use Java much these days but I am teaching my kids OOP using Java. I'd
like to also take the opportunity to show him where the warts are.

~~~
rbanffy
> I am teaching my kids OOP using Java.

I'd suggest doing it with Smalltalk, Ruby or Python. If I had to learn to
program with Java, I'd open a restaurant.

~~~
matdrewin
Tons of people have learned to program with Java. Might not be as elegant as
other languages but the fundamentals are the same.

~~~
iso-8859-1
Why not use something nice if you have the chance? Using your arguments about
fundamentals, it's not even necessary to treat him computer science, he could
just learn maths and he has all the foundations he needs.

------
bingo_cannon
> While the vulnerability that Aspect Security uncovered is not "trivial to
> exploit," acknowledged Williams, he has no doubt that determined attackers
> will do so.

The quotes should cover 'not' as well i.e. "not trivial to exploit".

------
matdrewin
As long as you're not injecting unvalidated request parameters in your JSPs,
you will be fine.

~~~
meaty
And if you do this you are a wally anyway...

------
tonetheman
Meh no worries.

If there is a flaw you probably need to write like 5M of XML to exploit it.

